From nobody Sat Mar 1 13:15:24 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651BF1A0AA6; Sat, 1 Mar 2014 13:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] 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 4c6ELIGdYlg3; Sat, 1 Mar 2014 13:15:16 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 3A42A1A0A3D; Sat, 1 Mar 2014 13:15:16 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s21LFCjN027319; Sat, 1 Mar 2014 21:15:12 GMT Received: from 950129200 ([130.129.155.107]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s21LFBMC027311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Mar 2014 21:15:12 GMT From: "Adrian Farrel" To: , , Date: Sat, 1 Mar 2014 21:15:12 -0000 Message-ID: <016b01cf3593$559e5c20$00db1460$@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: Ac81k02Ei3diiSknRm29s6W1beIuYQ== Content-Language: en-gb Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/n8nv1gTrzndI38FGk6HkYt82ylI Subject: [RTG-DIR] Routing ADs' Open Office - Reminder and Location X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 21:15:18 -0000 Hi, Sunday 14.30-16.00 Victoria (East Wing, Mezzanine Meeting Rooms) Adrian, Stewart, and Alia From nobody Sun Mar 2 05:48:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCDC1A0722; Sun, 2 Mar 2014 05:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 9-Hr382Bs_IX; Sun, 2 Mar 2014 05:48:52 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id B89A11A06E5; Sun, 2 Mar 2014 05:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=185; q=dns/txt; s=iport; t=1393768130; x=1394977730; h=message-id:date:from:reply-to:mime-version:to:subject: content-transfer-encoding; bh=Z0XshwsyS7ApK/+PXs8oKO2AHMEDHuIqeoP5w1YcWFo=; b=Iqq8yOzRtsgIV08myS0wJs9tbWhz8s1Shp94/BU2Jdj/d8laIiaeML/D M/rf4IPDysLVTdHN5dcI3NXK2VixPwYr1eJ/YSX52hQc9+Do/6fcI6D5u 6UEeuxo4ggi48EXHfUdeVQ6NxH/H4J2K8lg68T7B0d1DkL6xpr6oD5IHD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOw1E1OQ/khR/2dsb2JhbABagwbDRBZ0gmRAPRYYAwIBAgFLAQwIAQGHdaMmqDsXkxgEmDySK4Mt X-IronPort-AV: E=Sophos;i="4.97,572,1389744000"; d="scan'208";a="2025247" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 02 Mar 2014 13:48:48 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s22DmlCW000668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Mar 2014 13:48:48 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s22DmkgU006238; Sun, 2 Mar 2014 13:48:47 GMT Message-ID: <531336BF.1040309@cisco.com> Date: Sun, 02 Mar 2014 13:48:47 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: routing-discussion@ietf.org, "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/B1_obfJacHnOufcoigsaHi9wj3Q Subject: [RTG-DIR] RTG ADs Open House - new location X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 13:48:53 -0000 Seems that the Hotel have booked out the IESG room to another organization today. The three RTG ADs are in Hilton Boardroom 1, which accessed via tower lift level 1. Stewart From nobody Wed Mar 19 09:26:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF08E1A07A1; Wed, 19 Mar 2014 09:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 Hffs6_V08CGm; Wed, 19 Mar 2014 09:26:22 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 299F31A0754; Wed, 19 Mar 2014 09:26:21 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s2JGQ7UR020563; Wed, 19 Mar 2014 11:26:07 -0500 (CDT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s2JG6676021908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 12:06:06 -0400 Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Mar 2014 12:06:06 -0400 Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.74]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 20 Mar 2014 00:06:02 +0800 From: "Bhatia, Manav (Manav)" To: "david.sinicrope@gmail.com" Thread-Topic: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-auth-02 Thread-Index: AQHOvHW6Vn3yQ7bMNk6chPmRg73d0prpn7xQ Date: Wed, 19 Mar 2014 16:06:01 +0000 Message-ID: <20211F91F544D247976D84C5D778A4C32E5B4DAD@SG70YWXCHMBA05.zap.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.253.19.17] Content-Type: multipart/alternative; boundary="_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ITZIVhxFyXiLcZafrVcyKgTtbsM Cc: "mpls@ietf.org" , Mach Chen , "rtg-dir@ietf.org" , Loa Andersson , Lianshu Zheng , "karp@ietf.org" Subject: [RTG-DIR] FW: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-auth-02 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 16:26:26 -0000 --_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi David, I think I have addressed most of your comments and suggestions in the updat= ed document. Can you please take a look at this and see if there is anything else that y= ou think we ought to address before it gets pushed further. URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-hel= lo-crypto-auth-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-= crypto-auth/ Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto= -auth-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-hell= o-crypto-auth-03 Cheers, Manav From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Dav= id Sinicrope Sent: Saturday, September 28, 2013 11:25 PM To: mpls@ietf.org; IETF.PWE3; karp@ietf.org Subject: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-auth-02 This time with a more relevant subject on the email. Dave Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review. The purpose of the re= view is to provide assistance to the Routing ADs. For more information abou= t the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-mpls-ldp-hello-crypto-auth-02 Reviewer: David Sinicrope Review Date: 28 September 2013 IETF LC End Date: 23 September 2013 Intended Status: Standards Track o Summary: I have some major and minor concerns about this document that I think shoul= d be resolved before publication. While I reviewed the document from the R= tgDir point of view, I would strongly suggest a thorough security related r= eview, if not already done, before progressing to publication. In general, I believe the document should be progressed to publication once= the issues are resolved by the authors. The document assumes a working kn= owledge of KARP mechanisms. This should be stated up front with relevant r= eferences. I've attached a .pdf version of the document to this message for use by the= authors. Comments: --- Page 4 --- Note (yellow), Sep 27, 2013, 3:04 PM: Nit: sec1, para 1 1st sentence : c/runs/run Note (yellow), Sep 27, 2013, 3:04 PM: Minor- sec 1, para 2: start the second sentence with "Since the Hello messa= ges are sent with UDP and not TCP..." Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1, para 2: change "Besides a note that some configuration may = help protect against bogus discovery messages, [RFC5036] does not really p= rovide any security mechanism to protect the Hello messages." To "While so= me configuration guidance is given in [RFC5036] to help protect against fal= se discovery messages, it does not provide an explicit security mechanism t= o protect the Hello messages." Note (yellow), Sep 27, 2013, 3:04 PM: Minor - global: c/Spoofing/Falsifying/ Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1, para 3: please give an example of a falsified Hello with a d= ifferent transport address. Note (yellow), Sep 27, 2013, 3:04 PM: Nit - sec 1, para 4: remove first "that" in the fist sentence Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1 para 4, 1st sentence and global: remove "Basic". The text is = introducing a new term of "Basic Hellos" that doesn't exist in RFC 5036. Y= ou may be referring to "Link Hellos". See RFC 5036 sec 2.4. Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 1 para 4 & global: remove "Extended" and replace with "Targeted= ". The text is introducing a new term of "Extended Hellos" that doesn't exi= st in RFC 5036. You may be referring to "Targeted Hellos". See RFC 5036 s= ec 2.4. Note (yellow), Sep 27, 2013, 3:04 PM: Nit - sec 1, para 5, sentence 1: c/message/messages/ --- Page 5 --- Note (yellow), Sep 27, 2013, 3:04 PM: Nit - global: refer consistently to "Hello message"s vs "Hellos" and "Hello= packets". Note (yellow), Sep 27, 2013, 3:04 PM: Major - Sec 1, para 6, last sentence: remove thisMinor - sec 1 para 4, 1st = sentence and global: remove "Basic". The text is introducing a new term of = "Basic Hellos" that doesn't exist in RFC 5036. You may be referring to "Li= nk Hellos". See RFC 5036 sec 2.4. last sentence, it is redundant with sect= ion 3. --- Page 6 --- Note (yellow), Sep 27, 2013, 3:04 PM: Minor - sec 2.1, 1st para: remove 3rd sentence. Adds no value. Note (yellow), Sep 28, 2013, 1:29 PM: Major- s2.2, Auth Key ID: this field is conveying the algorithm AND the the= secret key. It should be atomic, I.e., the algorithm ID should be one fie= ld the key another. Major - s2.2, Auth Key ID: the composition of this field is not clear to th= e casual reader. Exactly how is the algorithm identified and what portion = is the algorithm I'd and what part is the secret key? --- Page 7 --- Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s2.2, p6: remove "really" in the penultimate sentence. Note (yellow), Sep 28, 2013, 1:29 PM: Major - s2.2, p6: what are the "available mechanisms" that are being requir= ed? I.e., if some one was to test compliance to the requirements of this dr= aft what would they test for this? Without more specifics on how to meet t= he sequence number requirement, the strictly increasing requirement in the = paragraph above is sufficient. Note (yellow), Sep 28, 2013, 1:29 PM: Major - s2.3, p1: it should be clearly stated that the high order 32 bits a= re incremented on device boot, and low order 32 bit wrap. "This is curren= tly on given subtly in the previous section as "wrap/boot". Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s2.3, p1: "If by some chance..." Should start a new paragraph, --- Page 8 --- Note (yellow), Sep 28, 2013, 1:29 PM: Major - s3, p1, sentence 1: "... the Auth Key ID maps to the authenticatio= n algorithm and the secret key used to..." Maps how exactly? As noted in = earlier comments it seems as those this field should be broken into two ato= mic fields Auth Algorithm and Auth Key. Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s3, p4: might be easier to see requirements as a list. "Of the above, implementations of this specification: - MUST include support for at least HMAC-SHA-256 - SHOULD include support for HMAC-SHA-1 - MAY include support for HMAC-SHA-384 or HMAC-SHA-512 or both." Note (yellow), Sep 28, 2013, 1:29 PM: Nit- s3,p3:remove this paragraph/list, it is superfluous, with the paragrap= h below and section 2.2 last paragraph. Further the word "includes" implie= s the list is not exhaustive. i.e., I can use MD5 if I wish. Question- s3,p3: Are other authentication hashes prohibited? If not how ar= e they identified and encoded? --- Page 9 --- Note (yellow), Sep 28, 2013, 1:29 PM: Major- s4: this is difficult to follow. - the section makes reference to "the two octet LDP Cryptographic Protocol = ID" this field is not previously mentioned in this document. What is the r= eference to this ID? Where is it defined? - The section makes reference to the "authentication key". Is this the same= as the Authentication Key ID in section 2.2? -"Other protocols using cryptographic authentication as specified herein M= UST similarly append their respective Cryptographic Protocol IDs to their = keys in this step." This document only specifies one protocol using crypt= o authentication, I.e., LDP What are the others being referred to? - This text first uses the term "Cryptographic Protocol ID". What is this? = Where is it defined? From the IANA considerations it is clearer this refe= rs to a KARP mechanism. Please add some explanation of how this mechanism = fits into the KARP framework. - could use more explanation or a reference to additional information on th= e cross protocol attack problem being addressed. - reference to "protocols sharing common keys," what does this mean? Pleas= e elaborate. Perhaps an example would help. --- Page 10 --- Note (yellow), Sep 28, 2013, 1:29 PM: General- the RtgDir Note - s5: I don't see any routing protocol issues with this. It should be= reviewed for security and crypto issues. --- Page 12 --- Note (yellow), Sep 28, 2013, 1:29 PM: Nit - s6.1, p1, 1st sentence: add "the" after "transmitting" Nit - s6.1, p1, last sentence: make this a list Nit - s6.1, p2, 1st sentence: make this a separate paragraph (report generated by GoodReader) --_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi David,

 <= /p>

I think I have addressed = most of your comments and suggestions in the updated document.

 <= /p>

Can you please take a loo= k at this and see if there is anything else that you  think we ought t= o address before it gets pushed further.

 <= /p>

URL:       &nb= sp;    http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-hello-crypto-auth-0= 3.txt

Status:       =   https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-hello-crypto-auth/=

Htmlized:       http://tools.ietf.org/html/draft-ietf-mpls-ldp-hello-crypto-auth-03

Diff:       &n= bsp;   http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-hello-crypto-auth-03=

 <= /p>

Cheers, Manav<= /span>

 <= /p>

 <= /p>

From: karp-bou= nces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of David Sinicrope
Sent: Saturday, September 28, 2013 11:25 PM
To: mpls@ietf.org; IETF.PWE3; karp@ietf.org
Subject: [karp] RtgDir review of draft-ietf-mpls-ldp-hello-crypto-au= th-02

 

This time with a more relevant subject on the email.=

Dave

Hello,

I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review. The purpose of the= review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, pl= ease see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it= would be helpful if you could consider them along with any other IETF Last= Call comments that you receive, and strive to resolve them through discuss= ion or by updating the draft.

Document: draft-ietf-mpls-ldp-hello-crypto-auth= -02
Reviewer: David Sinicrope

Review Date: 28 September 2013
IETF LC End Date: 23 September 2013
Intended Status: Standards Track

 

o Summary:
I have some major and minor concerns about this document that I think shoul= d be resolved before publication.  While I reviewed the document from = the RtgDir point of view, I would strongly suggest a thorough security rela= ted review, if not already done, before progressing to publication.  



In general, I believe the document should be progres= sed to publication once the issues are resolved by the authors.  The d= ocument assumes a working knowledge of KARP mechanisms.  This should b= e stated up front with relevant references.



I've attached a .pdf version of the document to this= message for use by the authors.

Comments:


--- Page 4 ---

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit: sec1, para 1 1st sentence : c/runs/run

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor- sec 1, para 2: start the second sentence with "Since the Hello = messages are sent with UDP and not TCP..."

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1, para 2: change "Besides a note that some  configur= ation may help protect against bogus discovery messages,  [RFC5036] do= es not really provide any security mechanism to protect  the Hello mes= sages." To "While some configuration guidance is given in [RFC5036] to help protect against false discovery messages, it does not= provide an explicit security mechanism to protect the Hello messages."= ;

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - global: c/Spoofing/Falsifying/

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1, para 3: please give an example of a falsified Hello with a d= ifferent transport address.

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit - sec 1, para 4: remove first "that" in the fist sentence

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1 para 4, 1st sentence and global: remove "Basic". Th= e text is introducing a new term of "Basic Hellos" that doesn't e= xist in RFC 5036.  You may be referring to "Link Hellos".&nb= sp; See RFC 5036 sec 2.4.

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 1 para 4 & global: remove "Extended" and replace = with "Targeted". The text is introducing a new term of "Exte= nded Hellos" that doesn't exist in RFC 5036.  You may be referrin= g to "Targeted Hellos".  See RFC 5036 sec 2.4.

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit - sec 1, para 5, sentence 1: c/message/messages/


--- Page 5 ---

Note (yellow), Sep 27, 2013, 3:04 PM:
Nit - global: refer consistently to "Hello message"s vs "Hel= los" and "Hello packets".

Note (yellow), Sep 27, 2013, 3:04 PM:
Major - Sec 1, para 6, last sentence: remove thisMinor - sec 1 para 4, 1st = sentence and global: remove "Basic". The text is introducing a ne= w term of "Basic Hellos" that doesn't exist in RFC 5036.  Yo= u may be referring to "Link Hellos".  See RFC 5036 sec 2.4. last sentence, it is redundant with section 3.


--- Page 6 ---

Note (yellow), Sep 27, 2013, 3:04 PM:
Minor - sec 2.1, 1st para: remove 3rd sentence.  Adds no value.

Note (yellow), Sep 28, 2013, 1:29 PM:
Major- s2.2, Auth Key ID: this field is conveying the algorithm AND the the= secret key.  It should be atomic, I.e., the algorithm ID should be on= e field the key another.

Major - s2.2, Auth Key ID: the composition of this field is not clear to th= e casual reader.  Exactly how is the algorithm identified and what por= tion is the algorithm I'd and what part is the secret key?


--- Page 7 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s2.2, p6: remove "really" in the penultimate sentence.

Note (yellow), Sep 28, 2013, 1:29 PM:
Major - s2.2, p6: what are the "available mechanisms" that are be= ing required? I.e., if some one was to test compliance to the requirements = of this draft what would they test for this?  Without more specifics o= n how to meet the sequence number requirement, the strictly increasing requirement in the paragraph above is sufficient.<= br>
Note (yellow), Sep 28, 2013, 1:29 PM:
Major - s2.3, p1: it should be clearly stated that the high order 32 bits a= re  incremented on device boot, and low order 32 bit wrap.  "= ;This is currently on given subtly in the previous section as "wrap/bo= ot".

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s2.3, p1: "If by some chance..."  Should start a new p= aragraph,


--- Page 8 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Major - s3, p1, sentence 1:  "... the Auth Key ID maps to the aut= hentication algorithm and the secret key used to..."  Maps how ex= actly?  As noted in earlier comments it seems as those this field shou= ld be broken into two atomic fields Auth Algorithm and Auth Key.

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s3, p4: might be easier to see requirements as a list.
"Of the above, implementations of this specification:
- MUST include support for at least HMAC-SHA-256
- SHOULD include support for HMAC-SHA-1
- MAY include support for HMAC-SHA-384 or HMAC-SHA-512 or both."

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit- s3,p3:remove this paragraph/list, it is superfluous, with the paragrap= h below and section 2.2 last paragraph.  Further the word "includ= es" implies the list is not exhaustive.  i.e., I can use MD5 if I= wish.

Question- s3,p3: Are other authentication hashes prohibited?  If not h= ow are they identified and encoded?


--- Page 9 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Major- s4:  this is difficult to follow. 
- the section makes reference to "the two octet LDP Cryptographic Prot= ocol ID" this field is not previously mentioned in this document. = ; What is the reference to this ID? Where is it defined?

- The section makes reference to the "authentication key". Is thi= s the same as the Authentication Key ID in section 2.2?

-"Other protocols  using cryptographic authentication as specifie= d herein MUST similarly  append their respective Cryptographic Protoco= l IDs to their keys in  this step."  This document only spec= ifies one protocol using crypto authentication, I.e., LDP What are the others being referred to? 

- This text first uses the term "Cryptographic Protocol ID". What= is this?  Where is it defined?  From the IANA considerations it = is clearer this refers to a KARP mechanism.  Please add some explanati= on of how this mechanism fits into the KARP framework.

- could use more explanation or a reference to additional information on th= e cross protocol attack problem being addressed.

- reference to "protocols sharing common keys," what does this me= an?  Please elaborate. Perhaps an example would help.


--- Page 10 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
General- the RtgDir

Note - s5: I don't see any routing protocol issues with this.  It shou= ld be reviewed for security and crypto issues.


--- Page 12 ---

Note (yellow), Sep 28, 2013, 1:29 PM:
Nit - s6.1, p1, 1st sentence: add "the" after "transmitting&= quot;
Nit - s6.1, p1, last sentence: make this a list
Nit - s6.1, p2, 1st sentence: make this a separate paragraph



(report generated by GoodReader)

 

--_000_20211F91F544D247976D84C5D778A4C32E5B4DADSG70YWXCHMBA05z_-- From nobody Thu Mar 20 05:46:06 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7A1A03CE for ; Thu, 20 Mar 2014 05:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.853 X-Spam-Level: X-Spam-Status: No, score=-97.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 rcXW2rk4rtXF for ; Thu, 20 Mar 2014 05:46:02 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id C56D61A0744 for ; Thu, 20 Mar 2014 05:46:00 -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 s2KCjo2l001286 for ; Thu, 20 Mar 2014 12:45:50 GMT Received: from 950129200 (110.26.90.92.rev.sfr.net [92.90.26.110]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2KCjmV3001276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Mar 2014 12:45:49 GMT From: "Adrian Farrel" To: Date: Thu, 20 Mar 2014 12:45:50 -0000 Message-ID: <049701cf443a$53a025b0$fae07110$@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: Ac9EOlCMNFzZqBWNTGmdb9v/8pqDhA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20576.006 X-TM-AS-Result: No--3.073-10.0-31-10 X-imss-scan-details: No--3.073-10.0-31-10 X-TMASE-MatchedRID: uz066wf0knKfKvWkXoMtxEg5Iem1vm3HGSqdEmeD/nVGr8G3v23M36Ie Tp7UBhhRrJ9UP7zoipqRXF2WkPr49vHgKSpVZydJJ7VPmvVUDcgGwd8wUY9uM7l+jVyLzmC7HUX +kHBsGd6vxGOtmo34h6EyNcDSVcG2p8pDLp9CdcLpnOP6QxEGtn0tCKdnhB58vqq8s2MNhPB/KM EkOe61SFBIVsvVu9ABJ0RPnyOnrZLstCMY8sL/Y8XmJ1pMvg0+Wx+TDlFWel8GYSsQcKsCO66Mo YMsSiSK6qTD7EJ4oxwspEz3oOxEa8Hl7Cuq8OXSUFps2EhB2uNN/vQcxQpFczQFvN82A8P79TpQ iD8Sn4s54DEQIK3XhMn5FmnhuafQ Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wIfFeRLuQnLTMdtKN8OpJnTZNek Subject: [RTG-DIR] Dan Li stepping down as Routing Directorate Co-Admin X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 12:46:03 -0000 Hi, Dan and Deborah have been running the admin of the Directorate together very smoothly for a number of years, covering for each other during vacations and work trips so that the ADs (initially Ross and Adrian, then Stewart and Adrian) never had to worry about who was tracking issues. All the ADs needed to do was fire off a note and they knew it was taken care of. Over time Dan has moved on (and upwards) with an important management position in ITU-T SG15 and also within Huawei. This has given him less time to focus on the IETF and he has asked to step down from this position. Jonathan Hardwick has agreed to take on the role and under Deborah's tutelage I am sure the hand-over will be smooth. Many thanks to both Dan and Jon for their work. Cheers, Adrian and Alia From nobody Thu Mar 20 06:17:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102C11A08D2 for ; Thu, 20 Mar 2014 06:17: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, 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 krxfGYYRX-xa for ; Thu, 20 Mar 2014 06:17:28 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id BDA731A08C7 for ; Thu, 20 Mar 2014 06:17:28 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-b2-532ae7788a5f Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 78.B9.11484.877EA235; Thu, 20 Mar 2014 14:04:56 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0387.000; Thu, 20 Mar 2014 09:17:18 -0400 From: Acee Lindem To: Dan Li Thread-Topic: [RTG-DIR] Dan Li stepping down as Routing Directorate Co-Admin Thread-Index: Ac9EOlCMNFzZqBWNTGmdb9v/8pqDhAAJe3CA Date: Thu, 20 Mar 2014 13:17:17 +0000 Message-ID: References: <049701cf443a$53a025b0$fae07110$@olddog.co.uk> In-Reply-To: <049701cf443a$53a025b0$fae07110$@olddog.co.uk> 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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPrG7Fc61gg5fNUhavnk9gtFiw5im7 A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYPPsJU8EjjopZyzezNjC+Z+ti5OSQEDCR +PSlFcoWk7hwbz2YLSRwhFFiTxtrFyMXkL2cUWLLoSZ2kASbgI7E80f/mLsYOThEBGQlWnqM QUxmAU2JtZe5QCqEBbwlPmzaxwxiiwj4SKzc08sEYRtJdKz8zgJiswioSsx4fQHM5hWwl3h+ dA0jxForiXdNuxlBRnIKWEt8mQpWwgh02fdTa8DGMAuIS9x6Mp8J4mIBiSV7zjND2KISLx// Y4WwFSX29U9nh6jXkViw+xMbhG0tseT6LmYIW1ti2cLXzBAnCEqcnPmEZQKj+CwkK2YhaZ+F pH0WkvZZSNoXMLKuYuQoLU4ty003MtzECIynYxJsjjsYF3yyPMQozcGiJM775a1zkJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQbGzqdRf2//aL8SVpfckdiV/eRe3OR3s7ZGtOzvO591MI4h 8rlf9o9TtQ0cj6cHXQ1MnzeZ02GpB1vliotinVab5zzYJTLpeMDcWe+WvbC+/Sxg2p31u6dL PFozu2hR68UYn5YjR1ZpV9sdV9hwJrcn19KS06P4rkjQzI8/H9V8O6F0rffCR9+b8kosxRmJ hlrMRcWJANbqVOJ1AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/-RD78mmU0B7MtnYmA8WbrY_9KxY Cc: "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Dan Li stepping down as Routing Directorate Co-Admin X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:17:31 -0000 Dan - Thanks for all the work administrating the Routing Directorate and go= od luck with your new position.=20 Acee=20 On Mar 20, 2014, at 8:45 AM, Adrian Farrel wrote: > Hi, >=20 > Dan and Deborah have been running the admin of the Directorate together v= ery > smoothly for a number of years, covering for each other during vacations = and > work trips so that the ADs (initially Ross and Adrian, then Stewart and A= drian) > never had to worry about who was tracking issues. All the ADs needed to d= o was > fire off a note and they knew it was taken care of. >=20 > Over time Dan has moved on (and upwards) with an important management pos= ition > in ITU-T SG15 and also within Huawei. This has given him less time to foc= us on > the IETF and he has asked to step down from this position. >=20 > Jonathan Hardwick has agreed to take o= n the > role and under Deborah's tutelage I am sure the hand-over will be smooth. >=20 > Many thanks to both Dan and Jon for their work. >=20 > Cheers, > Adrian and Alia >=20 >=20 >=20 From nobody Thu Mar 20 06:30:28 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFCA1A08CB for ; Thu, 20 Mar 2014 06:30:26 -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 K3vU9UKU93RM for ; Thu, 20 Mar 2014 06:30:23 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 560DA1A08C8 for ; Thu, 20 Mar 2014 06:30:23 -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 s2KDUC1f029538 for ; Thu, 20 Mar 2014 13:30:12 GMT Received: from 950129200 (110.26.90.92.rev.sfr.net [92.90.26.110]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2KDUAJN029422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Mar 2014 13:30:12 GMT From: "Adrian Farrel" To: Date: Thu, 20 Mar 2014 13:30:12 -0000 Message-ID: <04c001cf4440$8675b350$936119f0$@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: Ac9EQFHeM0lHUkPuQpylVqsowfP4HA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20576.006 X-TM-AS-Result: No--11.244-10.0-31-10 X-imss-scan-details: No--11.244-10.0-31-10 X-TMASE-MatchedRID: RbQp6+VZ92glr4UAbUFME4v73wEu0Nx7TXnWmEdM1hGeZPgfsiHN3a79 I6IQCMPyxBNJOS7QP8RmTS5sLBywlCAiXI4mhveSdrnuu4cCcfGHxi2fvkKUM8zvOkSymob/vh9 Mai8mi6j1HPS4UJoGDhUZqx3zdGw7emzGG4qDPalCvapcIkxJX3HhdFmDyaVratZ/Qq0plW72mN 6F/22Lyyya+v8M/JfcR0g1tEUNvxkYB2fOueQzjzl/1fD/Gopd2K+lN2ZUJHbEQdG7H66TyH4gK q42LRYk092KuZV4DCK/CLBLktCGZWFOItnt7rW5VlQa18DvB/V+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/p731tzSWRg5NTJFd3eCXhdxImFM Subject: [RTG-DIR] Changes to Routing Directorate membership X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:30:26 -0000 Hi all, Please welcome some new members to the Directorate. With Alia on board as our new AD we have taken the opportunity to get a few of you to renew your vows, to refresh the Directorate, and obviously to fire Alia as a Directorate member :-) New to the ranks are: Sue Hares Hickory Hill Consulting Stewart Bryant Cisco Keyur Patel Cisco Mach Chen Huawei Andy Malis Huawei Terry Manderson ICANN They have all been added to the mailing list, and the web page update is in the pipe. May we (again) thank you for the work you do and remind you to reread the web page https://www.ietf.org/iesg/directorate/routing.html for guidance about reviews and to raise any issues you have. Thanks, Adrian and Alia PS, for those of you who care about these things (we make a causal attempt at balance, but nothing strong) 6 Cisco 4 Juniper 4 Ericsson 5 Huawei 5 Alcatel-Lucent 6 Operators 11 Other companies and independents --- 41 From nobody Thu Mar 20 06:30:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8D1A03E9 for ; Thu, 20 Mar 2014 06:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 FyzYC5FVl_su for ; Thu, 20 Mar 2014 06:30:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E709D1A06F2 for ; Thu, 20 Mar 2014 06:30:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , References: <049701cf443a$53a025b0$fae07110$@olddog.co.uk> In-Reply-To: <049701cf443a$53a025b0$fae07110$@olddog.co.uk> Date: Thu, 20 Mar 2014 09:30:34 -0400 Message-ID: <028f01cf4440$92d71a80$b8854f80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJZMjB+KAwtI83uflwH1lHAZl938pnWHKZA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/i7G-SluHTFb1Jay43zIOy33Ci14 Subject: Re: [RTG-DIR] Dan Li stepping down as Routing Directorate Co-Admin X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Mar 2014 13:30:47 -0000 Dan: Thank you for all your hard work on the Routing AD. Sue -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Thursday, March 20, 2014 8:46 AM To: rtg-dir@ietf.org Subject: [RTG-DIR] Dan Li stepping down as Routing Directorate Co-Admin Hi, Dan and Deborah have been running the admin of the Directorate together very smoothly for a number of years, covering for each other during vacations and work trips so that the ADs (initially Ross and Adrian, then Stewart and Adrian) never had to worry about who was tracking issues. All the ADs needed to do was fire off a note and they knew it was taken care of. Over time Dan has moved on (and upwards) with an important management position in ITU-T SG15 and also within Huawei. This has given him less time to focus on the IETF and he has asked to step down from this position. Jonathan Hardwick has agreed to take on the role and under Deborah's tutelage I am sure the hand-over will be smooth. Many thanks to both Dan and Jon for their work. Cheers, Adrian and Alia From nobody Fri Mar 21 11:31:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5171A09FF; Fri, 21 Mar 2014 11:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.654 X-Spam-Level: X-Spam-Status: No, score=-98.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 SBsu1aer4qbC; Fri, 21 Mar 2014 11:31:22 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 306671A03DD; Fri, 21 Mar 2014 11:31:22 -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 s2LIVCsA002074; Fri, 21 Mar 2014 18:31:12 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2LIV815002035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Mar 2014 18:31:09 GMT From: "Adrian Farrel" To: , Date: Fri, 21 Mar 2014 18:31:08 -0000 Message-ID: <090901cf4533$bc895840$359c08c0$@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: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEg== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20582.001 X-TM-AS-Result: No--10.569-10.0-31-10 X-imss-scan-details: No--10.569-10.0-31-10 X-TMASE-MatchedRID: 12Xa/RVcPtGSDoYDmYjzLM98NT1MWuHvnvBHr/aFnM7agsZM0qVv10Ui 03ou4skQrgU550wdHoxY03RiAPqCiGbxI8bKMM2VvjbQsW4wX4ZP/yasSnN+D1AJw3UwxOCmAmh wf/f7pFi9NDBWKrcaI7h8wiI4NasiTX7PJ/OU3vL+xOhjarOnHmrz/G/ZSbVq+gtHj7OwNO0Yzp bdT4ued4dyu+LjjP8bsn20T8vRlJc6dBAIbpfNnPoQaE32wt28 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/b-UcuSmGUqsXs9dykUAuvsKKHYQ Cc: Alia Atlas Subject: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:31:24 -0000 Hello Directorate and WG chairs, Alia and I have been discussing the Routing Area, its work, its output, and its working groups. We have reached a conclusion (which perhaps we should have come to sooner) that we need your help and input. The crunch question for us is "What makes it hard to get work done in the Routing Area?" What gets in the way of your work? What is making life hard for document authors? How could working groups be doing better? We are open to all and every type of answer. We are happy to have quick, one-line answers or deeply-considered essays. What do you think? Thanks for all your input, Adrian and Alia PS Please respond to both aliases because not everyone is on both lists. Sorry that that means some of you will get duplicates. From nobody Fri Mar 21 13:45:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3D1A0792; Fri, 21 Mar 2014 13:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OOl6uurnkMOA; Fri, 21 Mar 2014 13:44:57 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5C1A0A0C; Fri, 21 Mar 2014 13:44:57 -0700 (PDT) Received: from mail36-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 21 Mar 2014 20:44:47 +0000 Received: from mail36-va3 (localhost [127.0.0.1]) by mail36-va3-R.bigfish.com (Postfix) with ESMTP id 7E4123C0255; Fri, 21 Mar 2014 20:44:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz9371I1b0aL542I1dbaI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail36-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(13464003)(51704005)(377454003)(87936001)(53806001)(54356001)(46102001)(87266001)(54316002)(81342001)(56776001)(2656002)(51856001)(81542001)(47736001)(47976001)(49866001)(4396001)(80022001)(74502001)(66066001)(65816001)(31966008)(20776003)(85852003)(97186001)(97336001)(76786001)(63696002)(76576001)(83072002)(59766001)(19580405001)(76482001)(81816001)(74662001)(83322001)(80976001)(2201001)(85306002)(19580395003)(33646001)(95416001)(93136001)(50986001)(86362001)(74316001)(95666003)(90146001)(93516002)(77982001)(74876001)(79102001)(47446002)(92566001)(74366001)(98676001)(56816005)(94946001)(94316002)(81686001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB200; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:B819D21C.ABF39309.C1DFBDBF.D7C5E1BD.202B2; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail36-va3 (localhost.localdomain [127.0.0.1]) by mail36-va3 (MessageSwitch) id 1395434684910575_26206; Fri, 21 Mar 2014 20:44:44 +0000 (UTC) Received: from VA3EHSMHS043.bigfish.com (unknown [10.7.14.245]) by mail36-va3.bigfish.com (Postfix) with ESMTP id 9444F2C0054; Fri, 21 Mar 2014 20:44:44 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS043.bigfish.com (10.7.99.53) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 21 Mar 2014 20:44:31 +0000 Received: from BLUPR05MB200.namprd05.prod.outlook.com (10.255.191.14) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 21 Mar 2014 20:44:30 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB200.namprd05.prod.outlook.com (10.255.191.14) with Microsoft SMTP Server (TLS) id 15.0.898.11; Fri, 21 Mar 2014 20:44:29 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0898.005; Fri, 21 Mar 2014 20:44:29 +0000 From: John E Drake To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQ Date: Fri, 21 Mar 2014 20:44:28 +0000 Message-ID: <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 0157DEB61B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/fqLL49J9mk_XnZYEMi3N3L-k9C8 Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 20:44:59 -0000 Adrian, Combine IS-IS and OSPF Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there There is probably some synergy between PCE, SFC, and SPRING that needs to b= e exploited Combine BFD and the OAM/protection switching part of MPLS Close Secure IDR, FORCES, KARP, MANET, and NVO3=20 Yours Irrespectively, John > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farre= l > Sent: Friday, March 21, 2014 11:31 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Cc: Alia Atlas > Subject: [RTG-DIR] Routing Area Health Check >=20 > Hello Directorate and WG chairs, >=20 > Alia and I have been discussing the Routing Area, its work, its output, a= nd its > working groups. >=20 > We have reached a conclusion (which perhaps we should have come to sooner= ) > that we need your help and input. >=20 > The crunch question for us is "What makes it hard to get work done in the > Routing Area?" What gets in the way of your work? What is making life har= d > for document authors? How could working groups be doing better? We are > open to all and every type of answer. We are happy to have quick, one-lin= e > answers or deeply-considered essays. >=20 > What do you think? >=20 > Thanks for all your input, > Adrian and Alia >=20 > PS Please respond to both aliases because not everyone is on both lists. = Sorry > that that means some of you will get duplicates. >=20 >=20 From nobody Sat Mar 22 03:03:37 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4391A05D3; Fri, 21 Mar 2014 20:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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.547, 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 JS1TebxrPCkW; Fri, 21 Mar 2014 20:35:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7E51A0850; Fri, 21 Mar 2014 20:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1226; q=dns/txt; s=iport; t=1395459318; x=1396668918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AWPzg5TzzDwYoer0dwIXi68Y5kzrcNgk6NuEJ5ahLbI=; b=KgfxrO1MJF0yVrMYiB9HIRo2EZ6z4nqfKoX7Ao/zCOFYZGZyN+d7U6a3 81uLmOIWN3pgyeCoeMR4+MPP1G8iXKkywd86MbOekKDQYJQfwddF7OP8x frF86TC+lj91gKYC60RSndLEwJ12dmZZyU4j7VgXKIK9gfp0k3thyiIfV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHwELVOtJXG//2dsb2JhbABZgmUhgRLCZYEWFnSCJQEBAQQ6PwwEAgEIEQQBAQsUCQcyFAkIAQEEAQ0FCBGHYAHOVxeOOTEHBoMegRQBA6p6gy2CKw X-IronPort-AV: E=Sophos;i="4.97,707,1389744000"; d="scan'208";a="29479304" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 22 Mar 2014 03:35:17 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2M3ZHIP030237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 03:35:17 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 22:35:17 -0500 From: "Nobo Akiya (nobo)" To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAStk9g Date: Sat, 22 Mar 2014 03:35:17 +0000 Message-ID: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/zFkZnyesRucnj-0ZDnkqY_IyTaw X-Mailman-Approved-At: Sat, 22 Mar 2014 03:03:33 -0700 Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 03:35:29 -0000 Hi Adrian, Alia, Require drafts to place more emphasis on OAM to minimize OAM needing to pl= ay the catch-up game later. Regards, Nobo > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Friday, March 21, 2014 2:31 PM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Cc: Alia Atlas > Subject: Routing Area Health Check >=20 > Hello Directorate and WG chairs, >=20 > Alia and I have been discussing the Routing Area, its work, its output, a= nd its > working groups. >=20 > We have reached a conclusion (which perhaps we should have come to > sooner) that we need your help and input. >=20 > The crunch question for us is "What makes it hard to get work done in the > Routing Area?" What gets in the way of your work? What is making life har= d > for document authors? How could working groups be doing better? We are > open to all and every type of answer. We are happy to have quick, one-lin= e > answers or deeply-considered essays. >=20 > What do you think? >=20 > Thanks for all your input, > Adrian and Alia >=20 > PS Please respond to both aliases because not everyone is on both lists. > Sorry that that means some of you will get duplicates. From nobody Sat Mar 22 03:15:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 619FE1A06AB; Sat, 22 Mar 2014 03:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[T_RP_MATCHES_RCVD=-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 ubGayR1UmKgi; Sat, 22 Mar 2014 03:15:26 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 43C171A05D1; Sat, 22 Mar 2014 03:15:26 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 62B231802AB1; Sat, 22 Mar 2014 11:15:25 +0100 (CET) Message-ID: <532D62BE.3040102@pi.nu> Date: Sat, 22 Mar 2014 11:15:26 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: John E Drake , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ZFI7OF-dUtcyInqq0Q0_k5RnPxM Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 10:15:28 -0000 John, How about deciding what is broken first, and then looking at the actions?? /Loa On 2014-03-21 21:44, John E Drake wrote: > Adrian, > > Combine IS-IS and OSPF > > Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there > > There is probably some synergy between PCE, SFC, and SPRING that needs to be exploited > > Combine BFD and the OAM/protection switching part of MPLS > > Close Secure IDR, FORCES, KARP, MANET, and NVO3 > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel >> Sent: Friday, March 21, 2014 11:31 AM >> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >> Cc: Alia Atlas >> Subject: [RTG-DIR] Routing Area Health Check >> >> Hello Directorate and WG chairs, >> >> Alia and I have been discussing the Routing Area, its work, its output, and its >> working groups. >> >> We have reached a conclusion (which perhaps we should have come to sooner) >> that we need your help and input. >> >> The crunch question for us is "What makes it hard to get work done in the >> Routing Area?" What gets in the way of your work? What is making life hard >> for document authors? How could working groups be doing better? We are >> open to all and every type of answer. We are happy to have quick, one-line >> answers or deeply-considered essays. >> >> What do you think? >> >> Thanks for all your input, >> Adrian and Alia >> >> PS Please respond to both aliases because not everyone is on both lists. Sorry >> that that means some of you will get duplicates. >> >> > > -- 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 Mar 22 05:22:12 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194891A0968; Sat, 22 Mar 2014 05:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mL9bENl3imGK; Sat, 22 Mar 2014 05:22:09 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6E31A0960; Sat, 22 Mar 2014 05:22:08 -0700 (PDT) Received: from mail61-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.22; Sat, 22 Mar 2014 12:22:08 +0000 Received: from mail61-ch1 (localhost [127.0.0.1]) by mail61-ch1-R.bigfish.com (Postfix) with ESMTP id B2429200461; Sat, 22 Mar 2014 12:22:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz62a3I98dI9371I1b0aL936eI542I1dbaI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail61-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(252514010)(377454003)(377424004)(51704005)(13464003)(69224002)(189002)(199002)(81816001)(87266001)(2656002)(87936001)(80976001)(56776001)(54316002)(53806001)(93136001)(76482001)(54356001)(81686001)(51856001)(85306002)(85852003)(2201001)(92566001)(83072002)(56816005)(33646001)(90146001)(19580395003)(83322001)(19580405001)(81342001)(98676001)(81542001)(31966008)(74662001)(95666003)(47446002)(74502001)(95416001)(69226001)(94316002)(46102001)(86362001)(93516002)(47736001)(49866001)(50986001)(47976001)(4396001)(94946001)(76786001)(74316001)(97336001)(66066001)(77982001)(65816001)(76796001)(63696002)(59766001)(20776003)(74366001)(97186001)(74706001)(79102001)(76576001)(74876001)(80022001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB200; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:B41DD01C.ABF19309.C1DFBDBF.97C5E1BD.2034E; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail61-ch1 (localhost.localdomain [127.0.0.1]) by mail61-ch1 (MessageSwitch) id 1395490927111856_16966; Sat, 22 Mar 2014 12:22:07 +0000 (UTC) Received: from CH1EHSMHS026.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.249]) by mail61-ch1.bigfish.com (Postfix) with ESMTP id 1614226021C; Sat, 22 Mar 2014 12:22:07 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS026.bigfish.com (10.43.70.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 22 Mar 2014 12:22:06 +0000 Received: from BLUPR05MB200.namprd05.prod.outlook.com (10.255.191.14) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Sat, 22 Mar 2014 12:22:06 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB200.namprd05.prod.outlook.com (10.255.191.14) with Microsoft SMTP Server (TLS) id 15.0.898.11; Sat, 22 Mar 2014 12:22:05 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0898.005; Sat, 22 Mar 2014 12:22:05 +0000 From: John E Drake To: Loa Andersson , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQABx1xgAABGQpEA== Date: Sat, 22 Mar 2014 12:22:05 +0000 Message-ID: <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> In-Reply-To: <532D62BE.3040102@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 01583E185C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/oIO7AvkDV96q-daIyLHLlWN2aZA Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 12:22:11 -0000 Loa, That's what I did. Yours Irrespectively, John > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: Saturday, March 22, 2014 3:15 AM > To: John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.= org > Cc: Alia Atlas > Subject: Re: [RTG-DIR] Routing Area Health Check >=20 > John, >=20 > How about deciding what is broken first, and then looking at the actions?= ? >=20 > /Loa >=20 > On 2014-03-21 21:44, John E Drake wrote: > > Adrian, > > > > Combine IS-IS and OSPF > > > > Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there > > > > There is probably some synergy between PCE, SFC, and SPRING that needs > > to be exploited > > > > Combine BFD and the OAM/protection switching part of MPLS > > > > Close Secure IDR, FORCES, KARP, MANET, and NVO3 > > > > Yours Irrespectively, > > > > John > > > >> -----Original Message----- > >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian > >> Farrel > >> Sent: Friday, March 21, 2014 11:31 AM > >> To: rtg-dir@ietf.org; rtg-chairs@ietf.org > >> Cc: Alia Atlas > >> Subject: [RTG-DIR] Routing Area Health Check > >> > >> Hello Directorate and WG chairs, > >> > >> Alia and I have been discussing the Routing Area, its work, its > >> output, and its working groups. > >> > >> We have reached a conclusion (which perhaps we should have come to > >> sooner) that we need your help and input. > >> > >> The crunch question for us is "What makes it hard to get work done in > >> the Routing Area?" What gets in the way of your work? What is making > >> life hard for document authors? How could working groups be doing > >> better? We are open to all and every type of answer. We are happy to > >> have quick, one-line answers or deeply-considered essays. > >> > >> What do you think? > >> > >> Thanks for all your input, > >> Adrian and Alia > >> > >> PS Please respond to both aliases because not everyone is on both > >> lists. Sorry that that means some of you will get duplicates. > >> > >> > > > > >=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 From nobody Sat Mar 22 06:55:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA321A06E0; Sat, 22 Mar 2014 06:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 EXzKkzeuAGtn; Sat, 22 Mar 2014 06:55:05 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5313E1A0545; Sat, 22 Mar 2014 06:55:04 -0700 (PDT) Received: from c-98-251-8-237.hsd1.ga.comcast.net ([98.251.8.237]:54204 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WRMNv-0006SZ-Fn; Sat, 22 Mar 2014 13:54:51 +0000 From: "Russ White" To: "'John E Drake'" , "'Loa Andersson'" , , , References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> Date: Sat, 22 Mar 2014 09:54:40 -0400 Message-ID: <047201cf45d6$465e3250$d31a96f0$@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: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wGfr6KFARRJlhYCZgSzJZkuGPgA 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/rtg-dir/jbHfZDiONwYs-k71R3aV-T20Qng Cc: 'Alia Atlas' Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 13:55:06 -0000 > > > Combine IS-IS and OSPF I'm ambivalent about this... There is always an ebb and flow of work in these WG's -- and it's going to be hard to separate them once they're merged. OTOH, it does seem most of the work in both of these WGs is common right now, and combining them might result in some interesting ideas (a combined tlv for both protocols might be interesting). > > > Close Secure IDR, FORCES, KARP, MANET, and NVO3 SIDR has "finished," the RPKI, which could be folded into IDR, and the path protection stuff is a science experiment that isn't deployable in the real world. Suggest moving the path protection work into the routing research group until something that will actually provide some real protection comes along. > Require drafts to place more emphasis on OAM to minimize OAM needing to play the catch-up game later. An interesting idea... Maybe we need something more concrete here, though, like (as a rough start): require all new data structures in proposed standards (or experimentals) include a data model in YANG format -- or some such. :-) Russ From nobody Sat Mar 22 08:38:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17EE61A09B5; Sat, 22 Mar 2014 08:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 iyp7R4SVH9Rb; Sat, 22 Mar 2014 08:26:53 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD6A1A09B2; Sat, 22 Mar 2014 08:26:53 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id sa20so3816483veb.8 for ; Sat, 22 Mar 2014 08:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z/pLytho6xnZ8jsbt/SQ+zJTF1byG87hnSaYp6KCUgY=; b=m0vj9NoXsp/YPQD4n51swBwDPUro/qpSfmTQGjwOgeSWUYvnEktwBk1jU1JAk0Q2Jx OffNhMkgIt7p3MEHXljkmckY4kLdEA7KN1bFKkf6wQjJ/GX9bf6WgOwZaLDKHYgrgA3z 8vUoOuywC8Nxw45O2o6Io1NFRLoq4W+tDy6kIJq/5o7l4XzWwffmhBO4ENMp6o3lUm2g TIKXaRFsQOvCcWk84YQTYsnW1WsgoD5r6zkBPAxs3NWUzsoEGzNMkFUqBUOnAKM2mAHH c+djxpBBJpK45yoLw9Bg/xjSuV1FG4RY5BapsFZJxYorIuDyx82BYJmQkD56xFLif3eO vtTQ== MIME-Version: 1.0 X-Received: by 10.58.38.166 with SMTP id h6mr21589611vek.22.1395502013096; Sat, 22 Mar 2014 08:26:53 -0700 (PDT) Received: by 10.221.16.3 with HTTP; Sat, 22 Mar 2014 08:26:52 -0700 (PDT) In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Date: Sat, 22 Mar 2014 12:26:52 -0300 Message-ID: From: Ines Robles To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e013a0d40c6337e04f533a1ad Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/OBwFTYAaF_T_FpSqzhkMaXFX9-s X-Mailman-Approved-At: Sat, 22 Mar 2014 08:38:28 -0700 Cc: rtg-dir@ietf.org, Alia Atlas , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 15:26:56 -0000 --089e013a0d40c6337e04f533a1ad Content-Type: text/plain; charset=ISO-8859-1 *Hi, About this: ""What is making life hard for document authors? How could working groups be doing better?" I was thinking that maybe having some kind of fast checklist for the authors, which they can follow to know about the process on their documents. E.g.: When a new draft is submitted a checklist could be displayed to download. In the checklist: "Before complete this checklist, please be sure, that you have read RFC(list of related RFCs with the IETF process.....) Checklist: When a new work is presented: * Did I express my work's intention in the ML? * Did I find how it is related with the current charter? Should I propose recharter, Why? * Did I present to the ML some implementations about it? * Did I attend to a document language session in the IETF? (for not native english speaker) ..... When a work is ready to be published: * Did I address the SecDir review? * Did I address the Gen-art review? * Did I address all open tickets? ....." It would not replace the useful and necessary work of the Doc. Shepherds, it should give just a fast review by the authors for themselves. Considering that the authors are very busy most of the time, it should be a fast checklist, with the main points to be considered. It is just an idea, I hope you can find it useful :-) Thanks and Regards, Ines.* 2014-03-21 15:31 GMT-03:00 Adrian Farrel : > Hello Directorate and WG chairs, > > Alia and I have been discussing the Routing Area, its work, its output, > and its > working groups. > > We have reached a conclusion (which perhaps we should have come to sooner) > that > we need your help and input. > > The crunch question for us is "What makes it hard to get work done in the > Routing Area?" What gets in the way of your work? What is making life hard > for > document authors? How could working groups be doing better? We are open to > all > and every type of answer. We are happy to have quick, one-line answers or > deeply-considered essays. > > What do you think? > > Thanks for all your input, > Adrian and Alia > > PS Please respond to both aliases because not everyone is on both lists. > Sorry > that that means some of you will get duplicates. > > --089e013a0d40c6337e04f533a1ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,


About this: “”What is making life hard for document authors? How could working g= roups be doing better?

I was thinking that maybe having some kind = of fast checklist for the authors, which they can follow to know about the = process on their documents.


E.g.:


When a new draft is submitted a checklist c= ould be displayed to download.


In the checklist:


“Before complete this checklist, plea= se be sure, that you have read RFC(list of related RFCs with the IETF proce= ss…..)


Checklist:

= When a new work is presente= d:

= * Did I express my work&rsq= uo;s intention in the ML?

= * Did I find how it is rela= ted with the current charter? Should I propose recharter, Why?

= * Did I present to the ML s= ome implementations about it?

= * Did I attend to a documen= t language session in the IETF? (for not native english speaker)

= …..

= When a work is ready to be = published:

= * Did I address the SecDir = review?

= * Did I address the Gen-art= review?

= * Did I address all open ti= ckets?

= …..”

It would not replace the useful and necessa= ry work of the Doc. Shepherds, it should give just a fast review by the aut= hors for themselves.


Considering that the authors are very busy = most of the time, it should be a fast checklist, with the main points to be= considered.


It is just an idea, I hope you can find it = useful :-)


Thanks and Regards,


Ines.


2014-03-21 15= :31 GMT-03:00 Adrian Farrel <adrian@olddog.co.uk>:
Hello Directorate and WG chairs,

Alia and I have been discussing the Routing Area, its work, its output, and= its
working groups.

We have reached a conclusion (which perhaps we should have come to sooner) = that
we need your help and input.

The crunch question for us is "What makes it hard to get work done in = the
Routing Area?" What gets in the way of your work? What is making life = hard for
document authors? How could working groups be doing better? We are open to = all
and every type of answer. We are happy to have quick, one-line answers or deeply-considered essays.

What do you think?

Thanks for all your input,
Adrian and Alia

PS Please respond to both aliases because not everyone is on both lists. So= rry
that that means some of you will get duplicates.


--089e013a0d40c6337e04f533a1ad-- From nobody Sat Mar 22 09:55:33 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295F61A047D; Sat, 22 Mar 2014 09:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 9jDgN8VrxM_G; Sat, 22 Mar 2014 09:55:30 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1921A0128; Sat, 22 Mar 2014 09:55:30 -0700 (PDT) Received: from c-98-251-8-237.hsd1.ga.comcast.net ([98.251.8.237]:51308 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WRPCb-0007hD-Vk; Sat, 22 Mar 2014 16:55:22 +0000 From: "Russ White" To: "'Ines Robles'" , "'Adrian Farrel'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: Date: Sat, 22 Mar 2014 12:55:12 -0400 Message-ID: <007001cf45ef$7e3b0090$7ab101b0$@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: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wJ1AFd2mUNykaA= 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/rtg-dir/P_xuFlNneL-BY68SL_Atncaj1-I Cc: rtg-dir@ietf.org, 'Alia Atlas' , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 16:55:32 -0000 > About this: ""What is making life hard for document authors? How could > working groups be doing better?" Another point we might want to consider is whether or not we should be at least something proactive about the language barrier issues -- like making certain the community knows the RG-DIR is open to helping folks with issues on the language side, or even to provide a "non-native speaker review." This might help improve the output of the area as a whole (?). :-) Russ From nobody Sat Mar 22 10:01:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D011A06D2; Sat, 22 Mar 2014 10:01:27 -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 DxiB1ieeGgtb; Sat, 22 Mar 2014 10:01:25 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF871A0128; Sat, 22 Mar 2014 10:01:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 812DA1CA7002; Sat, 22 Mar 2014 10:01:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-57.clppva.east.verizon.net [70.106.134.57]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6CC221CA7000; Sat, 22 Mar 2014 10:01:24 -0700 (PDT) Message-ID: <532DC1E3.3000807@joelhalpern.com> Date: Sat, 22 Mar 2014 13:01:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: John E Drake , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> In-Reply-To: <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/n4aN0XTsSQRGl_H5SanTcN7voVs Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 17:01:27 -0000 John, Despite your asserting that you had decided what was broken, I can not see the relationship between your asserted fixes and any of the questions in Adrian's initial note. I can guess, for example, that you think the number of working groups is itself a problem. But that is a guess. You don't even assert it, much less justify it. Yours, Joel On 3/22/14, 8:22 AM, John E Drake wrote: > Loa, > > That's what I did. > > Yours Irrespectively, > > John > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: Saturday, March 22, 2014 3:15 AM >> To: John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org >> Cc: Alia Atlas >> Subject: Re: [RTG-DIR] Routing Area Health Check >> >> John, >> >> How about deciding what is broken first, and then looking at the actions?? >> >> /Loa >> >> On 2014-03-21 21:44, John E Drake wrote: >>> Adrian, >>> >>> Combine IS-IS and OSPF >>> >>> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >>> >>> There is probably some synergy between PCE, SFC, and SPRING that needs >>> to be exploited >>> >>> Combine BFD and the OAM/protection switching part of MPLS >>> >>> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>> Farrel >>>> Sent: Friday, March 21, 2014 11:31 AM >>>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>>> Cc: Alia Atlas >>>> Subject: [RTG-DIR] Routing Area Health Check >>>> >>>> Hello Directorate and WG chairs, >>>> >>>> Alia and I have been discussing the Routing Area, its work, its >>>> output, and its working groups. >>>> >>>> We have reached a conclusion (which perhaps we should have come to >>>> sooner) that we need your help and input. >>>> >>>> The crunch question for us is "What makes it hard to get work done in >>>> the Routing Area?" What gets in the way of your work? What is making >>>> life hard for document authors? How could working groups be doing >>>> better? We are open to all and every type of answer. We are happy to >>>> have quick, one-line answers or deeply-considered essays. >>>> >>>> What do you think? >>>> >>>> Thanks for all your input, >>>> Adrian and Alia >>>> >>>> PS Please respond to both aliases because not everyone is on both >>>> lists. Sorry that that means some of you will get duplicates. >>>> >>>> >>> >>> >> >> -- >> >> >> 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 Mar 22 10:26:38 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B461A08ED; Sat, 22 Mar 2014 10:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 UAGQ-wDhlBPc; Sat, 22 Mar 2014 10:26:36 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB31A0709; Sat, 22 Mar 2014 10:26:36 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id r5so4191364qcx.4 for ; Sat, 22 Mar 2014 10:26:36 -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=quJW8IKb7TdPtROvVhzTBQsUR71HF7XAHCJ1JH7Yzq4=; b=v+29YPBeTZMFOFHwqhwK/PV6c5oUEJcg/C2rZ4mipXztlJaq+f4z39GXfJUYeeld02 YqwyD5iTBB0R132H7zpKFEzqF6H2Z0Vy0K9egKDgaTbaqQhRrldZN7emmnpwS+vvmhxL gIO5dpjQlm+fj2tpvMgx6mfeZbd52V0iddAihS7Ddlg+M/qvKHYRe9eWR6ArYE7A4gKC 4FmfHlnL2zh4ZojqxH58NyNigQ/5b0XexKXzMXEmAnyfYjOromRaakGP+KIX2Sd25fn8 1PIytZ2MJvIzJKEFmzazffl/E5cAxgIw6dm6djIsO104IjZ7FZppPbjPkN8MG5WQ6xiI MjPQ== X-Received: by 10.224.163.12 with SMTP id y12mr15521599qax.25.1395509195975; Sat, 22 Mar 2014 10:26:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Sat, 22 Mar 2014 10:26:15 -0700 (PDT) In-Reply-To: <007001cf45ef$7e3b0090$7ab101b0$@riw.us> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> From: "Andrew G. Malis" Date: Sat, 22 Mar 2014 18:26:15 +0100 Message-ID: To: Russ White Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/CEYcAgC_4ZCCGTnKRuARN2-bxVM Cc: Adrian Farrel , Ines Robles , Alia Atlas , rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 17:26:38 -0000 I recently did some language editing on a draft I was technically reviewing for the Independent Series Editor (the author wasn't a native English speaker). Perhaps we could put together a list of area volunteers that are willing to do a language cleanup pass on drafts that could use it just before they go into WG LC. You wouldn't want to do it any earlier. Cheers, Andy On Sat, Mar 22, 2014 at 5:55 PM, Russ White wrote: > >> About this: ""What is making life hard for document authors? How could >> working groups be doing better?" > > Another point we might want to consider is whether or not we should be at > least something proactive about the language barrier issues -- like making > certain the community knows the RG-DIR is open to helping folks with issues > on the language side, or even to provide a "non-native speaker review." This > might help improve the output of the area as a whole (?). > > :-) > > Russ > > > From nobody Sat Mar 22 10:28:54 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8651A08E9; Sat, 22 Mar 2014 10:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 VTGcEE74H4Hq; Sat, 22 Mar 2014 10:28:52 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 92AB81A08CD; Sat, 22 Mar 2014 10:28:52 -0700 (PDT) Received: from c-98-251-8-237.hsd1.ga.comcast.net ([98.251.8.237]:64320 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WRPj0-0008Am-Qv; Sat, 22 Mar 2014 17:28:51 +0000 From: "Russ White" To: "'Andrew G. Malis'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> In-Reply-To: Date: Sat, 22 Mar 2014 13:28:40 -0400 Message-ID: <00b201cf45f4$2b975af0$82c610d0$@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: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wJ1AFd2AS7Sf84BzqowQZkrkjhQ 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/rtg-dir/nvsdaRBSIQwIxbXW5K9FjtwEUBA Cc: 'Adrian Farrel' , 'Ines Robles' , 'Alia Atlas' , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 17:28:54 -0000 > I recently did some language editing on a draft I was technically reviewing for > the Independent Series Editor (the author wasn't a native English speaker). > Perhaps we could put together a list of area volunteers that are willing to do > a language cleanup pass on drafts that could use it just before they go into > WG LC. You wouldn't want to do it any earlier. I'd be glad to help out with this... :-) Russ From nobody Sat Mar 22 10:38:06 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310421A0709; Sat, 22 Mar 2014 10:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.345 X-Spam-Level: ** X-Spam-Status: No, score=2.345 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DOS_OUTLOOK_TO_MX=2.845] 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 n2C-1v7nSANG; Sat, 22 Mar 2014 10:38:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 01D901A08CD; Sat, 22 Mar 2014 10:38:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Russ White'" , "'Andrew G. Malis'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> <00b201cf45f4$2b975af0$82c610d0$@riw.us> In-Reply-To: <00b201cf45f4$2b975af0$82c610d0$@riw.us> Date: Sat, 22 Mar 2014 13:37:51 -0400 Message-ID: <002401cf45f5$73b17ef0$5b147cd0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wJ1AFd2AS7Sf84BzqowQQJfzXn+mRiWWwA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/qwdVA9lhu8Y5kXACHd3J-LuWnXg Cc: 'Adrian Farrel' , 'Ines Robles' , 'Alia Atlas' , rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 17:38:04 -0000 Andy and Russ I will be glad to help out as well. Sue From nobody Sat Mar 22 11:44:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC11A09BF; Sat, 22 Mar 2014 11:44:51 -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 qaR6wRjj2R_W; Sat, 22 Mar 2014 11:44:49 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id D4F211A09BD; Sat, 22 Mar 2014 11:44:48 -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 s2MIikng029089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Mar 2014 13:44:47 -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 s2MIijjC009278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 19:44:45 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sat, 22 Mar 2014 19:44:45 +0100 From: "Papadimitriou, Dimitri (Dimitri)" To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAv05Dw Date: Sat, 22 Mar 2014 18:44:44 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF8308B57E65@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/-zhRmwZTNhNcFpnE70oogQ9kYwA Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 18:44:51 -0000 Hi, I may see a couple elements: - Protocol evolution: one starts with a basic specification and progressive= ly come up with evolutions in separate documents that come with their own e= xtensions, etc. while there are very few documents providing global picture= or tentatives to consolidate the protocol specifications; the dependency g= raph may help but remains limited.=20 - RFC document results of sometimes complex reasoning which may remain undo= cumented -> those that were part of the inner-discussions know why, newcome= rs not necessarily. I would also state here that the format/messaging part = is often taking over the procedural part in description. - Are emails/ftp still the best way to exchange technical content ? in part= icular reviewing/updating documents ? Once reaching working group status it= could be valuable to progress documents with collaborative writing tools. Thanks, -dimitri. > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farre= l > Sent: Friday, March 21, 2014 19:31 > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Cc: Alia Atlas > Subject: [RTG-DIR] Routing Area Health Check >=20 > Hello Directorate and WG chairs, >=20 > Alia and I have been discussing the Routing Area, its work, its output, > and its > working groups. >=20 > We have reached a conclusion (which perhaps we should have come to sooner= ) > that > we need your help and input. >=20 > The crunch question for us is "What makes it hard to get work done in the > Routing Area?" What gets in the way of your work? What is making life har= d > for > document authors? How could working groups be doing better? We are open t= o > all > and every type of answer. We are happy to have quick, one-line answers or > deeply-considered essays. >=20 > What do you think? >=20 > Thanks for all your input, > Adrian and Alia >=20 > PS Please respond to both aliases because not everyone is on both lists. > Sorry > that that means some of you will get duplicates. From nobody Sat Mar 22 11:45:39 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528E41A09E0 for ; Sat, 22 Mar 2014 11:45:38 -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 H5P8bkiP5avA for ; Sat, 22 Mar 2014 11:45:36 -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 955DB1A09BD for ; Sat, 22 Mar 2014 11:45:36 -0700 (PDT) Received: (qmail 32487 invoked by uid 0); 22 Mar 2014 18:45:36 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 22 Mar 2014 18:45:36 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id gilW1n00h2SSUrH01ilZCf; Sat, 22 Mar 2014 12:45:35 -0600 X-Authority-Analysis: v=2.1 cv=ar4hV0pV 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=WspU9PCzxMAA:10 a=HFCU6gKsb0MA:10 a=kj9zAlcOel0A:10 a=wU2YTnxGAAAA:8 a=-NfooI8aBGcA:10 a=pGLkceISAAAA:8 a=CBXcPCjeXSAM2lC6HEAA:9 a=CjuIK1q_8ugA:10 a=MSl-tDqOz04A:10 a=EJ_lzN1bkxcA: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=JhlZP6d1ZBhxIZwYywNqZEb7m3J2JbxsW3PmOuphEzs=; b=SlrBGM5CrmKnd5Fs/UAZDq3EzGD8ESKP/+f8BPJGXrTqD3cxAN4CBMYi62zTW9f/voeXQ5LOu0/5ubHSeFtKmU5owFwDOdORG8Jcros8MNFy3rslI9W5iSYhZHhKoWLu; Received: from [70.192.198.89] (port=8658 helo=[10.180.160.161]) by box313.bluehost.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1WRQvD-0005x6-Bt; Sat, 22 Mar 2014 12:45:31 -0600 From: Lou Berger To: "Andrew G. Malis" , Russ White Date: Sat, 22 Mar 2014 14:45:29 -0400 Message-ID: <144eaf73f20.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 AquaMail/1.3.8 (build: 2100414) 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.198.89 authed with lberger@labn.net} Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/1ER9nw0kEnMeaUAX1iE1yCzex34 Cc: Adrian Farrel , Ines Robles , Alia Atlas , rtg-chairs@ietf.org, rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 18:45:38 -0000 This is a great idea. Lou On March 22, 2014 1:28:15 PM "Andrew G. Malis" wrote: > I recently did some language editing on a draft I was technically > reviewing for the Independent Series Editor (the author wasn't a > native English speaker). Perhaps we could put together a list of area > volunteers that are willing to do a language cleanup pass on drafts > that could use it just before they go into WG LC. You wouldn't want to > do it any earlier. > > Cheers, > Andy > > On Sat, Mar 22, 2014 at 5:55 PM, Russ White wrote: > > > >> About this: ""What is making life hard for document authors? How could > >> working groups be doing better?" > > > > Another point we might want to consider is whether or not we should be at > > least something proactive about the language barrier issues -- like making > > certain the community knows the RG-DIR is open to helping folks with issues > > on the language side, or even to provide a "non-native speaker review." This > > might help improve the output of the area as a whole (?). > > > > :-) > > > > Russ > > > > > > > From nobody Sat Mar 22 12:11:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B381A09F1; Sat, 22 Mar 2014 12:11:22 -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 lAe8g_SLLMaO; Sat, 22 Mar 2014 12:11:16 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEBC1A0906; Sat, 22 Mar 2014 12:11:15 -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 s2MJBEST007037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 22 Mar 2014 14:11:15 -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 s2MJBCYZ010552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 20:11:13 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.10]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sat, 22 Mar 2014 20:11:12 +0100 From: "Papadimitriou, Dimitri (Dimitri)" To: Russ White , "'John E Drake'" , "'Loa Andersson'" , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQABpdVQAABGxXgAADO8IAAAze3PA= Date: Sat, 22 Mar 2014 19:11:11 +0000 Message-ID: <84675BAA8C49154AB81E2587BE8BDF8308B57E9F@FR711WXCHMBA07.zeu.alcatel-lucent.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> <047201cf45d6$465e3250$d31a96f0$@riw.us> In-Reply-To: <047201cf45d6$465e3250$d31a96f0$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Xwmk76TPLM8JzRvFMI3SJUcNElQ Cc: 'Alia Atlas' Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 19:11:23 -0000 > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Russ White > Sent: Saturday, March 22, 2014 14:55 > To: 'John E Drake'; 'Loa Andersson'; adrian@olddog.co.uk; rtg- > dir@ietf.org; rtg-chairs@ietf.org > Cc: 'Alia Atlas' > Subject: Re: [RTG-DIR] Routing Area Health Check >=20 >=20 > > > > Combine IS-IS and OSPF >=20 > I'm ambivalent about this... There is always an ebb and flow of work in > these WG's -- and it's going to be hard to separate them once they're > merged. OTOH, it does seem most of the work in both of these WGs is commo= n > right now, and combining them might result in some interesting ideas (a > combined tlv for both protocols might be interesting). >=20 > > > > Close Secure IDR, FORCES, KARP, MANET, and NVO3 >=20 > SIDR has "finished," the RPKI, which could be folded into IDR, and the > path > protection stuff is a science experiment that isn't deployable in the rea= l > world. Suggest moving the path protection work into the routing research > group until something that will actually provide some real protection > comes along. ... I think the problem is broader here, how to ensure a better cooperation= with RRG (bidirectional) There is closer relation between ICCRG (with groups transport and congestio= n control) and TSV Area so we could certainly do better here. Thanks, -d. > > Require drafts to place more emphasis on OAM to minimize OAM needing t= o > play the catch-up game later. >=20 > An interesting idea... Maybe we need something more concrete here, though= , > like (as a rough start): require all new data structures in proposed > standards (or experimentals) include a data model in YANG format -- or > some > such. >=20 > :-) >=20 > Russ From nobody Sat Mar 22 15:18:28 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA731A08BD; Sat, 22 Mar 2014 15:18:27 -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, 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 chtTSMpqqG5V; Sat, 22 Mar 2014 15:18:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C82EF1A076D; Sat, 22 Mar 2014 15:18:24 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-a3-532e093e5d71 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E8.6F.11484.F390E235; Sat, 22 Mar 2014 23:05:51 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0387.000; Sat, 22 Mar 2014 18:18:13 -0400 From: Acee Lindem To: Loa Andersson , John E Drake , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQACTXiwAACpRvAA== Date: Sat, 22 Mar 2014 22:18:12 +0000 Message-ID: In-Reply-To: <532D62BE.3040102@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonXNeeUy/Y4OMjEYsfPTeYLb5eS7OY c9fZ4t/cOcwWDw4vZLNYsOYpuwObx5IlP5k8rjddZfdYsXklo8es6W1sASxRXDYpqTmZZalF +nYJXBmvd89lL7gmUHHz1HHGBsZPPF2MnBwSAiYSK35+YIewxSQu3FvP1sXIxSEkcIRR4tGD 1ewQznJGiZfTdzODVLEJ6Eg8f/SPGSQhInCUUWLx6RNgCWYBFYnePT+ZQGxhAQOJj/8vM4LY IgKGEk/3rWSCsJ0ktv35AWazCKhKPNm4AKyGV8BU4urHaSwgNidQ/OH1c2A1jEAnfT+1hgli vrjErSfzmSBOFZBYsuc8M4QtKvHy8T9WEFtUQE+ie9ZyVoi4ksSc19egbtORWLD7ExuEbS1x q/09O4StLbFs4WtmiBsEJU7OfMIygVF8FpJ1s5C0z0LSPgtJ+ywk7QsYWVcxcpQWp5blphsZ bmIERuQxCTbHHYwLPlkeYpTmYFES5/3y1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+MG thdsxw2c9u51zODRXvCWPbZbdBOXD/f5sHn5x71P+XXtuMRoFrcjROeZROHPmhk2BvuOLmBN XK610exsZxTLjmulLKsfrHmfemxJ/Kc/5j/73fi9Zt84LNhr7jDt15mja+Qt1H86Pf8c+d9y xe8D9s9KjfYyLP4ubrx59zGT36mToravEH+uxFKckWioxVxUnAgAcyzi/JYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/9bDmJz6WA6J2oRVPbp7ZhmvMAAI Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 22:18:27 -0000 I agree with Loa that the problem needs to be defined - this discussion has already diverged into 4 different directions. Thanks, Acee=20 On 3/22/14 3:15 AM, "Loa Andersson" wrote: >John, > >How about deciding what is broken first, and then looking at the >actions?? > >/Loa > >On 2014-03-21 21:44, John E Drake wrote: >> Adrian, >> >> Combine IS-IS and OSPF >> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >> >> There is probably some synergy between PCE, SFC, and SPRING that needs >>to be exploited >> >> Combine BFD and the OAM/protection switching part of MPLS >> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>Farrel >>> Sent: Friday, March 21, 2014 11:31 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Cc: Alia Atlas >>> Subject: [RTG-DIR] Routing Area Health Check >>> >>> Hello Directorate and WG chairs, >>> >>> Alia and I have been discussing the Routing Area, its work, its >>>output, and its >>> working groups. >>> >>> We have reached a conclusion (which perhaps we should have come to >>>sooner) >>> that we need your help and input. >>> >>> The crunch question for us is "What makes it hard to get work done in >>>the >>> Routing Area?" What gets in the way of your work? What is making life >>>hard >>> for document authors? How could working groups be doing better? We are >>> open to all and every type of answer. We are happy to have quick, >>>one-line >>> answers or deeply-considered essays. >>> >>> What do you think? >>> >>> Thanks for all your input, >>> Adrian and Alia >>> >>> PS Please respond to both aliases because not everyone is on both >>>lists. Sorry >>> that that means some of you will get duplicates. >>> >>> >> >> > >--=20 > > >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 Mar 22 15:48:29 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600241A6EE4; Sat, 22 Mar 2014 15:48:26 -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 Kv8wZwlblWm3; Sat, 22 Mar 2014 15:48:23 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AF6371A6EDE; Sat, 22 Mar 2014 15:48:22 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so10504839ykp.1 for ; Sat, 22 Mar 2014 15:48:22 -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=3dNYoh8qeRa+IU4DAC7HVw/uJb3YCuF9skdQXC383PE=; b=A7rQSDq5jvZfXWwYsSlKAYgcsGvmqZIO9Lvcv6L33r2QtCjM1Ky579jATg2PBwR7VZ zx1b2AzktUZNVNM7c2ykRW0Le447czBG6JJ8MI/6g+uALXFga0ovdtOoIA3qGORJQ0z7 1R1qTFZIIwxdiZnmM69UL9AkKHcHX2QFsb1ZrtE+0ygcHKHWSvF1YVEC3iVWKmbvuAyE /OgQCwSeDYFjdNSVHPdPKqXxk8EwpRWyYC/275iYxrDTWiY5S82wQas4jwYk5A4RKvDZ X7PV2fjq7+uFOd67Y6GcxAO1RyRbYR4UnqPHZ3FrDvp8LjbbNR0Y9iWvRHrSiGRhet/l iUjA== MIME-Version: 1.0 X-Received: by 10.236.11.113 with SMTP id 77mr76921895yhw.70.1395528502427; Sat, 22 Mar 2014 15:48:22 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Sat, 22 Mar 2014 15:48:22 -0700 (PDT) In-Reply-To: References: <532D62BE.3040102@pi.nu> Date: Sat, 22 Mar 2014 18:48:22 -0400 Message-ID: From: Alia Atlas To: Acee Lindem Content-Type: multipart/alternative; boundary=001a11381bdea9802f04f539ccdd Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/tWawKrG1AeK3HN11PCCp8YvfdG4 Cc: John E Drake , "rtg-dir@ietf.org" , Alia Atlas , "rtg-chairs@ietf.org" , "adrian@olddog.co.uk" , Loa Andersson Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 22:48:26 -0000 --001a11381bdea9802f04f539ccdd Content-Type: text/plain; charset=ISO-8859-1 Acee, None of those different directions seems to me to be bad. The question was deliberately ask unframed and undefined. Adrian and I will define and frame it more - but first we wanted to hear the unframed but thoughtful discussion. Providing reasoning does help everyone determine if they are on the same page. Regards, Alia On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem wrote: > I agree with Loa that the problem needs to be defined - this discussion > has already diverged into 4 different directions. > > Thanks, > Acee > > On 3/22/14 3:15 AM, "Loa Andersson" wrote: > > >John, > > > >How about deciding what is broken first, and then looking at the > >actions?? > > > >/Loa > > > >On 2014-03-21 21:44, John E Drake wrote: > >> Adrian, > >> > >> Combine IS-IS and OSPF > >> > >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there > >> > >> There is probably some synergy between PCE, SFC, and SPRING that needs > >>to be exploited > >> > >> Combine BFD and the OAM/protection switching part of MPLS > >> > >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> -----Original Message----- > >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian > >>>Farrel > >>> Sent: Friday, March 21, 2014 11:31 AM > >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org > >>> Cc: Alia Atlas > >>> Subject: [RTG-DIR] Routing Area Health Check > >>> > >>> Hello Directorate and WG chairs, > >>> > >>> Alia and I have been discussing the Routing Area, its work, its > >>>output, and its > >>> working groups. > >>> > >>> We have reached a conclusion (which perhaps we should have come to > >>>sooner) > >>> that we need your help and input. > >>> > >>> The crunch question for us is "What makes it hard to get work done in > >>>the > >>> Routing Area?" What gets in the way of your work? What is making life > >>>hard > >>> for document authors? How could working groups be doing better? We are > >>> open to all and every type of answer. We are happy to have quick, > >>>one-line > >>> answers or deeply-considered essays. > >>> > >>> What do you think? > >>> > >>> Thanks for all your input, > >>> Adrian and Alia > >>> > >>> PS Please respond to both aliases because not everyone is on both > >>>lists. Sorry > >>> that that means some of you will get duplicates. > >>> > >>> > >> > >> > > > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > --001a11381bdea9802f04f539ccdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Acee,

None of those different direction= s seems to me to be bad.
The question was deliberately ask unfram= ed and undefined.
Adrian and I will define and frame it more - bu= t first we wanted=A0
to hear the unframed but thoughtful discussion.

Providing reasoning does help everyone determine if they are
o= n the same page.

Regards,
Alia


On Sat,= Mar 22, 2014 at 6:18 PM, Acee Lindem <acee.lindem@ericsson.com= > wrote:
I agree with Loa that the problem needs to b= e defined - this discussion
has already diverged into 4 different directions.

Thanks,
Acee

On 3/22/14 3:15 AM, "Loa Andersson" <loa@pi.nu> wrote:

>John,
>
>How about deciding what is broken first, and then looking at the
>actions??
>
>/Loa
>
>On 2014-03-21 21:44, John E Drake wrote:
>> Adrian,
>>
>> Combine IS-IS and OSPF
>>
>> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work the= re
>>
>> There is probably some synergy between PCE, SFC, and SPRING that n= eeds
>>to be exploited
>>
>> Combine BFD and the OAM/protection switching part of MPLS
>>
>> Close Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, March 21, 2014 11:31 AM
>>> To: rtg-dir@ietf.org; = rtg-chairs@ietf.org
>>> Cc: Alia Atlas
>>> Subject: [RTG-DIR] Routing Area Health Check
>>>
>>> Hello Directorate and WG chairs,
>>>
>>> Alia and I have been discussing the Routing Area, its work, it= s
>>>output, and its
>>> working groups.
>>>
>>> We have reached a conclusion (which perhaps we should have com= e to
>>>sooner)
>>> that we need your help and input.
>>>
>>> The crunch question for us is "What makes it hard to get = work done in
>>>the
>>> Routing Area?" What gets in the way of your work? What is= making life
>>>hard
>>> for document authors? How could working groups be doing better= ? We are
>>> open to all and every type of answer. We are happy to have qui= ck,
>>>one-line
>>> answers or deeply-considered essays.
>>>
>>> What do you think?
>>>
>>> Thanks for all your input,
>>> Adrian and Alia
>>>
>>> PS Please respond to both aliases because not everyone is on b= oth
>>>lists. Sorry
>>> that that means some of you will get duplicates.
>>>
>>>
>>
>>
>
>--
>
>
>Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
>Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<= a href=3D"mailto:loa@pi.nu">loa@pi.nu
>Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
>


--001a11381bdea9802f04f539ccdd-- From nobody Sun Mar 23 01:12:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6691A0A1E; Sat, 22 Mar 2014 15:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CVHn0vOiD6yn; Sat, 22 Mar 2014 15:09:30 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id C92F71A0A0F; Sat, 22 Mar 2014 15:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1337; q=dns/txt; s=iport; t=1395526169; x=1396735769; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VCNpWth7HLi0YiVDHJHmL4Ml1f9XXAbSaTsJNioxjUY=; b=T+KB2x4yv2hZUJoStDMNNweSOQHnVx68W62Pe+LmjVQ02UFHl/Sbu3JS A19/UVeCyHzI90Zz6UsaArurprcS98j/yy+j8TXQDu55WCCRHnBmicab2 /2mtUw9/M5G5k9qJI+dKOKCKB9xKeZyzrepczuOz0FgOpofAuatqRMqyU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABoJLlOtJXHA/2dsb2JhbABYgmUhO1fCbYEVFnSCJQEBAQMBOj8QAgEIIhQQMiUBAQQBDQ0Th1YIAQzNdReOSTEHgySBFASZfJB/gy2CKw X-IronPort-AV: E=Sophos;i="4.97,711,1389744000"; d="scan'208";a="29597205" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 22 Mar 2014 22:09:28 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2MM9SGK002760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 22 Mar 2014 22:09:28 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Sat, 22 Mar 2014 17:09:28 -0500 From: "Nobo Akiya (nobo)" To: Russ White , "'John E Drake'" , "'Loa Andersson'" , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQACbv/AAABGxXgAADO8IAAAXNhfA= Date: Sat, 22 Mar 2014 22:09:27 +0000 Message-ID: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> <047201cf45d6$465e3250$d31a96f0$@riw.us> In-Reply-To: <047201cf45d6$465e3250$d31a96f0$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.81] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/6ufXjUuhVU-87RuBjZ7oOEvEmF4 X-Mailman-Approved-At: Sun, 23 Mar 2014 01:12:51 -0700 Cc: 'Alia Atlas' Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 22:09:32 -0000 > > Require drafts to place more emphasis on OAM to minimize OAM needing > > to > play the catch-up game later. >=20 > An interesting idea... Maybe we need something more concrete here, > though, like (as a rough start): require all new data structures in propo= sed > standards (or experimentals) include a data model in YANG format -- or > some such. >=20 > :-) >=20 > Russ Requiring data model (MIB/YANG) wasn't what I had in mind, although that it= self is an interesting idea. I was thinking more from different angle. Picking on recent specific. http://datatracker.ietf.org/doc/draft-ietf-mpls-rsvp-ingress-protection/?in= clude_text=3D1 Ra should be able to detect the failure of R1 and switch the traffic within 10s of ms. The exact method by which Ra does so is out of scope. How? Ra cannot differentiate between failure of link/reachability to R1 ver= sus node failure of R1, and proposed solution will not work w/o differentia= ting the two. "should be able to detect" here sounds more like "someone wil= l probably do something later". I rather see "OAM Considerations" section describe things needed/required i= n OAM tools for the proposal to work. If that can also be communicated to <= somewhere where OAM guys can provide feedback>, even better. Regards, Nobo From nobody Sun Mar 23 01:12:58 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1161A0A2A; Sat, 22 Mar 2014 15:29:59 -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, 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 cttuC9biawdg; Sat, 22 Mar 2014 15:29:57 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 293BA1A0A28; Sat, 22 Mar 2014 15:29:57 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-e1-532e0bfdb72b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 98.7F.11484.DFB0E235; Sat, 22 Mar 2014 23:17:33 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0387.000; Sat, 22 Mar 2014 18:29:56 -0400 From: Jeff Tantsura To: Acee Lindem , Loa Andersson , "John E Drake" , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQACTXiwAACpRvAAAAZx4A Date: Sat, 22 Mar 2014 22:29:55 +0000 Message-ID: References: <532D62BE.3040102@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <8160B2E5E754C04AB36E8277FD7387D6@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonSvcvt16wwdZefYsfPTeYLb5eS7OY c9fZ4t/cOcwWDw4vZLNYsOYpuwObx5IlP5k8rjddZfdYsXklo8es6W1sASxRXDYpqTmZZalF +nYJXBlX955mKvgnVzHt+zTWBsZvkl2MnBwSAiYS25c9ZIWwxSQu3FvP1sXIxSEkcIRRon/z RHYIZzmjxMxZuxlBqtgEDCT+fzvOApIQEfjIKHHr5CSwdmYBFYnePT+ZQGxhoKKP/y+DNYgI GEo83beSCcJ2k5j/5RQ7iM0ioCpx88dasF5eAXOJqf+fg9lCAgES8/umgNVwCphJ/H7QDhZn BDrv+6k1TBC7xCVuPZnPBHG2gMSSPeeZIWxRiZeP/4HViwroSdx7NJcFIq4osa9/OjtEr47E gt2f2CBsa4mr015AzdSWWLbwNTPEPYISJ2c+YZnAKDELybpZSNpnIWmfhaR9FpL2BYysqxg5 SotTy3LTjQw3MQIj9ZgEm+MOxgWfLA8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qB0cF8Z/mRKom5vw69MCnZe7LwlkFLpvCdc++r4/T1ehK4Zx13VV11bAlPyG3eFn07 vQrDv3/jegL2+/L5Gy711FnoeWlfgciquBUMc8P5BPIORbAtWm/w6P8js4e6K35+1A5/5ZF/ 9sCPvV7rczcbmSvWGMXPPsP2wdmRt0ohnM2X39ZM8uUKJZbijERDLeai4kQAP926haICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Br26vNaHq_IGESjVMOc6A3dYD-4 X-Mailman-Approved-At: Sun, 23 Mar 2014 01:12:51 -0700 Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Mar 2014 22:29:59 -0000 I agree with Loa and Acee - let's define problems before trying to solve them! Cheers, Jeff -----Original Message----- From: Acee Lindem Lindem III Date: Saturday, March 22, 2014 3:18 PM To: Loa Andersson , John Drake , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Cc: Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check Resent-To: , , , , , , , , , , , "hannes@juniper.net" , Joel Halpern , , , , Thomas Morin , Martin Vigoureux , , , , Loa Andersson , , , , , Acee Lindem Lindem III , , , , , , , , , Alvaro Retana , Jeff Tantsura , , , , , Alvaro Retana , , Alia Atlas , >I agree with Loa that the problem needs to be defined - this discussion >has already diverged into 4 different directions. > >Thanks, >Acee=20 > >On 3/22/14 3:15 AM, "Loa Andersson" wrote: > >>John, >> >>How about deciding what is broken first, and then looking at the >>actions?? >> >>/Loa >> >>On 2014-03-21 21:44, John E Drake wrote: >>> Adrian, >>> >>> Combine IS-IS and OSPF >>> >>> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >>> >>> There is probably some synergy between PCE, SFC, and SPRING that needs >>>to be exploited >>> >>> Combine BFD and the OAM/protection switching part of MPLS >>> >>> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >>> >>> Yours Irrespectively, >>> >>> John >>> >>>> -----Original Message----- >>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>>Farrel >>>> Sent: Friday, March 21, 2014 11:31 AM >>>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>>> Cc: Alia Atlas >>>> Subject: [RTG-DIR] Routing Area Health Check >>>> >>>> Hello Directorate and WG chairs, >>>> >>>> Alia and I have been discussing the Routing Area, its work, its >>>>output, and its >>>> working groups. >>>> >>>> We have reached a conclusion (which perhaps we should have come to >>>>sooner) >>>> that we need your help and input. >>>> >>>> The crunch question for us is "What makes it hard to get work done in >>>>the >>>> Routing Area?" What gets in the way of your work? What is making life >>>>hard >>>> for document authors? How could working groups be doing better? We are >>>> open to all and every type of answer. We are happy to have quick, >>>>one-line >>>> answers or deeply-considered essays. >>>> >>>> What do you think? >>>> >>>> Thanks for all your input, >>>> Adrian and Alia >>>> >>>> PS Please respond to both aliases because not everyone is on both >>>>lists. Sorry >>>> that that means some of you will get duplicates. >>>> >>>> >>> >>> >> >>--=20 >> >> >>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 Mar 23 01:37:07 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69FE21A092C; Sun, 23 Mar 2014 01:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.129 X-Spam-Level: X-Spam-Status: No, score=-101.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 6nP2661D9v96; Sun, 23 Mar 2014 01:37:02 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id F34121A091E; Sun, 23 Mar 2014 01:37:01 -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 s2N8b0a6017658; Sun, 23 Mar 2014 08:37:00 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2N8awpq017630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 08:36:59 GMT From: "Adrian Farrel" To: , References: <532D62BE.3040102@pi.nu> In-Reply-To: Date: Sun, 23 Mar 2014 08:36:59 -0000 Message-ID: <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B56_01CF4673.0F5B9FC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUSZYWTwCBpcwfYKSo2uUSqm2+UQGRqzQOAfOTaXOcSCfvIA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20584.006 X-TM-AS-Result: No--35.732-10.0-31-10 X-imss-scan-details: No--35.732-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFo7TQ33iIu+7FbWTTCHhOTxn6WRxK/0Rx+mUzNZSpGeUair mEfFRuoPra1MFj2AtFUsECwTYw9bTpRMdwEiWk2Nt1AhvyEKdj4gdghl533NdTRCaZSKE/Os/F1 Brea7byKBXkRBG9KO2q0Pj/9cOH4s1N8sc+ZmqpmVUcz8XpiS9LcKpgWLjRGK33Nl3elSfsrf2a 6mYZqlhVckktDFTOdTHIPKfHWEsTRH6+lhuE4fWia1MaKuob8PnophrTcsI7aqvcIF1TcLYBrAl 8br+lweAPJewjr9WbaATqlB8xTnmxccs8336rx5AjTI/+6gf4NR3sGN+j7mNCJ8zskw0dbrYsWa kGXS7Fcb5eiG8Ik8P2Bph9YeEe8MB4rexQR1xI5Wjqaf7FeZ1Qtx7lnIMkAmcYZaHYAFbS/PhUL P14ziaKfg/QnMAwHRvDfcj1bOvAcd2SQtrADtIXFpe+85TnNunjQstLm6Sv10PA/ki2kI7BxJEX 0k/k7OLiNvWfV40DeHMqVObyPMMsNYV73vYBFQjtK7dC6UBnkUqWKocoJo6esoDDE6CvPdp4Wcm yqBbFxC3bjvSDu959+suYAg9ZWJMxvA4OPLCf7yFS9/ikjYMJE8wIBxuXjSoCR/e+JqW6uoE5C4 E7U4IF6pdoSHMJdrEx8v+o5aYx0+IBpBKMCCmTbN0t/c2qF2FNsHrIiF8rsVvvd4qkb1+1Q+CF9 xoc5LnE2RogVHfH2sEFKef8ZUxpcqz3g0A4fyupDIC9422DrTMQ/93vE8XUbaqUVvLFsimpFVmG A1607MDEuDg15grA26ehZuKFNX/jM1WnqKv0WeAiCmPx4NwGmRqNBHmBvelpyqxIUg/ZTJ4y0wP 1A6AKTygpcqFEs8IhDmZnlKoc8BryGvp6Doi+ae82Sj1GmHiLWVNI3S+BXYKQ5wwBqBHCkddiM2 tuih Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/yO_5PfyLEnWQ6_R2b_xlB2yGR3c Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 08:37:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B56_01CF4673.0F5B9FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yeah, I like that all sorts of ideas are being thrown into the pot. We should be a sufficiently adult subset of the crazies to be able to handle that. However, we are talking like engineers :-) Might be nice to focus back on the questions of what is a problem for getting work done. We can come back to how to fix it. Now, all of you complaining that the problem needs to be defined... ...please define the problem :-) Adrian From: Alia Atlas [mailto:akatlas@gmail.com] Sent: 22 March 2014 22:48 To: Acee Lindem Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check Acee, None of those different directions seems to me to be bad. The question was deliberately ask unframed and undefined. Adrian and I will define and frame it more - but first we wanted to hear the unframed but thoughtful discussion. Providing reasoning does help everyone determine if they are on the same page. Regards, Alia On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem wrote: I agree with Loa that the problem needs to be defined - this discussion has already diverged into 4 different directions. Thanks, Acee On 3/22/14 3:15 AM, "Loa Andersson" wrote: >John, > >How about deciding what is broken first, and then looking at the >actions?? > >/Loa > >On 2014-03-21 21:44, John E Drake wrote: >> Adrian, >> >> Combine IS-IS and OSPF >> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >> >> There is probably some synergy between PCE, SFC, and SPRING that needs >>to be exploited >> >> Combine BFD and the OAM/protection switching part of MPLS >> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>Farrel >>> Sent: Friday, March 21, 2014 11:31 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Cc: Alia Atlas >>> Subject: [RTG-DIR] Routing Area Health Check >>> >>> Hello Directorate and WG chairs, >>> >>> Alia and I have been discussing the Routing Area, its work, its >>>output, and its >>> working groups. >>> >>> We have reached a conclusion (which perhaps we should have come to >>>sooner) >>> that we need your help and input. >>> >>> The crunch question for us is "What makes it hard to get work done in >>>the >>> Routing Area?" What gets in the way of your work? What is making life >>>hard >>> for document authors? How could working groups be doing better? We are >>> open to all and every type of answer. We are happy to have quick, >>>one-line >>> answers or deeply-considered essays. >>> >>> What do you think? >>> >>> Thanks for all your input, >>> Adrian and Alia >>> >>> PS Please respond to both aliases because not everyone is on both >>>lists. Sorry >>> that that means some of you will get duplicates. >>> >>> >> >> > >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > ------=_NextPart_000_0B56_01CF4673.0F5B9FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yeah, I like that all sorts of = ideas are being thrown into the pot. We should be a sufficiently adult = subset of the crazies to be able to handle that.

 

However, we are talking like = engineers :-)

Might be nice to focus back on = the questions of what is a problem for getting work done. We can come = back to how to fix it.

 

Now, all of you complaining = that the problem needs to be defined...

...please define the problem = :-)

 

Adrian

 

From: Alia Atlas = [mailto:akatlas@gmail.com]
Sent: 22 March 2014 = 22:48
To: Acee Lindem
Cc: Loa Andersson; John E = Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia = Atlas
Subject: Re: [RTG-DIR] Routing Area Health = Check

 

Acee,

 

None of those different directions seems to me to be = bad.

The question was = deliberately ask unframed and undefined.

Adrian and I will define and frame it more - but first = we wanted 

to hear = the unframed but thoughtful discussion.

 

Providing reasoning does help everyone determine if = they are

on the same = page.

 

Regards,

Alia

 

On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem <acee.lindem@ericsson.com> = wrote:

I agree with Loa that the = problem needs to be defined - this discussion
has already diverged = into 4 different = directions.

Thanks,
Acee


On 3/22/14 3:15 AM, = "Loa Andersson" <loa@pi.nu> = wrote:

>John,
>
>How about deciding what is broken = first, and then looking at = the
>actions??
>
>/Loa
>
>On 2014-03-21 = 21:44, John E Drake wrote:
>> Adrian,
>>
>> = Combine IS-IS and OSPF
>>
>> Combine L2 and L3 VPNs = and move the CCAMP inter-domain TE work there
>>
>> = There is probably some synergy between PCE, SFC, and SPRING that = needs
>>to be exploited
>>
>> Combine BFD and = the OAM/protection switching part of MPLS
>>
>> Close = Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours = Irrespectively,
>>
>> John
>>
>>> = -----Original Message-----
>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] = On Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, = March 21, 2014 11:31 AM
>>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org
>>&g= t; Cc: Alia Atlas
>>> Subject: [RTG-DIR] Routing Area Health = Check
>>>
>>> Hello Directorate and WG = chairs,
>>>
>>> Alia and I have been discussing = the Routing Area, its work, its
>>>output, and = its
>>> working groups.
>>>
>>> We = have reached a conclusion (which perhaps we should have come = to
>>>sooner)
>>> that we need your help and = input.
>>>
>>> The crunch question for us is = "What makes it hard to get work done = in
>>>the
>>> Routing Area?" What gets in = the way of your work? What is making = life
>>>hard
>>> for document authors? How could = working groups be doing better? We are
>>> open to all and = every type of answer. We are happy to have = quick,
>>>one-line
>>> answers or = deeply-considered essays.
>>>
>>> What do you = think?
>>>
>>> Thanks for all your = input,
>>> Adrian and Alia
>>>
>>> = PS Please respond to both aliases because not everyone is on = both
>>>lists. Sorry
>>> that that means some of = you will get = duplicates.
>>>
>>>
>>
>>
&g= t;
>--
>
>
>Loa Andersson       =                  email: loa@mail01.huawei.com
>Se= nior MPLS Expert                 =          loa@pi.nu
>Huawei Technologies = (consultant)     phone: +46 739 81 21 = 64
>

 

------=_NextPart_000_0B56_01CF4673.0F5B9FC0-- From nobody Sun Mar 23 08:14:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9A11A6FC3; Sun, 23 Mar 2014 08:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ffIbV2O4DKDF; Sun, 23 Mar 2014 08:14:16 -0700 (PDT) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 65B161A098D; Sun, 23 Mar 2014 08:14:15 -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 s2NFECq9002127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 23 Mar 2014 10:14:14 -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 s2NFEB7o027408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Mar 2014 16:14:11 +0100 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.4]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sun, 23 Mar 2014 16:14:11 +0100 From: "VIGOUREUX, MARTIN (MARTIN)" To: Lou Berger , "Andrew G. Malis" , "Russ White" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: AQHPReNW3JqwBCUX7EqukSZw1unn75rtQnAAgAAIrYCAABYjgIABaA7B Date: Sun, 23 Mar 2014 15:14:09 +0000 Message-ID: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> , <144eaf73f20.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <144eaf73f20.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FEA27CFACBAF3A429E381E6FD69CDC731A1B52FR712WXCHMBA09zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wbn0qbEcpVeuCuWegONcsCr_dEU Cc: Adrian Farrel , Ines Robles , Alia Atlas , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 15:14:19 -0000 --_000_FEA27CFACBAF3A429E381E6FD69CDC731A1B52FR712WXCHMBA09zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable mpls has just started that following London's meeting. Team of ~8 reviewers. First English review ongoing. There were signs indicating the need for that. Adrian's talk in mpls triggered the call for volunteers. I think it is a good idea, especially if it enables to catch those sentence= s which can be understood technicaly differently. -m ________________________________ De : Lou Berger Envoy=E9 : 22/03/2014 19:45 =C0 : Andrew G. Malis; Russ White Cc : Adrian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg-dir@i= etf.org Objet : Re: [RTG-DIR] Routing Area Health Check This is a great idea. Lou On March 22, 2014 1:28:15 PM "Andrew G. Malis" wrote: > I recently did some language editing on a draft I was technically > reviewing for the Independent Series Editor (the author wasn't a > native English speaker). Perhaps we could put together a list of area > volunteers that are willing to do a language cleanup pass on drafts > that could use it just before they go into WG LC. You wouldn't want to > do it any earlier. > > Cheers, > Andy > > On Sat, Mar 22, 2014 at 5:55 PM, Russ White wrote: > > > >> About this: ""What is making life hard for document authors? How could > >> working groups be doing better?" > > > > Another point we might want to consider is whether or not we should be = at > > least something proactive about the language barrier issues -- like mak= ing > > certain the community knows the RG-DIR is open to helping folks with is= sues > > on the language side, or even to provide a "non-native speaker review."= This > > might help improve the output of the area as a whole (?). > > > > :-) > > > > Russ > > > > > > > --_000_FEA27CFACBAF3A429E381E6FD69CDC731A1B52FR712WXCHMBA09zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
mpls has just= started that following London's meeting.
Team of ~8 reviewers. First English review ongoing.

There were signs indicating the need for that.
Adrian's talk in mpls triggered the call for volunteers.

I think it is a good idea, especially if it enables to catch those sentence= s which can be understood technicaly differently.

-m
De : Lou Be= rger
Envoy=E9 : 22/03/= 2014 19:45
=C0 : Andrew= G. Malis; Russ White
Cc : Adrian= Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg-dir@ietf.org
Objet : Re: [R= TG-DIR] Routing Area Health Check

This is a great idea.

Lou


On March 22, 2014 1:28:15 PM "Andrew G. Malis" <agmalis@gmail.= com> wrote:

> I recently did some language editing on a draft I was technically
> reviewing for the Independent Series Editor (the author wasn't a
> native English speaker). Perhaps we could put together a list of area<= br> > volunteers that are willing to do a language cleanup pass on drafts > that could use it just before they go into WG LC. You wouldn't want to=
> do it any earlier.
>
> Cheers,
> Andy
>
> On Sat, Mar 22, 2014 at 5:55 PM, Russ White <russw@riw.us> wrote= :
> >
> >> About this: ""What is making life hard for document= authors? How could
> >> working groups be doing better?"
> >
> > Another point we might want to consider is whether or not we shou= ld be at
> > least something proactive about the language barrier issues -- li= ke making
> > certain the community knows the RG-DIR is open to helping folks w= ith issues
> > on the language side, or even to provide a "non-native speak= er review." This
> > might help improve the output of the area as a whole (?).
> >
> > :-)
> >
> > Russ
> >
> >
> >
>


 --_000_FEA27CFACBAF3A429E381E6FD69CDC731A1B52FR712WXCHMBA09zeu_-- From nobody Sun Mar 23 10:08:52 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DFA1A6FB9; Sun, 23 Mar 2014 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 YwuJIday2XNt; Sun, 23 Mar 2014 07:19:33 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC451A0744; Sun, 23 Mar 2014 07:19:33 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jx11so4527080veb.17 for ; Sun, 23 Mar 2014 07:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KqlVX5VCjX3ScIW27v+Oqg/Lp0j9N1zk8vMU5REmPKM=; b=S70k1BH6a0YFl1UJxtNGJBjzqf1k2r+26HDBgnBoMyNxTgR/gZaMaa6vwtNStpFsPr 6GoaBu1LVjFNpYNI4JIl5lJbsVU5k33+88WGvWDaGCAxc9Un3rRCycvomYxfGtgCw/Mm ODILT1pR4QLIN2t8VYEkBYhPRs0A7Xu0Wp+/cRbWNdwBwM34Ncfxooj7S1UbwN9TmrR8 SMUvzRf8SJhTZr4QQ/prFbFEIC5lbF/r+4ybBPjqg3nRZd3fjVvc5g3eIEMhPntHvLb9 QJEaN/89M3HHu+SFnR8xtC45RlQ2POkLEgnK+GckLAj+2t2/nomHDInqOPOQNCe+e0/i FciA== MIME-Version: 1.0 X-Received: by 10.58.152.142 with SMTP id uy14mr13990943veb.4.1395584372819; Sun, 23 Mar 2014 07:19:32 -0700 (PDT) Received: by 10.221.16.3 with HTTP; Sun, 23 Mar 2014 07:19:32 -0700 (PDT) In-Reply-To: <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> Date: Sun, 23 Mar 2014 11:19:32 -0300 Message-ID: From: Ines Robles To: Adrian Farrel Content-Type: multipart/alternative; boundary=089e01294218cbcbf704f546ce8e Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Kzkt2a50_n7Li01GYYg8LN75xNA X-Mailman-Approved-At: Sun, 23 Mar 2014 10:08:46 -0700 Cc: rtg-dir@ietf.org, Alia Atlas , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 14:19:36 -0000 --089e01294218cbcbf704f546ce8e Content-Type: text/plain; charset=ISO-8859-1 *Hi, About this: "What is making life hard for document authors?" Maybe, one problem is that the authors don't know all the steps, that a document goes through during the process of publication, of course it is responsibility of the authors read the required information to learn about it; This is the minimum thing, that an author must do, if he/she wants to publish a document in the IETF. But, I think, sometimes the authors believe that, the work is done when a document is submitted to the IESG, then for example they forget to address the Gen-art review, AUTH48, and additionals reviews. Thinking that maybe, a fast checklist is going to help them to know what they should address to get a document published :-) Thanks and Regards Ines* 2014-03-23 5:36 GMT-03:00 Adrian Farrel : > Yeah, I like that all sorts of ideas are being thrown into the pot. We > should be a sufficiently adult subset of the crazies to be able to handle > that. > > > > However, we are talking like engineers :-) > > Might be nice to focus back on the questions of what is a problem for > getting work done. We can come back to how to fix it. > > > > Now, all of you complaining that the problem needs to be defined... > > ...please define the problem :-) > > > > Adrian > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* 22 March 2014 22:48 > *To:* Acee Lindem > *Cc:* Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; > rtg-chairs@ietf.org; Alia Atlas > *Subject:* Re: [RTG-DIR] Routing Area Health Check > > > > Acee, > > > > None of those different directions seems to me to be bad. > > The question was deliberately ask unframed and undefined. > > Adrian and I will define and frame it more - but first we wanted > > to hear the unframed but thoughtful discussion. > > > > Providing reasoning does help everyone determine if they are > > on the same page. > > > > Regards, > > Alia > > > > On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem > wrote: > > I agree with Loa that the problem needs to be defined - this discussion > has already diverged into 4 different directions. > > Thanks, > Acee > > > On 3/22/14 3:15 AM, "Loa Andersson" wrote: > > >John, > > > >How about deciding what is broken first, and then looking at the > >actions?? > > > >/Loa > > > >On 2014-03-21 21:44, John E Drake wrote: > >> Adrian, > >> > >> Combine IS-IS and OSPF > >> > >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there > >> > >> There is probably some synergy between PCE, SFC, and SPRING that needs > >>to be exploited > >> > >> Combine BFD and the OAM/protection switching part of MPLS > >> > >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> -----Original Message----- > >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian > >>>Farrel > >>> Sent: Friday, March 21, 2014 11:31 AM > >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org > >>> Cc: Alia Atlas > >>> Subject: [RTG-DIR] Routing Area Health Check > >>> > >>> Hello Directorate and WG chairs, > >>> > >>> Alia and I have been discussing the Routing Area, its work, its > >>>output, and its > >>> working groups. > >>> > >>> We have reached a conclusion (which perhaps we should have come to > >>>sooner) > >>> that we need your help and input. > >>> > >>> The crunch question for us is "What makes it hard to get work done in > >>>the > >>> Routing Area?" What gets in the way of your work? What is making life > >>>hard > >>> for document authors? How could working groups be doing better? We are > >>> open to all and every type of answer. We are happy to have quick, > >>>one-line > >>> answers or deeply-considered essays. > >>> > >>> What do you think? > >>> > >>> Thanks for all your input, > >>> Adrian and Alia > >>> > >>> PS Please respond to both aliases because not everyone is on both > >>>lists. Sorry > >>> that that means some of you will get duplicates. > >>> > >>> > >> > >> > > > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > > > > --089e01294218cbcbf704f546ce8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,


About this: “”


Maybe, one problem is that the authors don&= rsquo;t know all the steps, that a document goes through during the process= of publication, of course it is responsibility of the authors read the req= uired information to learn about it; This is the minimum thing, that an aut= hor must do, if he/she wants to publish a document in the IETF.


But, I think, sometimes the authors believe= that, the work is done when a document is submitted to the IESG, then for = example they forget to address the Gen-art review, , and additionals reviews.


Thinking that maybe, a fast checklist is go= ing to help them to know what they should address to get a document publish= ed :-)


Thanks and Regards


Ines


2014-03-23 5:= 36 GMT-03:00 Adrian Farrel <adrian@olddog.co.uk>:

Yeah, I like that all sorts of ideas are bei= ng thrown into the pot. We should be a sufficiently adult subset of the cra= zies to be able to handle that.

 

However, we are tal= king like engineers :-)

Might be nice to focus ba= ck on the questions of what is a problem for getting work done. We can come= back to how to fix it.

 

Now, all of you com= plaining that the problem needs to be defined...

...please define the prob= lem :-)

 

Adrian

 

From: Alia Atlas [mailto:akatlas@gmail.com]
Sent: 22 March 2014 22:48
To: Acee Lindem
Cc: Lo= a Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia Atlas
Subject: Re: [RTG-DIR] Routing Area Health Check

 

<= div>

Acee,

 

None of those dif= ferent directions seems to me to be bad.

The question was deliberately ask unframed and undefined.<= u>

Adrian and I will define and frame it mor= e - but first we wanted 

to hear the unframed but thoughtful discussion.

 

Providing reasoning does help everyone determine if they are

on the same page.<= /p>

 

Regards,

Alia=

 

On Sat, Mar 22, 2014 at= 6:18 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:

I agree with Loa that the problem needs to be defined - this discussion
= has already diverged into 4 different directions.

Thanks,
Acee=


On 3/22/14 3:15 AM, "Loa Andersson" <loa@pi.nu> wrote:

>John,
>=
>How about deciding what is broken first, and then looking at the >actions??
>
>/Loa
>
>On 2014-03-21 21:44, John = E Drake wrote:
>> Adrian,
>>
>> Combine IS-IS an= d OSPF
>>
>> Combine L2 and L3 VPNs and move the CCAMP in= ter-domain TE work there
>>
>> There is probably some synergy between PCE, SFC, and S= PRING that needs
>>to be exploited
>>
>> Combine= BFD and the OAM/protection switching part of MPLS
>>
>> = Close Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours Irrespectively,
>>
>> John
= >>
>>> -----Original Message-----
>>> From: r= tg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, March 21, 2014 11:31 AM>>> To: rtg= -dir@ietf.org; rtg-chairs@ietf.org
>>> Cc: Alia Atlas
>>> Subject: [RTG-DIR] Routing Area= Health Check
>>>
>>> Hello Directorate and WG chai= rs,
>>>
>>> Alia and I have been discussing the Rou= ting Area, its work, its
>>>output, and its
>>> working groups.
>>>=
>>> We have reached a conclusion (which perhaps we should have= come to
>>>sooner)
>>> that we need your help and = input.
>>>
>>> The crunch question for us is "What makes= it hard to get work done in
>>>the
>>> Routing Are= a?" What gets in the way of your work? What is making life
>>= >hard
>>> for document authors? How could working groups be doing better= ? We are
>>> open to all and every type of answer. We are happy= to have quick,
>>>one-line
>>> answers or deeply-c= onsidered essays.
>>>
>>> What do you think?
>>>
>>= > Thanks for all your input,
>>> Adrian and Alia
>>= >
>>> PS Please respond to both aliases because not everyone= is on both
>>>lists. Sorry
>>> that that means some of you will g= et duplicates.
>>>
>>>
>>
>>
&= gt;
>--
>
>
>Loa Andersson       &nb= sp;                email: loa@mail01.huawei.com
>Senior MPLS Expert               &nb= sp;          loa@pi.nu
>Huawei Technologies (consultant)   &n= bsp; phone: +4= 6 739 81 21 64
>

 = ;


--089e01294218cbcbf704f546ce8e-- From nobody Sun Mar 23 10:21:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0F31A0759; Sun, 23 Mar 2014 10:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.083 X-Spam-Level: X-Spam-Status: No, score=-97.083 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 556iSBCq1oy9; Sun, 23 Mar 2014 10:21:05 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 959A91A06D2; Sun, 23 Mar 2014 10:21:05 -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 s2NHL3wA009134; Sun, 23 Mar 2014 17:21:03 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2NHL16K009123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 23 Mar 2014 17:21:03 GMT From: "Adrian Farrel" To: , References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> , <144eaf73f20.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Date: Sun, 23 Mar 2014 17:21:02 -0000 Message-ID: <0bcb01cf46bc$454046b0$cfc0d410$@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: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wJ1AFd2AS7Sf84BzqowQQJSc0E5AbhwnfqZDMsaUA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20586.001 X-TM-AS-Result: No--5.518-10.0-31-10 X-imss-scan-details: No--5.518-10.0-31-10 X-TMASE-MatchedRID: lORh06tOiKg4HKI/yaqRm4FdumLFst5tQKuv8uQBDjqG8m0JExnub8Zd LfqNNxX6i8en/jNx6M00FJKIRy8cWhDuooXos5Ve8LWXwaKCemt9LQinZ4QefL6qvLNjDYTwfyj BJDnutUhQSFbL1bvQASAHAopEd76vluSbMgwrDnrcHz5C9J2iwuKeTvx2QHAykM7ZPFjt9RjRY0 X391NgNw== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/bakT9BgMfWMeC5tDjggobaTZPTk Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:21:07 -0000 > mpls has just started that following London's meeting. > Team of ~8 reviewers. First English review ongoing. > > There were signs indicating the need for that. > Adrian's talk in mpls triggered the call for volunteers. For those who love learning how to suck eggs... http://www.ietf.org/proceedings/89/slides/slides-89-mpls-15.pptx A From nobody Mon Mar 24 06:49:19 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8A1A0206; Mon, 24 Mar 2014 06:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 55gLD-K3TPju; Mon, 24 Mar 2014 06:49:16 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02B1A0201; Mon, 24 Mar 2014 06:49:16 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D12CDC1F2; Mon, 24 Mar 2014 09:49:15 -0400 (EDT) Date: Mon, 24 Mar 2014 09:49:15 -0400 From: Jeffrey Haas To: Russ White Message-ID: <20140324134915.GI13937@pfrc> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> <047201cf45d6$465e3250$d31a96f0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <047201cf45d6$465e3250$d31a96f0$@riw.us> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/JtZIQYssM6mJUeT_sg6wfi-NFXg Cc: 'John E Drake' , rtg-dir@ietf.org, 'Alia Atlas' , rtg-chairs@ietf.org, adrian@olddog.co.uk, 'Loa Andersson' Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 13:49:17 -0000 On Sat, Mar 22, 2014 at 09:54:40AM -0400, Russ White wrote: > > > > Close Secure IDR, FORCES, KARP, MANET, and NVO3 > > SIDR has "finished," the RPKI, which could be folded into IDR, and the path > protection stuff is a science experiment that isn't deployable in the real > world. Suggest moving the path protection work into the routing research > group until something that will actually provide some real protection comes > along. While I agree that the bgpsec stuff isn't deployable now (too much crypto), it's at least sound design. Probably best to just leave SIDR alone until that component hits RFC rather than trying to dump the remaining work into IDR. > > Require drafts to place more emphasis on OAM to minimize OAM needing to > play the catch-up game later. > > An interesting idea... Maybe we need something more concrete here, though, > like (as a rough start): require all new data structures in proposed > standards (or experimentals) include a data model in YANG format -- or some > such. I'm of mixed opinion about this from an IETF requirements standpoint. As much as I think we do a poor job of this sort of thing, protocol designers tend to implement protocol management components. Operators are far more interested in what helps them diagnose why things don't work in their networks. The two functional requirements don't always meet well in the middle. -- Jeff From nobody Mon Mar 24 07:04:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2494E1A0226; Mon, 24 Mar 2014 07:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kJjO2cw9tsE2; Mon, 24 Mar 2014 07:04:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8BC1A021E; Mon, 24 Mar 2014 07:04:15 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A8108C1F2; Mon, 24 Mar 2014 10:04:14 -0400 (EDT) Date: Mon, 24 Mar 2014 10:04:14 -0400 From: Jeffrey Haas To: Adrian Farrel Message-ID: <20140324140414.GJ13937@pfrc> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/MFupWknjlLw_gdqLqCVeIPrtvx8 Cc: rtg-dir@ietf.org, Alia Atlas , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:04:17 -0000 On Fri, Mar 21, 2014 at 06:31:08PM -0000, Adrian Farrel wrote: > The crunch question for us is "What makes it hard to get work done in the > Routing Area?" What gets in the way of your work? What is making life hard for > document authors? How could working groups be doing better? We are open to all > and every type of answer. We are happy to have quick, one-line answers or > deeply-considered essays. Focusing on the "done" part through a bunch of random observations: Work that gets "done" fast tends to be of interest and has running code associated with it. The authors are often working directly with implementors. In such cases, specs turn to implementations (or vice versa) and we end up with RFCs quickly. Something that has narrow focus can get published faster. Work that is progressing but isn't finishing often has running code (perhaps long deployed), but the interest of the authors/chairs in getting the thing pushed to RFC is the problem. A big portion of this, IMO, is due to the entirety of the process taking too long. Much of the fix for this is probably the chairs pushing the work (more active chairs). Work that lingers but isn't advancing (the walking dead) seems to have two aspects (at least): - Pet projects that haven't quite gotten some form of internal support to get code in an implementation. - Something that is the "right thing" to do but no one is really interested in. IMO, there is value to both of these, but they have a draining effect on working group throughput. This puts a lot of work upon either the authors or the chairs to make sure that time only is used by the WG when it's not a distraction. --- >From the above, the big issue with chair activity probably comes down to the fact that many chairs do not do IETF as their "full-time job". It's a common issue with volunteer organizations. Things that help is better project management tools (the datatracker helps but there's nothing in it that fulfills project management functions rather than project artifact tracking). In the absence of tools, nags from above can help but our leadership is similarly overwhelmed. Pushing on the authors for certain types of work probably doesn't help. Until there is implementation helping to pull things along, it's a "pushing the rope" problem. IMO, the fix for some of this is to ensure that at least meeting time is reserved for active work. Speculative or prospective work should be required to be vetted in the mailing list first. Walking dead work should be reserved to the mailing list until it gains new life. -- Jeff From nobody Mon Mar 24 07:53:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC341A019A; Mon, 24 Mar 2014 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 5PGw4srepCNS; Mon, 24 Mar 2014 07:53:17 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5651B1A023F; Mon, 24 Mar 2014 07:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16513; q=dns/txt; s=iport; t=1395672796; x=1396882396; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=soRDeV9JE5QrUC5eUfNBouuzeSowyfgpsSOAZtSN//o=; b=Y0Uts9LKfDY2xCUPu9UDlZswXAVqTKMpER/hGQP5nsngydnjYQTOlcM9 1mn51Nfhky8za0VwVlkkxzijRmRJEHZuMox8QgK2wh5R5uZWQOHBSpeaa FcqNhFPmVjrnNsAAVvueIMFNm0L0FmBI+OnP+XDkTejholUJHzO8RrHRk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEGAKxFMFOtJXG9/2dsb2JhbABZgkJEgRK/K4NCgRgWdIIlAQEBAwEdEEwFCwIBCBEDAQIBJwchERQJCAIEAQ0FFAWHTAMJCMcxDYcFF4lMgxGBSQMBASsTEQeEOASJGo1DgW2MaIVJgy2Bcjk X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208,217";a="312467824" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 24 Mar 2014 14:53:15 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2OErEA1026770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 14:53:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.233]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 09:53:13 -0500 From: "George Swallow (swallow)" To: "VIGOUREUX, MARTIN (MARTIN)" , "Lou Berger" , "Andrew G. Malis" , Russ White Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgA2VZUAAAMVwwAAARWcgAACxGeAACrpIoAAKS1igA== Date: Mon, 24 Mar 2014 14:53:13 +0000 Message-ID: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <007001cf45ef$7e3b0090$7ab101b0$@riw.us> <144eaf73f20.2764.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.98.56.165] Content-Type: multipart/alternative; boundary="_000_CF55BC8BA3761swallowciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/n3C9a6v3NsRVRq6lS6v1FFxasFg Cc: "George Swallow \(swallow\)" , "rtg-dir@ietf.org" , Ines Robles , Alia Atlas , "rtg-chairs@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:53:21 -0000 --_000_CF55BC8BA3761swallowciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To my surprise, when I called for English review volunteers, we got many re= sponses within the first three days. About half were folks that never atte= nd the IETF, but follow the mail list. Most of these said that they were l= ooking for a way to get more involved, but having no direct experience were= too shy to speak up on technical issues. I'm hoping this means we have a set of fairly highly motivated reviewers. = We'll let you know how it works out. George From: , "MARTIN (MARTIN)" > Date: Sunday, March 23, 2014 11:14 AM To: Lou Berger >, "Andrew G. Mali= s" >, Russ White > Cc: Adrian Farrel >, Ines R= obles >, Alia Atlas >, "rtg-chai= rs@ietf.org" >, "rtg-dir@ietf.org" > Subject: RE: [RTG-DIR] Routing Area Health Check Resent-From: > Resent-To: Jeffrey Haas >, >, = >, Lou Berger >, >, >, Jeffrey Haas >, >, >, "John G. Scudder" >, >, >, "Joel M. Halpern" >, >, "Bit= ar, Nabil N" >,= >, >, >, >, >, Ge= orge Swallow >, Loa Andersson <= loa@pi.nu>, Ross Callon >, >, BO= CCI Matthew >, >, >, = >, Julien Meuric = >, >, >, BOCCI Matthew >, >, >, >, >, >, >, >, >, >, >, "John G. Scudder" >, >, Adrian Farrel > Resent-Date: Sunday, March 23, 2014 11:14 AM mpls has just started that following London's meeting. Team of ~8 reviewers. First English review ongoing. There were signs indicating the need for that. Adrian's talk in mpls triggered the call for volunteers. I think it is a good idea, especially if it enables to catch those sentence= s which can be understood technicaly differently. -m ________________________________ De : Lou Berger Envoy=E9 : 22/03/2014 19:45 =C0 : Andrew G. Malis; Russ White Cc : Adrian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg-dir@ietf.org Objet : Re: [RTG-DIR] Routing Area Health Check This is a great idea. Lou On March 22, 2014 1:28:15 PM "Andrew G. Malis" > wrote: > I recently did some language editing on a draft I was technically > reviewing for the Independent Series Editor (the author wasn't a > native English speaker). Perhaps we could put together a list of area > volunteers that are willing to do a language cleanup pass on drafts > that could use it just before they go into WG LC. You wouldn't want to > do it any earlier. > > Cheers, > Andy > > On Sat, Mar 22, 2014 at 5:55 PM, Russ White > wrote: > > > >> About this: ""What is making life hard for document authors? How could > >> working groups be doing better?" > > > > Another point we might want to consider is whether or not we should be = at > > least something proactive about the language barrier issues -- like mak= ing > > certain the community knows the RG-DIR is open to helping folks with is= sues > > on the language side, or even to provide a "non-native speaker review."= This > > might help improve the output of the area as a whole (?). > > > > :-) > > > > Russ > > > > > > > --_000_CF55BC8BA3761swallowciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <135A3CA3405CF04C8B47F102B2C8D93C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
To my surprise, when I called for English review volunteers, we got ma= ny responses within the first three days.  About half were folks that = never attend the IETF, but follow the mail list.  Most of these said t= hat they were looking for a way to get more involved, but having no direct experience were too shy to speak up on tech= nical issues.  

I'm hoping this means we have a set of fairly highly motivated reviewe= rs.  We'll let you know how it works out.

George

From: <VIGOUREUX>, "MART= IN (MARTIN)" <martin.vigoureux@alcatel-lucent.com>
Date: Sunday, March 23, 2014 11:14 = AM
To: Lou Berger <lberger@labn.net>, "Andrew G. Malis" &= lt;agmalis@gmail.com>, Russ Whi= te <russw@riw.us>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Ines Robles <mariainesrobles@googlemail.co= m>, Alia Atlas <akatlas@ju= niper.net>, "rtg-chairs@ietf.org"= <rtg-chairs@ietf.org>, &q= uot;rtg-dir@ietf.org" <rtg-dir@ietf.org>
Subject: RE: [RTG-DIR] Routing Area= Health Check
Resent-From: <wg-alias-bounces@tools.ietf.org> Resent-To: Jeffrey Haas <jhaas@pfrc.org>, <nobo@cisco.com>, <dbrungard@att.com>, Lou Berger <lberger@labn.net>, <hadi@mojatatu.com>, <damascene.joachimpilla= i@verizon.com>, Jeffrey Haas <j= haas@pfrc.org>, <edc@google.com= >, <shares@ndzh.com>, "John= G. Scudder" <jgs@juniper.net>, <chopps@rawdofmt.org&g= t;, <hannes@juniper.net>, "Joel M. Halpern" <jmh= @joelhalpern.com>, <bew@cisco.co= m>, "Bitar, Nabil N" <nabil.n.bitar@verizon.com>, <giheron@cisco.com>, <thomas.morin@orange.com= >, <martin.vig= oureux@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, <sratliff@cisco.com>, George Swallow <swallow@cisco.com<= /a>>, Loa Andersson <loa@pi.nu>, = Ross Callon <rcallon@juniper.net<= /a>>, <bensons@queuefull.net= >, BOCCI Matthew <Matt= hew.Bocci@alcatel-lucent.com>, <= akr@cisco.com>, <acee= .lindem@ericsson.com>, <jpv@cisc= o.com>, Julien Meuric <julien.meuri= c@orange.com>, <mmcbride7@= gmail.com>, <stig@venaas.com>, BOCCI Matthew <Matthew.Bocci@alcatel-lucent.com>, <agmalis@gmail.com>, <mcr+ietf@sandelman.ca>= ;, <mariainesrobles@gmail.c= om>, <aretana@cisco.com&= gt;, <jeff.tantsura@ericsson.c= om>, <narten@us.ibm.com&= gt;, <jguichar@cisco.com>, = <Sandra.Murphy@sparta.com>, <morrowc@ops-netman.net&g= t;, <aretana@cisco.com>, &qu= ot;John G. Scudder" <jgs@juniper= .net>, <akatlas@gmail.com>, Adrian Farrel <adrian@olddog.co.= uk>
Resent-Date: Sunday, March 23, 2014= 11:14 AM

mpls has just= started that following London's meeting.
Team of ~8 reviewers. First English review ongoing.

There were signs indicating the need for that.
Adrian's talk in mpls triggered the call for volunteers.

I think it is a good idea, especially if it enables to catch those sentence= s which can be understood technicaly differently.

-m
De : L= ou Berger
Envoy=E9 : 2= 2/03/2014 19:45
=C0 : A= ndrew G. Malis; Russ White
Cc : A= drian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg-dir@ietf.org
Objet : R= e: [RTG-DIR] Routing Area Health Check

This is a great idea.

Lou


On March 22, 2014 1:28:15 PM "Andrew G. Malis" <agmalis@gmail.com> wrote:

> I recently did some language editing on a draft I was technically
> reviewing for the Independent Series Editor (the author wasn't a
> native English speaker). Perhaps we could put together a list of area<= br> > volunteers that are willing to do a language cleanup pass on drafts > that could use it just before they go into WG LC. You wouldn't want to=
> do it any earlier.
>
> Cheers,
> Andy
>
> On Sat, Mar 22, 2014 at 5:55 PM, Russ White <russw@riw.us> wrote:
> >
> >> About this: ""What is making life hard for document= authors? How could
> >> working groups be doing better?"
> >
> > Another point we might want to consider is whether or not we shou= ld be at
> > least something proactive about the language barrier issues -- li= ke making
> > certain the community knows the RG-DIR is open to helping folks w= ith issues
> > on the language side, or even to provide a "non-native speak= er review." This
> > might help improve the output of the area as a whole (?).
> >
> > :-)
> >
> > Russ
> >
> >
> >
>


 --_000_CF55BC8BA3761swallowciscocom_-- From nobody Mon Mar 24 15:12:16 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5671A028F for ; Mon, 24 Mar 2014 15:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.101 X-Spam-Level: X-Spam-Status: No, score=-99.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, 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 GBYver6qIYT1 for ; Mon, 24 Mar 2014 15:12:10 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:3::243]) by ietfa.amsl.com (Postfix) with SMTP id 5C74C1A02B3 for ; Mon, 24 Mar 2014 15:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path; bh=r+cb4YdZ9NgnAIoANs5tlJbpIOm4H+dJDXG8jzEBpGM=; b=5CI4AG50/vXh3TEPgR8YxxWjWLxKFGw1edUHTXruLZRG/3gr69w8eI2VHQ9NQLUi9fIOPnGyEYPQj xguW7wuDBXTrhJM+moVGePOrn6+7K7KVtC9CHEOflQkCoDY5BOuPTKNdv11iQJQPgRfskQC0bpvRy6 oiSmqXX8m/YNAunk= Received: from NXMDA1.org.apnic.net (unknown [203.119.93.247]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTP for ; Tue, 25 Mar 2014 17:21:29 +1000 (EST) Received: from [192.168.1.7] (203.119.101.249) by NXMDA1.org.apnic.net (203.119.107.11) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 25 Mar 2014 08:12:06 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Geoff Huston In-Reply-To: <047201cf45d6$465e3250$d31a96f0$@riw.us> Date: Tue, 25 Mar 2014 09:12:05 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <9B091063-01ED-4DA0-AED3-712B9EBEF770@apnic.net> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> <047201cf45d6$465e3250$d31a96f0$@riw.us> To: X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/pMia50MKZ5gll6sry1EEICX7s3Q Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 22:12:12 -0000 On 23 Mar 2014, at 12:54 am, Russ White wrote: >=20 > SIDR has "finished," the RPKI, which could be folded into IDR, and the = path > protection stuff is a science experiment that isn't deployable in the = real > world. Suggest moving the path protection work into the routing = research > group until something that will actually provide some real protection = comes > along. Only if you are using the term "finished" in the sense of "not = finished". :-) There are, as far as I can see, outstanding with validation, local = repository cache management, signalling, as well as path protection that = tend to suggest "unsafe to deploy" to me. Sometimes progress is hard in the routing area because we put = impediments in our way and tend to concentrate on the self-imposed = impediments of process over substance. On the other hand sometimes = progress is hard because we don't adequately understand the problem = space, and then we get confused over the difference between progress and = motion. Exhorting participants for more rapid outcomes and stirring up = activity often generates just motion, and then the undoing of this = motion and trying to identify actual achievements and directions where = progress can actually be made becomes downright difficult.=20 From nobody Mon Mar 24 16:33:02 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADCC1A000B for ; Mon, 24 Mar 2014 16:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yzbDb7InEjqq for ; Mon, 24 Mar 2014 16:32:57 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82E1A028E for ; Mon, 24 Mar 2014 16:32:48 -0700 (PDT) Received: from mail69-ch1-R.bigfish.com (10.43.68.228) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Mon, 24 Mar 2014 23:32:47 +0000 Received: from mail69-ch1 (localhost [127.0.0.1]) by mail69-ch1-R.bigfish.com (Postfix) with ESMTP id 837D7203E5; Mon, 24 Mar 2014 23:32:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail69-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(377454003)(51704005)(24454002)(81686001)(83322001)(74876001)(2656002)(87936001)(19580405001)(19580395003)(80022001)(65816001)(33646001)(87266001)(80976001)(83072002)(74316001)(95416001)(74366001)(74706001)(85852003)(54316002)(20776003)(56776001)(77982001)(97186001)(59766001)(63696002)(79102001)(66066001)(97336001)(85306002)(51856001)(46102001)(54356001)(95666003)(53806001)(92566001)(69226001)(50986001)(4396001)(93136001)(47976001)(98676001)(74662001)(49866001)(47736001)(56816005)(90146001)(76482001)(94946001)(81542001)(81816001)(94316002)(76576001)(81342001)(74502001)(31966008)(47446002)(86362001)(76786001)(76796001)(93516002)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB563; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:F8DAD0C5.EEB9BE2.F2F17DBB.58FDA169.20304; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1 (MessageSwitch) id 1395703965459313_18150; Mon, 24 Mar 2014 23:32:45 +0000 (UTC) Received: from CH1EHSMHS019.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail69-ch1.bigfish.com (Postfix) with ESMTP id 64D491600BD; Mon, 24 Mar 2014 23:32:45 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS019.bigfish.com (10.43.70.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Mar 2014 23:32:44 +0000 Received: from BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 24 Mar 2014 23:32:44 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB563.namprd05.prod.outlook.com (10.141.202.144) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 24 Mar 2014 23:32:43 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0898.005; Mon, 24 Mar 2014 23:32:43 +0000 From: John E Drake To: Geoff Huston , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQABx1xgAABGQpEAADQ/EAAHX0dYAAAshE8A== Date: Mon, 24 Mar 2014 23:32:42 +0000 Message-ID: <68fcbbd1d0204912947f5582634431f4@BLUPR05MB562.namprd05.prod.outlook.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> <047201cf45d6$465e3250$d31a96f0$@riw.us> <9B091063-01ED-4DA0-AED3-712B9EBEF770@apnic.net> In-Reply-To: <9B091063-01ED-4DA0-AED3-712B9EBEF770@apnic.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.13] x-forefront-prvs: 01604FB62B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/nz-GV6vHfWcqLAXDR_p78xG9Nvg Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 23:33:00 -0000 "Never confuse movement with action" is one of Hemingway's most popular quo= tations and is included in the book, Neverisms: A Quotation Lover's Guide t= o Things You Should Never Do, Never Say, or Never Forget. Yours Irrespectively, John > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Geoff Huston > Sent: Monday, March 24, 2014 3:12 PM > To: rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Routing Area Health Check >=20 > On 23 Mar 2014, at 12:54 am, Russ White wrote: > > > > SIDR has "finished," the RPKI, which could be folded into IDR, and the > > path protection stuff is a science experiment that isn't deployable in > > the real world. Suggest moving the path protection work into the > > routing research group until something that will actually provide some > > real protection comes along. >=20 >=20 > Only if you are using the term "finished" in the sense of "not finished".= :-) >=20 > There are, as far as I can see, outstanding with validation, local reposi= tory > cache management, signalling, as well as path protection that tend to sug= gest > "unsafe to deploy" to me. >=20 > Sometimes progress is hard in the routing area because we put impediments > in our way and tend to concentrate on the self-imposed impediments of > process over substance. On the other hand sometimes progress is hard > because we don't adequately understand the problem space, and then we get > confused over the difference between progress and motion. Exhorting > participants for more rapid outcomes and stirring up activity often gener= ates > just motion, and then the undoing of this motion and trying to identify a= ctual > achievements and directions where progress can actually be made becomes > downright difficult. >=20 >=20 >=20 From nobody Tue Mar 25 01:03:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2D61A00E5; Mon, 24 Mar 2014 21:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zvm6Fgashsqf; Mon, 24 Mar 2014 21:22:43 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70A061A00E1; Mon, 24 Mar 2014 21:22:43 -0700 (PDT) X-AuditID: c618062d-b7f858e0000031c7-6b-5331023e2007 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id EE.91.12743.E3201335; Tue, 25 Mar 2014 05:12:47 +0100 (CET) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 00:22:40 -0400 From: Jeff Tantsura To: Ines Robles , Adrian Farrel Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQACTXiwAACpRvAAAPt1AAABSOpYAAC/ajAABBER0A Date: Tue, 25 Mar 2014 04:22:39 +0000 Message-ID: References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_CF55D37D51650jefftantsuraericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyuXSPn649k2GwwefDIhY/em4wW3y9lmax oeU/i8WDwwvZLBasecruwOrxdMJkdo8lS34yeVxvusrusWLzSsYAligum5TUnMyy1CJ9uwSu jOfd21gLJp5jrLi06Sl7A+PtbYxdjJwcEgImEhebnkDZYhIX7q1n62Lk4hASOMIocfvIB3YI ZzmjxLuXJ9lAqtgEDCT+fzvOAmKLCIRLXF+yjgnEZhaoknj85jRYjTBQzcf/lxkhagwlnu5b yQRhR0ksuv0OrJdFQFWif9E1sDivgLnE/6apYHEhgX4mia75+iA2p0CgRP+dBawgNiPQdd9P rYHaJS5x68l8JoirBSSW7DnPDGGLSrx8/A+sXlRAT+Leo7ksEHEliY+/57ND9MZIHFx6nhFi r6DEyZlPWCYwis1CMnYWkrJZSMog4gYS78/NZ4awtSWWLXwNZetLbPxylhHCtpZ4Muc4G7Ka BYwcqxg5SotTy3LTjQw2MQJj95gEm+4Oxj0vLQ8xSnOwKInzfnnrHCQkkJ5YkpqdmlqQWhRf VJqTWnyIkYmDU6qBcStzSuAB3zUsCj1Ge7Ze0/L24/ph6+D2Msj+87rIE8IqHZvd3RTfa3x/ /46be6bKZeGP8RcebXJrmPNje3CFwc2lRwRfHLJR9meN3C+X+9D+SuTV2bdn/slU17uumb7Y hFd8SfeCTS3Kd83My/5+fxb/Yu8S8altH4MvJxY/K/OMYggLYd6urcRSnJFoqMVcVJwIAPbo 7k+rAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/E_G4YvlzSET5RvqxS9U9H8TDN54 X-Mailman-Approved-At: Tue, 25 Mar 2014 01:03:47 -0700 Cc: "rtg-dir@ietf.org" , Alia Atlas , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 04:22:47 -0000 --_000_CF55D37D51650jefftantsuraericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Perhaps would be worthwhile to present Adrian's presentation "What makes fo= r a quality RFC" for every wg. Cheers, Jeff From: Ines Robles > Date: Sunday, March 23, 2014 7:19 AM To: Adrian Farrel > Cc: "rtg-dir@ietf.org" >, "rtg-chairs@ietf.org" >, Alia Atlas > Subject: Re: [RTG-DIR] Routing Area Health Check Resent-To: >, >, >, >, >, >, >, >, >, >, >, "hannes@juniper.net" >, Joel Halpern >, >, >, >, Thomas Morin >, Martin Vigoureux >, >, >, <= swallow@cisco.com>, Loa Andersson >, >, >, >, >, Acee Lindem Lindem III >, >, >, >, >, >, >, >, >, Alvaro Retana >, Jeff T= antsura >, >, >, >, >, Alvaro Retana= >, >, Alia Atlas >, <= adrian@olddog.co.uk> Hi, About this: =93What is making life hard for document authors?=94 Maybe, one problem is that the authors don=92t know all the steps, that a d= ocument goes through during the process of publication, of course it is res= ponsibility of the authors read the required information to learn about it;= This is the minimum thing, that an author must do, if he/she wants to publ= ish a document in the IETF. But, I think, sometimes the authors believe that, the work is done when a d= ocument is submitted to the IESG, then for example they forget to address t= he Gen-art review, AUTH48, and additionals reviews. Thinking that maybe, a fast checklist is going to help them to know what th= ey should address to get a document published :-) Thanks and Regards Ines 2014-03-23 5:36 GMT-03:00 Adrian Farrel >: Yeah, I like that all sorts of ideas are being thrown into the pot. We shou= ld be a sufficiently adult subset of the crazies to be able to handle that. However, we are talking like engineers :-) Might be nice to focus back on the questions of what is a problem for getti= ng work done. We can come back to how to fix it. Now, all of you complaining that the problem needs to be defined... ...please define the problem :-) Adrian From: Alia Atlas [mailto:akatlas@gmail.com] Sent: 22 March 2014 22:48 To: Acee Lindem Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check Acee, None of those different directions seems to me to be bad. The question was deliberately ask unframed and undefined. Adrian and I will define and frame it more - but first we wanted to hear the unframed but thoughtful discussion. Providing reasoning does help everyone determine if they are on the same page. Regards, Alia On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem > wrote: I agree with Loa that the problem needs to be defined - this discussion has already diverged into 4 different directions. Thanks, Acee On 3/22/14 3:15 AM, "Loa Andersson" > wrote: >John, > >How about deciding what is broken first, and then looking at the >actions?? > >/Loa > >On 2014-03-21 21:44, John E Drake wrote: >> Adrian, >> >> Combine IS-IS and OSPF >> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >> >> There is probably some synergy between PCE, SFC, and SPRING that needs >>to be exploited >> >> Combine BFD and the OAM/protection switching part of MPLS >> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>Farrel >>> Sent: Friday, March 21, 2014 11:31 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Cc: Alia Atlas >>> Subject: [RTG-DIR] Routing Area Health Check >>> >>> Hello Directorate and WG chairs, >>> >>> Alia and I have been discussing the Routing Area, its work, its >>>output, and its >>> working groups. >>> >>> We have reached a conclusion (which perhaps we should have come to >>>sooner) >>> that we need your help and input. >>> >>> The crunch question for us is "What makes it hard to get work done in >>>the >>> Routing Area?" What gets in the way of your work? What is making life >>>hard >>> for document authors? How could working groups be doing better? We are >>> open to all and every type of answer. We are happy to have quick, >>>one-line >>> answers or deeply-considered essays. >>> >>> What do you think? >>> >>> Thanks for all your input, >>> Adrian and Alia >>> >>> PS Please respond to both aliases because not everyone is on both >>>lists. Sorry >>> that that means some of you will get duplicates. >>> >>> >> >> > >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > --_000_CF55D37D51650jefftantsuraericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Perhaps would be worthwhile to present Adrian's presentation "Wha= t makes for a quality RFC" for every wg.


Cheers,
Jeff

From: Ines Robles <mariainesrobles@googlemail.com>=
Date: Sunday, March 23, 2014 7:19 A= M
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "r= tg-chairs@ietf.org" <rtg= -chairs@ietf.org>, Alia Atlas <akatlas@juniper.net<= /a>>
Subject: Re: [RTG-DIR] Routing Area= Health Check
Resent-To: <jhaas@pfrc.org>, <nobo@cisco.com>, <dbrungard= @att.com>, <lberger@labn.net<= /a>>, <hadi@mojatatu.com>, <damascene.joachimpilla= i@verizon.com>, <jhaas@pfrc.org= >, <edc@google.com>, <shares@ndzh.com>, <jgs@juniper.net>, <chopps@rawdofmt.org>, "hannes@juniper.net" <hannes@juniper.net>, Joel Halpern <jmh@joelhalpern.co= m>, <bew@cisco.com>, <= nabil.n.bitar@verizon.com&= gt;, <giheron@cisco.com>, Thomas Morin <thomas.morin@o= range.com>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, <sratliff@cisco.com>, <= swallow@cisco.com>, Loa Anderss= on <loa@pi.nu>, <rcallon@juniper.net>, <bensons@queuefull.net>, <matthew.bocci@alca= tel-lucent.com>, <akr@cisco.com<= /a>>, Acee Lindem Lindem III <acee.lindem@ericsson.com>, <jpv@cisco.com>, <julien.meuric@orange.com>, <mmcbride7@gmail.com&= gt;, <stig@venaas.com>, <matthew.bocci@alcatel-luc= ent.com>, <agmalis@gmail.com>, <mcr+ietf@sandelman.ca>= ;, <mariainesrobles@gmail.c= om>, Alvaro Retana <aretana@= cisco.com>, Jeff Tantsura <jeff.tants= ura@ericsson.com>, <narten@u= s.ibm.com>, <jguichar@cisco= .com>, <Sandra.Murphy= @sparta.com>, <morrowc@ops-netman.net&g= t;, Alvaro Retana <aretana@cisco.co= m>, <jgs@juniper.net>, = Alia Atlas <akatlas@gmail.com&g= t;, <adrian@olddog.co.uk>

= Hi,


= About this: =93What is making life hard for document authors?=94


= Maybe, one problem is that = the authors don=92t know all the steps, that a document goes through during the process of publication, of course = it is responsibility of the authors read the required information to learn = about it; This is the minimum thing, that an author must do, if he/she want= s to publish a document in the IETF.


= But, I think, sometimes the= authors believe that, the work is done when a document is submitted to the IESG, then for example they forget to = address the Gen-art review, AUTH48, and additionals revi= ews.


= Thinking that maybe, a fast= checklist is going to help them to know what they should address to get a document published :-)


= Thanks and Regards


Ines


2014-03-23 5:36 GMT-03:00 Adrian Farrel <adrian@olddog.= co.uk>:

Yeah, I like that all sorts of ide= as are being thrown into the pot. We should be a sufficiently adult subset = of the crazies to be able to handle that.

 

However, we are talking like engin= eers :-)

Might be nice to focus back on the= questions of what is a problem for getting work done. We can come back to = how to fix it.

 

Now, all of you complaining that t= he problem needs to be defined...

...please define the problem :-)

 

Adrian

 

 

Acee,

 

None of those different directions seems to me to be= bad.

The question was deliberately ask unframed and undef= ined.

Adrian and I will define and frame it more - but fir= st we wanted 

to hear the unframed but thoughtful discussion.

 

Providing reasoning does help everyone determine if = they are

on the same page.

 

Regards,

Alia

 <= /p>

On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem <acee.lindem@eric= sson.com> wrote:

I agree with Loa that the problem needs to be define= d - this discussion
has already diverged into 4 different directions.

Thanks,
Acee


On 3/22/14 3:15 AM, "Loa Andersson" <loa@pi.nu> wrote:

>John,
>
>How about deciding what is broken first, and then looking at the
>actions??
>
>/Loa
>
>On 2014-03-21 21:44, John E Drake wrote:
>> Adrian,
>>
>> Combine IS-IS and OSPF
>>
>> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work the= re
>>
>> There is probably some synergy between PCE, SFC, and SPRING that n= eeds
>>to be exploited
>>
>> Combine BFD and the OAM/protection switching part of MPLS
>>
>> Close Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, March 21, 2014 11:31 AM
>>> To: rtg-= dir@ietf.org; rtg-chairs@ietf.org
>>> Cc: Alia Atlas
>>> Subject: [RTG-DIR] Routing Area Health Check
>>>
>>> Hello Directorate and WG chairs,
>>>
>>> Alia and I have been discussing the Routing Area, its work, it= s
>>>output, and its
>>> working groups.
>>>
>>> We have reached a conclusion (which perhaps we should have com= e to
>>>sooner)
>>> that we need your help and input.
>>>
>>> The crunch question for us is "What makes it hard to get = work done in
>>>the
>>> Routing Area?" What gets in the way of your work? What is= making life
>>>hard
>>> for document authors? How could working groups be doing better= ? We are
>>> open to all and every type of answer. We are happy to have qui= ck,
>>>one-line
>>> answers or deeply-considered essays.
>>>
>>> What do you think?
>>>
>>> Thanks for all your input,
>>> Adrian and Alia
>>>
>>> PS Please respond to both aliases because not everyone is on b= oth
>>>lists. Sorry
>>> that that means some of you will get duplicates.
>>>
>>>
>>
>>
>
>--
>
>
>Loa Andersson                 &= nbsp;      email: loa@mail01.huawei.com
>Senior MPLS Expert               &nb= sp;          loa@pi.nu
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>

 


 --_000_CF55D37D51650jefftantsuraericssoncom_-- From nobody Tue Mar 25 01:04:02 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9661B1A00EB; Mon, 24 Mar 2014 21:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 KNmpm3QQuysB; Mon, 24 Mar 2014 21:30:12 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 542CC1A00E1; Mon, 24 Mar 2014 21:30:12 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hu19so6949394vcb.15 for ; Mon, 24 Mar 2014 21:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ALOSRgp15uJIWrtfTRCO17IUOSBtzOUueOpKAj/A5gM=; b=XA3TZ4ykZonuCIbfODro6z0nxq4XX6J8/aSLcAf3yqYwa+uLutvhJl2bf/eNsWsFhu 8LxL33PlJMFzj7Icb1VK4RCnQuMqH7d8mnEItsTwOdSwMuKDToZ5Vd6kSxqAAtVpGmDP WJxFqdWQBvovg9YTkQGT172jkmKhUZRwr8+Noctx/4tp8ostS8WK9Lifqs4C1itw3YER +DMDdByd2ob/+rAeKjlxVzhJzDWH67ui8ecXBbiDeWTO4QyhbOwS2Bzen93lbxJStA8M A0tE0RZ0E3yzp6HFilKL5CgMknm/C7pAhul4R5ryGdrY1nvKB/+NIvfb5My0Ol7fcV2h IhzQ== MIME-Version: 1.0 X-Received: by 10.58.229.167 with SMTP id sr7mr51840994vec.7.1395721811273; Mon, 24 Mar 2014 21:30:11 -0700 (PDT) Received: by 10.221.16.3 with HTTP; Mon, 24 Mar 2014 21:30:10 -0700 (PDT) In-Reply-To: References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> Date: Tue, 25 Mar 2014 01:30:10 -0300 Message-ID: From: Ines Robles To: Jeff Tantsura Content-Type: multipart/alternative; boundary=047d7bd6b46ac42df304f566cef3 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/hSL_VpUwgUxLHvshv94T7URRrKQ X-Mailman-Approved-At: Tue, 25 Mar 2014 01:03:46 -0700 Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 04:30:13 -0000 --047d7bd6b46ac42df304f566cef3 Content-Type: text/plain; charset=ISO-8859-1 +1 2014-03-25 1:22 GMT-03:00 Jeff Tantsura : > Perhaps would be worthwhile to present Adrian's presentation "What > makes for a quality RFC" for every wg. > > > Cheers, > Jeff > > > --047d7bd6b46ac42df304f566cef3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1=A0

2014-03-25 1:22 GMT-03:00 Jeff Tantsura <jeff.tantsura@eric= sson.com>:
Perhaps would be worthwhile to present Adrian's presentation "= ;What makes for a quality RFC" for every wg.


Cheers,
Jeff


--047d7bd6b46ac42df304f566cef3-- From nobody Tue Mar 25 06:04:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134331A0386; Tue, 25 Mar 2014 03:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 zcljjZr0dAyu; Tue, 25 Mar 2014 03:03:59 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B0D2B1A018B; Tue, 25 Mar 2014 03:03:58 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 17F411802AB1; Tue, 25 Mar 2014 11:03:57 +0100 (CET) Message-ID: <5331548F.10409@pi.nu> Date: Tue, 25 Mar 2014 11:03:59 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem , Jeff Tantsura References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> In-Reply-To: <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/rmkHbHb7SHs2S14lugK2rtDcs5g Cc: Adrian Farrel , Ines Robles , Alia Atlas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 10:04:06 -0000 Acee, a better idea than doing it once in ever wg. I also like the initiative from Andy to send out the link to Adrians slides: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-15.pptx More wg chairs could do that /Loa. On 2014-03-25 10:44, Acee Lindem wrote: > > On Mar 25, 2014, at 12:22 AM, Jeff Tantsura > wrote: > >> Perhaps would be worthwhile to present Adrian's presentation "What >> makes for a quality RFC" for every wg. > > How about simply replaying it once in the Routing Area Open Meeting? > > Acee > >> >> >> Cheers, >> Jeff >> >> From: Ines Robles > > >> Date: Sunday, March 23, 2014 7:19 AM >> To: Adrian Farrel > >> Cc: "rtg-dir@ietf.org " > >, "rtg-chairs@ietf.org >> " > >, Alia Atlas > > >> Subject: Re: [RTG-DIR] Routing Area Health Check >> Resent-To: >, > >, > >, > >, > >, > >, > >, >, >> >, > >, > >, "hannes@juniper.net >> " > >, Joel Halpern > >, >, >> >, >> >, Thomas Morin >> >, Martin >> Vigoureux > >, >> >, >> >, > >, Loa Andersson > >, > >, > >, > >, > >, Acee Lindem Lindem III >> >, >> >, > >, > >, > >, > >, > >, > >, > >, Alvaro Retana > >, Jeff Tantsura > >, > >, > >, > >, > >, Alvaro Retana > >, > >, Alia Atlas > >, > > >> >>> * >>> Hi, >>> >>> About this: “What is making life hard for document authors?” >>> >>> Maybe, one problem is that the authors don’t know all the steps, that >>> a document goes through during the process of publication, of course >>> it is responsibility of the authors read the required information to >>> learn about it; This is the minimum thing, that an author must do, if >>> he/she wants to publish a document in the IETF. >>> >>> But, I think, sometimes the authors believe that, the work is done >>> when a document is submitted to the IESG, then for example they >>> forget to address the Gen-art review, AUTH48, and additionals reviews. >>> >>> Thinking that maybe, a fast checklist is going to help them to know >>> what they should address to get a document published :-) >>> >>> Thanks and Regards >>> >>> Ines* >>> >>> >>> 2014-03-23 5:36 GMT-03:00 Adrian Farrel >> >: >>>> Yeah, I like that all sorts of ideas are being thrown into the pot. >>>> We should be a sufficiently adult subset of the crazies to be able >>>> to handle that.____ >>>> __ __ >>>> However, we are talking like engineers :-)____ >>>> Might be nice to focus back on the questions of what is a problem >>>> for getting work done. We can come back to how to fix it.____ >>>> __ __ >>>> Now, all of you complaining that the problem needs to be defined...____ >>>> ...please define the problem :-)____ >>>> __ __ >>>> Adrian____ >>>> __ __ >>>> *From:*Alia Atlas [mailto:akatlas@gmail.com ] >>>> *Sent:* 22 March 2014 22:48 >>>> *To:* Acee Lindem >>>> *Cc:* Loa Andersson; John E Drake; adrian@olddog.co.uk >>>> ; rtg-dir@ietf.org >>>> ; rtg-chairs@ietf.org >>>> ; Alia Atlas >>>> *Subject:* Re: [RTG-DIR] Routing Area Health Check____ >>>> __ __ >>>> Acee,____ >>>> __ __ >>>> None of those different directions seems to me to be bad.____ >>>> The question was deliberately ask unframed and undefined.____ >>>> Adrian and I will define and frame it more - but first we wanted ____ >>>> to hear the unframed but thoughtful discussion.____ >>>> __ __ >>>> Providing reasoning does help everyone determine if they are____ >>>> on the same page.____ >>>> __ __ >>>> Regards,____ >>>> Alia____ >>>> >>>> __ __ >>>> >>>> On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem >>>> > wrote:____ >>>> I agree with Loa that the problem needs to be defined - this discussion >>>> has already diverged into 4 different directions. >>>> >>>> Thanks, >>>> Acee____ >>>> >>>> >>>> On 3/22/14 3:15 AM, "Loa Andersson" > >>>> wrote: >>>> >>>> >John, >>>> > >>>> >How about deciding what is broken first, and then looking at the >>>> >actions?? >>>> > >>>> >/Loa >>>> > >>>> >On 2014-03-21 21:44, John E Drake wrote: >>>> >> Adrian, >>>> >> >>>> >> Combine IS-IS and OSPF >>>> >> >>>> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >>>> >> >>>> >> There is probably some synergy between PCE, SFC, and SPRING that needs >>>> >>to be exploited >>>> >> >>>> >> Combine BFD and the OAM/protection switching part of MPLS >>>> >> >>>> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >>>> >> >>>> >> Yours Irrespectively, >>>> >> >>>> >> John >>>> >> >>>> >>> -----Original Message----- >>>> >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org ] On >>>> Behalf Of Adrian >>>> >>>Farrel >>>> >>> Sent: Friday, March 21, 2014 11:31 AM >>>> >>> To:rtg-dir@ietf.org ; rtg-chairs@ietf.org >>>> >>>> >>> Cc: Alia Atlas >>>> >>> Subject: [RTG-DIR] Routing Area Health Check >>>> >>> >>>> >>> Hello Directorate and WG chairs, >>>> >>> >>>> >>> Alia and I have been discussing the Routing Area, its work, its >>>> >>>output, and its >>>> >>> working groups. >>>> >>> >>>> >>> We have reached a conclusion (which perhaps we should have come to >>>> >>>sooner) >>>> >>> that we need your help and input. >>>> >>> >>>> >>> The crunch question for us is "What makes it hard to get work done in >>>> >>>the >>>> >>> Routing Area?" What gets in the way of your work? What is making life >>>> >>>hard >>>> >>> for document authors? How could working groups be doing better? We are >>>> >>> open to all and every type of answer. We are happy to have quick, >>>> >>>one-line >>>> >>> answers or deeply-considered essays. >>>> >>> >>>> >>> What do you think? >>>> >>> >>>> >>> Thanks for all your input, >>>> >>> Adrian and Alia >>>> >>> >>>> >>> PS Please respond to both aliases because not everyone is on both >>>> >>>lists. Sorry >>>> >>> that that means some of you will get duplicates. >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> > >>>> >-- >>>> > >>>> > >>>> >Loa Andersson email:loa@mail01.huawei.com >>>> >Senior MPLS Expertloa@pi.nu >>>> >Huawei Technologies (consultant) phone:+46 739 81 21 64 >>>> >____ >>>> >>>> __ __ >>> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Mar 25 06:04:26 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17701A0180; Tue, 25 Mar 2014 02:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9fMVMhAvbQwf; Tue, 25 Mar 2014 02:44:31 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 328B81A0173; Tue, 25 Mar 2014 02:44:31 -0700 (PDT) X-AuditID: c6180641-b7f2f8e000002cdc-7c-53314d16c3de Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 21.E4.11484.61D41335; Tue, 25 Mar 2014 10:32:06 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 05:44:29 -0400 From: Acee Lindem To: Jeff Tantsura Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgAEhSsQACTXiwAACpRvAAAPt1AAABSOpYAAC/ajAABBER0AABnoggA= Date: Tue, 25 Mar 2014 09:44:28 +0000 Message-ID: <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> In-Reply-To: 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_26ACAF161CA445B39030B51736FE8902ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonRFfM1zDYYH+3tsWPnhvMFl+vpVls aPnPYvHg8EI2iwVrnrI7sHo8nTCZ3WPJkp9MHtebrrJ7rNi8kjGAJYrLJiU1J7MstUjfLoEr 48Wn1UwF7dcYK1bN6WNqYNy+l7GLkZNDQsBE4u+JncwQtpjEhXvr2boYuTiEBI4wSnzfd4EV JCEksJxR4t/jMBCbTUBH4vmjf2ANIgJ6Evv+dLKCNDALnGeUuHP6I9hUYQEDiY//LzNCFBlK PN23kgnCTpJYs3M+UDMHB4uAqsSlBywgJq+AvcS+Y9EQe/cySWy50gu2l1PAQmLS7ilgrYxA x30/tQbMZhYQl7j1ZD4TxNECEkv2nId6QFTi5eN/rBC2osS+/unsEPXJEteOXAer4RUQlDg5 8wnLBEbRWUhGzUJSNgtJGUTcQOL9ufnMELa2xLKFr6FsfYmNX84yQtjWEpM6rzMiq1nAyLGK kaO0OLUsN93IcBMjMEKPSbA57mBc8MnyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanF hxiZODilGhiXll9SVTt+dU7iro4ldV4NBSWpM37dszbneHXuosSn5vuXEjzeP7aQELY7cClp MlsHR4j+tHkXtoboLb4k2cDBvVb/edGTvE/7ZCyYD8YLmU5eIZ33I91hTvc9SeMF0kmb332f t1jq/t6TcxPaPVLq3obt3Z3kLeF4LXTZFn6+vBYh+6wJ/AxKLMUZiYZazEXFiQDakwaWngIA AA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/J7Q1Hfdvq_Ad8U7_Y8T3IGjaeCc Cc: Adrian Farrel , Ines Robles , Alia Atlas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 09:44:36 -0000 --_000_26ACAF161CA445B39030B51736FE8902ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 25, 2014, at 12:22 AM, Jeff Tantsura > wrote: Perhaps would be worthwhile to present Adrian's presentation "What makes fo= r a quality RFC" for every wg. How about simply replaying it once in the Routing Area Open Meeting? Acee Cheers, Jeff From: Ines Robles > Date: Sunday, March 23, 2014 7:19 AM To: Adrian Farrel > Cc: "rtg-dir@ietf.org" >, "rtg-chairs@ietf.org" >, Alia Atlas > Subject: Re: [RTG-DIR] Routing Area Health Check Resent-To: >, >, >, >, >, >, >, >, >, >, >, "hannes@juniper.net" >, Joel Halpern >, >, >, >, Thomas Morin >, Martin Vigoureux >, >, >, <= swallow@cisco.com>, Loa Andersson >, >, >, >, >, Acee Lindem Lindem III >, >, >, >, >, >, >, >, >, Alvaro Retana >, Jeff T= antsura >, >, >, >, >, Alvaro Retana= >, >, Alia Atlas >, <= adrian@olddog.co.uk> Hi, About this: =93What is making life hard for document authors?=94 Maybe, one problem is that the authors don=92t know all the steps, that a d= ocument goes through during the process of publication, of course it is res= ponsibility of the authors read the required information to learn about it;= This is the minimum thing, that an author must do, if he/she wants to publ= ish a document in the IETF. But, I think, sometimes the authors believe that, the work is done when a d= ocument is submitted to the IESG, then for example they forget to address t= he Gen-art review, AUTH48, and additionals reviews. Thinking that maybe, a fast checklist is going to help them to know what th= ey should address to get a document published :-) Thanks and Regards Ines 2014-03-23 5:36 GMT-03:00 Adrian Farrel >: Yeah, I like that all sorts of ideas are being thrown into the pot. We shou= ld be a sufficiently adult subset of the crazies to be able to handle that. However, we are talking like engineers :-) Might be nice to focus back on the questions of what is a problem for getti= ng work done. We can come back to how to fix it. Now, all of you complaining that the problem needs to be defined... ...please define the problem :-) Adrian From: Alia Atlas [mailto:akatlas@gmail.com] Sent: 22 March 2014 22:48 To: Acee Lindem Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check Acee, None of those different directions seems to me to be bad. The question was deliberately ask unframed and undefined. Adrian and I will define and frame it more - but first we wanted to hear the unframed but thoughtful discussion. Providing reasoning does help everyone determine if they are on the same page. Regards, Alia On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem > wrote: I agree with Loa that the problem needs to be defined - this discussion has already diverged into 4 different directions. Thanks, Acee On 3/22/14 3:15 AM, "Loa Andersson" > wrote: >John, > >How about deciding what is broken first, and then looking at the >actions?? > >/Loa > >On 2014-03-21 21:44, John E Drake wrote: >> Adrian, >> >> Combine IS-IS and OSPF >> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >> >> There is probably some synergy between PCE, SFC, and SPRING that needs >>to be exploited >> >> Combine BFD and the OAM/protection switching part of MPLS >> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>Farrel >>> Sent: Friday, March 21, 2014 11:31 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Cc: Alia Atlas >>> Subject: [RTG-DIR] Routing Area Health Check >>> >>> Hello Directorate and WG chairs, >>> >>> Alia and I have been discussing the Routing Area, its work, its >>>output, and its >>> working groups. >>> >>> We have reached a conclusion (which perhaps we should have come to >>>sooner) >>> that we need your help and input. >>> >>> The crunch question for us is "What makes it hard to get work done in >>>the >>> Routing Area?" What gets in the way of your work? What is making life >>>hard >>> for document authors? How could working groups be doing better? We are >>> open to all and every type of answer. We are happy to have quick, >>>one-line >>> answers or deeply-considered essays. >>> >>> What do you think? >>> >>> Thanks for all your input, >>> Adrian and Alia >>> >>> PS Please respond to both aliases because not everyone is on both >>>lists. Sorry >>> that that means some of you will get duplicates. >>> >>> >> >> > >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > --_000_26ACAF161CA445B39030B51736FE8902ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 25, 2014, at 12:22 AM, Jeff Tantsura <jeff.tantsura@ericsson.com> wrote:

Perhaps would be worthwhile to present Adrian's presentation "Wha= t makes for a quality RFC" for every wg.

How about simply replaying it once in the Routing Area Open Meeting?&n= bsp;

Acee 



Cheers,
Jeff

From: Ines Robles <mariainesrobles@googlemail.com>=
Date: Sunday, March 23, 2014 7:19 A= M
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "r= tg-chairs@ietf.org" <rtg= -chairs@ietf.org>, Alia Atlas <akatlas@juniper.net<= /a>>
Subject: Re: [RTG-DIR] Routing Area= Health Check
Resent-To: <jhaas@pfrc.org>, <nobo@cisco.com>, <dbrungard= @att.com>, <lberger@labn.net<= /a>>, <hadi@mojatatu.com>, <damascene.joachimpilla= i@verizon.com>, <jhaas@pfrc.org= >, <edc@google.com>, <shares@ndzh.com>, <jgs@juniper.net>, <chopps@rawdofmt.org>, "hannes@juniper.net" <hannes@juniper.net>, Joel Halpern <jmh@joelhalpern.co= m>, <bew@cisco.com>, <= nabil.n.bitar@verizon.com&= gt;, <giheron@cisco.com>, Thomas Morin <thomas.morin@o= range.com>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, <sratliff@cisco.com>, <= swallow@cisco.com>, Loa Anderss= on <loa@pi.nu>, <rcallon@juniper.net>, <bensons@queuefull.net>, <matthew.bocci@alca= tel-lucent.com>, <akr@cisco.com<= /a>>, Acee Lindem Lindem III <acee.lindem@ericsson.com>, <jpv@cisco.com>, <julien.meuric@orange.com>, <mmcbride7@gmail.com&= gt;, <stig@venaas.com>, <matthew.bocci@alcatel-luc= ent.com>, <agmalis@gmail.com>, <mcr+ietf@sandelman.ca>= ;, <mariainesrobles@gmail.c= om>, Alvaro Retana <aretana@= cisco.com>, Jeff Tantsura <jeff.tants= ura@ericsson.com>, <narten@u= s.ibm.com>, <jguichar@cisco= .com>, <Sandra.Murphy= @sparta.com>, <morrowc@ops-netman.net&g= t;, Alvaro Retana <aretana@cisco.co= m>, <jgs@juniper.net>, = Alia Atlas <akatlas@gmail.com&g= t;, <adrian@olddog.co.uk>

Hi,

About this: =93What is making life hard for document authors?=94

Maybe, one problem is that the = authors don=92t know all the steps, that a document goes through during the process of publication, of course it is= responsibility of the authors read the required information to learn about= it; This is the minimum thing, that an author must do, if he/she wants to = publish a document in the IETF.

But, I think, sometimes the aut= hors believe that, the work is done when a document is submitted to the IESG, then for example they forget to = address the Gen-art review, AUTH48, and additionals revi= ews.

Thinking that maybe, a fast che= cklist is going to help them to know what they should address to get a document published :-)

Thanks and Regards

Ines


2014-03-23 5:36 GMT-03:00 Adrian Farrel <adrian@olddog.= co.uk>:
Yeah, I like that all sorts of i= deas are being thrown into the pot. We should be a sufficiently adult subse= t of the crazies to be able to handle that.
 
However, we are talking like eng= ineers :-)
Might be nice to focus back on t= he questions of what is a problem for getting work done. We can come back t= o how to fix it.
 
Now, all of you complaining that= the problem needs to be defined...
...please define the problem :-)=
 
Adrian
 
From: Alia Atlas [mail= to:akatlas@gmail.com= ]
Sent: 22 March 2014 22:48
To: Acee Lindem
Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.or= g; Alia Atlas
Subject: Re: [RTG-DIR] Routing Area Health Check
 
Acee,
 
None of those different directions seems to me to = be bad.
The question was deliberately ask unframed and und= efined.
Adrian and I will define and frame it more - but f= irst we wanted 
to hear the unframed but thoughtful discussion.=
 
Providing reasoning does help everyone determine i= f they are
on the same page.
 
Regards,
Alia

 <= /p>

On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem <<= a href=3D"mailto:acee.lindem@ericsson.com" target=3D"_blank">acee.lindem@er= icsson.com> wrote:
I agree with Loa that the problem needs to be defi= ned - this discussion
has already diverged into 4 different directions.

Thanks,
Acee


On 3/22/14 3:15 AM, "Loa Andersson" <loa@pi.nu> wrote:

>John,
>
>How about deciding what is broken first, and then looking at the
>actions??
>
>/Loa
>
>On 2014-03-21 21:44, John E Drake wrote:
>> Adrian,
>>
>> Combine IS-IS and OSPF
>>
>> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work the= re
>>
>> There is probably some synergy between PCE, SFC, and SPRING that n= eeds
>>to be exploited
>>
>> Combine BFD and the OAM/protection switching part of MPLS
>>
>> Close Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, March 21, 2014 11:31 AM
>>> To: rtg-= dir@ietf.org; rtg-chairs@ietf.org
>>> Cc: Alia Atlas
>>> Subject: [RTG-DIR] Routing Area Health Check
>>>
>>> Hello Directorate and WG chairs,
>>>
>>> Alia and I have been discussing the Routing Area, its work, it= s
>>>output, and its
>>> working groups.
>>>
>>> We have reached a conclusion (which perhaps we should have com= e to
>>>sooner)
>>> that we need your help and input.
>>>
>>> The crunch question for us is "What makes it hard to get = work done in
>>>the
>>> Routing Area?" What gets in the way of your work? What is= making life
>>>hard
>>> for document authors? How could working groups be doing better= ? We are
>>> open to all and every type of answer. We are happy to have qui= ck,
>>>one-line
>>> answers or deeply-considered essays.
>>>
>>> What do you think?
>>>
>>> Thanks for all your input,
>>> Adrian and Alia
>>>
>>> PS Please respond to both aliases because not everyone is on b= oth
>>>lists. Sorry
>>> that that means some of you will get duplicates.
>>>
>>>
>>
>>
>
>--
>
>
>Loa Andersson                 &= nbsp;      email: loa@mail01.huawei.com
>Senior MPLS Expert               &nb= sp;          loa@pi.nu
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>

 


--_000_26ACAF161CA445B39030B51736FE8902ericssoncom_-- From nobody Tue Mar 25 06:15:04 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543821A0150; Tue, 25 Mar 2014 06:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 u5AU8BP812Qf; Tue, 25 Mar 2014 06:15:00 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B39B31A0116; Tue, 25 Mar 2014 06:14:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Loa Andersson'" , "'Acee Lindem'" , "'Jeff Tantsura'" References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> <5331548F.10409@pi.nu> In-Reply-To: <5331548F.10409@pi.nu> Date: Tue, 25 Mar 2014 09:14:53 -0400 Message-ID: <009401cf482c$3679da30$a36d8e90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEUSZYWTwCBpcwfYKSo2uUSqm2+UQGRqzQOAfOTaXMCAGRCFAHgOsXBA33RAHsCcrn5UQLGdRk6m+bd76A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/enOUwQwy8CE3neB0I7nzNstg3d0 Cc: 'Adrian Farrel' , 'Ines Robles' , 'Alia Atlas' , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:15:03 -0000 Loa: I agree that this presentation was very helpful. I have used it to review IDR document. Sue -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Tuesday, March 25, 2014 6:04 AM To: Acee Lindem; Jeff Tantsura Cc: Adrian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check Acee, a better idea than doing it once in ever wg. I also like the initiative from Andy to send out the link to Adrians slides: http://www.ietf.org/proceedings/89/slides/slides-89-mpls-15.pptx More wg chairs could do that /Loa. On 2014-03-25 10:44, Acee Lindem wrote: > > On Mar 25, 2014, at 12:22 AM, Jeff Tantsura > > wrote: > >> Perhaps would be worthwhile to present Adrian's presentation "What >> makes for a quality RFC" for every wg. > > How about simply replaying it once in the Routing Area Open Meeting? > > Acee > >> >> >> Cheers, >> Jeff >> >> From: Ines Robles > > >> Date: Sunday, March 23, 2014 7:19 AM >> To: Adrian Farrel > >> Cc: "rtg-dir@ietf.org " > >, "rtg-chairs@ietf.org >> " > >, Alia Atlas > > >> Subject: Re: [RTG-DIR] Routing Area Health Check >> Resent-To: >, > >, > >, > >, > >, > >, > >, >, >> >, > >, > >, "hannes@juniper.net >> " > >, Joel Halpern > >, > >, > >, >> >, Thomas Morin >> >, Martin >> Vigoureux > >, >> >, >> >, > >, Loa Andersson > >, > >, > >, > >, > >, Acee Lindem Lindem III >> >, >> >, > >, > >, > >, > >, > >, > >, > >, Alvaro Retana > >, Jeff Tantsura >> >, >> >, > >, > >, > >, Alvaro Retana > >, > >, Alia Atlas > >, > > >> >>> * >>> Hi, >>> >>> About this: "What is making life hard for document authors?" >>> >>> Maybe, one problem is that the authors don't know all the steps, >>> that a document goes through during the process of publication, of >>> course it is responsibility of the authors read the required >>> information to learn about it; This is the minimum thing, that an >>> author must do, if he/she wants to publish a document in the IETF. >>> >>> But, I think, sometimes the authors believe that, the work is done >>> when a document is submitted to the IESG, then for example they >>> forget to address the Gen-art review, AUTH48, and additionals reviews. >>> >>> Thinking that maybe, a fast checklist is going to help them to know >>> what they should address to get a document published :-) >>> >>> Thanks and Regards >>> >>> Ines* >>> >>> >>> 2014-03-23 5:36 GMT-03:00 Adrian Farrel >> >: >>>> Yeah, I like that all sorts of ideas are being thrown into the pot. >>>> We should be a sufficiently adult subset of the crazies to be able >>>> to handle that.____ __ __ However, we are talking like engineers >>>> :-)____ Might be nice to focus back on the questions of what is a >>>> problem for getting work done. We can come back to how to fix >>>> it.____ __ __ Now, all of you complaining that the problem needs to >>>> be defined...____ ...please define the problem :-)____ __ __ >>>> Adrian____ __ __ *From:*Alia Atlas [mailto:akatlas@gmail.com >>>> ] >>>> *Sent:* 22 March 2014 22:48 >>>> *To:* Acee Lindem >>>> *Cc:* Loa Andersson; John E Drake; adrian@olddog.co.uk >>>> ; rtg-dir@ietf.org >>>> ; rtg-chairs@ietf.org >>>> ; Alia Atlas >>>> *Subject:* Re: [RTG-DIR] Routing Area Health Check____ __ __ >>>> Acee,____ __ __ None of those different directions seems to me to >>>> be bad.____ The question was deliberately ask unframed and >>>> undefined.____ Adrian and I will define and frame it more - but >>>> first we wanted ____ to hear the unframed but thoughtful >>>> discussion.____ __ __ Providing reasoning does help everyone >>>> determine if they are____ on the same page.____ __ __ Regards,____ >>>> Alia____ >>>> >>>> __ __ >>>> >>>> On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem >>>> > >>>> wrote:____ I agree with Loa that the problem needs to be defined - >>>> this discussion has already diverged into 4 different directions. >>>> >>>> Thanks, >>>> Acee____ >>>> >>>> >>>> On 3/22/14 3:15 AM, "Loa Andersson" > >>>> wrote: >>>> >>>> >John, >>>> > >>>> >How about deciding what is broken first, and then looking at the >>>> >actions?? >>>> > >>>> >/Loa >>>> > >>>> >On 2014-03-21 21:44, John E Drake wrote: >>>> >> Adrian, >>>> >> >>>> >> Combine IS-IS and OSPF >>>> >> >>>> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work >>>> >> there >>>> >> >>>> >> There is probably some synergy between PCE, SFC, and SPRING that >>>> >>needs to be exploited >>>> >> >>>> >> Combine BFD and the OAM/protection switching part of MPLS >>>> >> >>>> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >>>> >> >>>> >> Yours Irrespectively, >>>> >> >>>> >> John >>>> >> >>>> >>> -----Original Message----- >>>> >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org >>>> >>> ] On >>>> Behalf Of Adrian >>>> >>>Farrel >>>> >>> Sent: Friday, March 21, 2014 11:31 AM To:rtg-dir@ietf.org >>>> >>>; rtg-chairs@ietf.org >>>> >>>> >>> Cc: Alia Atlas >>>> >>> Subject: [RTG-DIR] Routing Area Health Check >>>> >>> >>>> >>> Hello Directorate and WG chairs, >>>> >>> >>>> >>> Alia and I have been discussing the Routing Area, its work, its >>>> >>>output, and its working groups. >>>> >>> >>>> >>> We have reached a conclusion (which perhaps we should have come >>>> >>>to >>>> >>>sooner) >>>> >>> that we need your help and input. >>>> >>> >>>> >>> The crunch question for us is "What makes it hard to get work >>>> >>>done in the Routing Area?" What gets in the way of your work? >>>> >>>What is making life hard for document authors? How could >>>> >>>working groups be doing better? We are open to all and every >>>> >>>type of answer. We are happy to have quick, one-line answers or >>>> >>>deeply-considered essays. >>>> >>> >>>> >>> What do you think? >>>> >>> >>>> >>> Thanks for all your input, >>>> >>> Adrian and Alia >>>> >>> >>>> >>> PS Please respond to both aliases because not everyone is on >>>> >>>both lists. Sorry that that means some of you will get >>>> >>>duplicates. >>>> >>> >>>> >>> >>>> >> >>>> >> >>>> > >>>> >-- >>>> > >>>> > >>>> >Loa Andersson email:loa@mail01.huawei.com >>>> >Senior MPLS Expertloa@pi.nu >>>> >Huawei Technologies (consultant) phone:+46 739 81 21 64 >>>> >____ >>>> >>>> __ __ >>> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Mar 25 06:38:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5AD1A0133; Tue, 25 Mar 2014 06:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 lH3nwF2F7xWR; Tue, 25 Mar 2014 06:38:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id AC3C71A011B; Tue, 25 Mar 2014 06:38:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: , Date: Tue, 25 Mar 2014 09:38:15 -0400 Message-ID: <00af01cf482f$79cc5210$6d64f630$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B0_01CF480D.F2BED0C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9ILG9DEgAH8hqJRl2NhqJHIcfMVA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/qVjrdniAJmaWU-wxcPHbQZkSw_8 Cc: 'Adrian Farrel' , Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:38:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B0_01CF480D.F2BED0C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Soap box on]=20 What=92s not necessary to consider in this discussion is:=20 =20 1) Maximum number of working groups - 2) Instant cutting of number of working groups 3) Bullying or badgering toward cutting working groups =20 Three issues exist in the routing area: =20 1) Getting new work in =96 from new applications of routing = protocols in Data centers,=20 2) Getting work completed =96=20 a. Getting the last drafts out and then, declaring victory and closing,=20 b. Determining the last drafts are not worth-while, so stopping at = a good point. c. Determine things are at maintenance point and scheduling based = on this point.=20 3) Listening to each other (which prevents 1 & 2 effectively occurring)=20 =20 ------------------- 1) The most important of these facets is the ability to rapidly = adopt and get new work in. This means we must actively go out and listen for = new work. Data Center people have a lot of traffic and a new ideas. = ETSI/NFV have a new needs. It is good news that people attending heavily SFC, Spring, and I2RS. =20 =20 This is where most of our discussion should be focused =96 because this = is what keeps us vibrant as a standard group.=20 =20 2) Getting work completed. =20 =20 Here is the tough part we are really talking about. With SIDR, KARP, = and the rest =96 the real question is have we finished our first grouping? = What does it take to complete it? =20 =20 One middle ground to closing is =93hiatus=94. Yakov put IDR into hiatus = for several sessions. This was a good forcing function for the new uses. Putting your WG into hiatus may signal people that if they do not have drafts ready and active on the mail list =96 you will simply not meet or = get the =BD hour time slot. Hiatus is a step before closing. AD=92s can = handle a lot of groups in Hiatus, if we =93de-emotionalize=94 this state. =20 =20 Some groups are in maintenance or a change. IDR is both in maintenance (fixing those pesty error conditions), and new growth. The difficulty = with MPLS, L2VPN, L3VPN, PWE =96 is we are not sure if it is maintenance (for = large deployments) or new growth. If we have a hiatus state, perhaps we can = talk about the problems as chairs and a directorate. =20 =20 3) Listening to one another - We have OMC (Old Married Couple) syndrome =20 We in the routing group have been at this for almost 30 years. We have = OMC syndrome.=20 We have ceased to listen because we KNOW what the other person will say, = and fight rather than think about new ideas. Are Alia and Adrian like OMC marriage counselors? Yes =96 but is about time we started listening = because the best time for working on routing =96 are ahead of us. =20 =20 The virtualization of the edge and the data center has endless possibilities, and we have the wisdom to figure it out. We are the best people to help the next generation of technology come to full bloom.=20 =20 [Soap box off] =20 =20 Sue Hares=20 =20 ------=_NextPart_000_00B0_01CF480D.F2BED0C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=

[Soap box on]

What’s not necessary to consider in this = discussion is:

 

1)      = Maximum number of working groups = -

2)      = Instant cutting of number of working = groups

3)      = Bullying or badgering toward cutting working = groups

 

Three issues exist in the routing = area:

 

1)      = Getting new work in – from new = applications of routing protocols in Data centers,

2)      = Getting work completed –

a.       = Getting the last drafts out and then,=A0 = declaring victory and closing,

b.      = Determining the last drafts are not worth-while, = so stopping at a good point.

c.       = Determine things are at=A0 maintenance point and = scheduling based on this point.

3)      = Listening to each other =A0(which prevents 1 = & 2 effectively occurring)

 

-------------------

1)      = The most important of these facets is the = ability to rapidly adopt and get new work in. This means we must = actively go out and listen for new work.=A0 Data Center people have a = lot of traffic and a new ideas.=A0 ETSI/NFV have a new needs. =A0It is = good news that people attending heavily SFC, Spring, and I2RS.=A0 =

 

This is where most of our discussion should be = focused – because this is what keeps us vibrant as a standard = group.

 

2)      = Getting work completed.=A0

 

Here is the tough part we are really talking = about.=A0 With SIDR, KARP, and the rest – the real question is = have we finished our first grouping?=A0 What does it take to complete = it? =A0

 

One middle ground to closing is = “hiatus”.=A0 Yakov put IDR into hiatus for several sessions. = This was a good forcing function for the new uses.=A0 Putting your WG = into hiatus may signal people that if they do not have drafts ready and = active on the mail list – you will simply not meet or get the =BD = hour time slot.=A0 Hiatus is a step before closing.=A0 AD’s can = handle a lot of groups in Hiatus, if we “de-emotionalize” = this state.=A0=A0

 

Some groups are in maintenance or a change.=A0 = IDR is both in maintenance (fixing those pesty error conditions), and = new growth.=A0 The difficulty with MPLS, L2VPN, L3VPN, PWE – is we = are not sure if it is maintenance (for large deployments) or new growth. = =A0If we have a hiatus state, perhaps we can talk about the problems as = chairs and a directorate. =A0

 

3)      = Listening to one another =A0- We have OMC (Old = Married Couple) syndrome

 

We in the routing group have been at this for = almost 30 years.=A0 We have OMC syndrome.

We have ceased to listen = because we KNOW what the other person will say, and fight rather than = think about new ideas.=A0 Are Alia and Adrian like OMC marriage = counselors?=A0 Yes – but is about time we started listening = because the best time for working on routing – are ahead of us.=A0 =

 

The virtualization of the edge and the data = center has endless possibilities, and we have the wisdom to figure it = out.=A0 We are the best people to help the next generation of technology = come to full bloom.

 

[Soap box = off] =A0

 

Sue Hares



 =

------=_NextPart_000_00B0_01CF480D.F2BED0C0-- From nobody Tue Mar 25 06:45:39 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA5E1A0145; Tue, 25 Mar 2014 06:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 epbUCUuGi0JP; Tue, 25 Mar 2014 06:45:30 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA11A008F; Tue, 25 Mar 2014 06:45:27 -0700 (PDT) Received: from AM3PR03MB532.eurprd03.prod.outlook.com (10.242.109.156) by AM3PR03MB530.eurprd03.prod.outlook.com (10.242.109.154) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 25 Mar 2014 13:45:25 +0000 Received: from AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) by AM3PR03MB532.eurprd03.prod.outlook.com ([10.242.109.156]) with mapi id 15.00.0898.005; Tue, 25 Mar 2014 13:45:25 +0000 From: Alexander Vainshtein To: Acee Lindem Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: AQEUSZYWTwCBpcwfYKSo2uUSqm2+UQGRqzQOAfOTaXOcSCfvIIAAYMEAgAJ95YCAAFnqAIAAQBkg Date: Tue, 25 Mar 2014 13:45:24 +0000 Message-ID: <76e54cfca64a4709aacdd90d7af1f993@AM3PR03MB532.eurprd03.prod.outlook.com> References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> In-Reply-To: <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-forefront-prvs: 01613DFDC8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(164054003)(51704005)(24454002)(377424004)(199002)(189002)(377454003)(479174003)(252514010)(13464003)(83072002)(85852003)(56816005)(87936001)(90146001)(2656002)(69226001)(76482001)(95666003)(46102001)(54356001)(4396001)(51856001)(86362001)(53806001)(15975445006)(56776001)(81686001)(97186001)(54316002)(92566001)(98676001)(19580395003)(80976001)(19609705001)(87266001)(93516002)(93136001)(19580405001)(83322001)(81816001)(85306002)(76786001)(74316001)(76796001)(76576001)(97336001)(74706001)(19300405004)(77982001)(59766001)(33646001)(79102001)(31966008)(74662001)(81542001)(74876001)(47446002)(16236675002)(94316002)(74502001)(81342001)(95416001)(65816001)(47736001)(63696002)(20776003)(50986001)(66066001)(47976001)(49866001)(80022001)(15202345003)(74366001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB530; H:AM3PR03MB532.eurprd03.prod.outlook.com; FPR:A41DC095.AFF29351.F2DFFDBB.92C8FB8D.20753; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: ecitele.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_76e54cfca64a4709aacdd90d7af1f993AM3PR03MB532eurprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/A0D3Cp_n44hwZQwlAwWGnFDZNDs Cc: "rtg-dir@ietf.org" , Ines Robles , Jeff Tantsura , Alia Atlas , "rtg-chairs@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 13:45:37 -0000 --_000_76e54cfca64a4709aacdd90d7af1f993AM3PR03MB532eurprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Acee, and all, This is a very good presentation indeed. I just wonder whether statistics from some other WGs is not needed for this= - the current presentation actually calls for that in Slide 4... And, IMHO and FWIW, the most important point is raised on Slide 14. Once up= on a time existing implementation (=3D running code) has been a mandatory r= equirement for the Standards Track documents in the Routing Area. This requ= irement has been relaxed - but my gut feeling is that restoration of this r= ule would really help in getting the job done better and faster. My 2c, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Acee Lindem Sent: Tuesday, March 25, 2014 11:44 AM To: Jeff Tantsura Cc: Adrian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg-dir@ie= tf.org Subject: Re: [RTG-DIR] Routing Area Health Check On Mar 25, 2014, at 12:22 AM, Jeff Tantsura > wrote: Perhaps would be worthwhile to present Adrian's presentation "What makes fo= r a quality RFC" for every wg. How about simply replaying it once in the Routing Area Open Meeting? Acee Cheers, Jeff From: Ines Robles > Date: Sunday, March 23, 2014 7:19 AM To: Adrian Farrel > Cc: "rtg-dir@ietf.org" >, "rtg-chairs@ietf.org" >, Alia Atlas > Subject: Re: [RTG-DIR] Routing Area Health Check Resent-To: >, >, >, >, >, >, >, >, >, >, >, "hannes@juniper.net" >, Joel Halpern >, >, >, >, Thomas Morin >, Martin Vigoureux >, >, >, <= swallow@cisco.com>, Loa Andersson >, >, >, >, >, Acee Lindem Lindem III >, >, >, >, >, >, >, >, >, Alvaro Retana >, Jeff T= antsura >, >, >, >, >, Alvaro Retana= >, >, Alia Atlas >, <= adrian@olddog.co.uk> Hi, About this: "What is making life hard for document authors?" Maybe, one problem is that the authors don't know all the steps, that a doc= ument goes through during the process of publication, of course it is respo= nsibility of the authors read the required information to learn about it; T= his is the minimum thing, that an author must do, if he/she wants to publis= h a document in the IETF. But, I think, sometimes the authors believe that, the work is done when a d= ocument is submitted to the IESG, then for example they forget to address t= he Gen-art review, AUTH48, and additionals reviews. Thinking that maybe, a fast checklist is going to help them to know what th= ey should address to get a document published :-) Thanks and Regards Ines 2014-03-23 5:36 GMT-03:00 Adrian Farrel >: Yeah, I like that all sorts of ideas are being thrown into the pot. We shou= ld be a sufficiently adult subset of the crazies to be able to handle that. However, we are talking like engineers :-) Might be nice to focus back on the questions of what is a problem for getti= ng work done. We can come back to how to fix it. Now, all of you complaining that the problem needs to be defined... ...please define the problem :-) Adrian From: Alia Atlas [mailto:akatlas@gmail.com] Sent: 22 March 2014 22:48 To: Acee Lindem Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check Acee, None of those different directions seems to me to be bad. The question was deliberately ask unframed and undefined. Adrian and I will define and frame it more - but first we wanted to hear the unframed but thoughtful discussion. Providing reasoning does help everyone determine if they are on the same page. Regards, Alia On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem > wrote: I agree with Loa that the problem needs to be defined - this discussion has already diverged into 4 different directions. Thanks, Acee On 3/22/14 3:15 AM, "Loa Andersson" > wrote: >John, > >How about deciding what is broken first, and then looking at the >actions?? > >/Loa > >On 2014-03-21 21:44, John E Drake wrote: >> Adrian, >> >> Combine IS-IS and OSPF >> >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work there >> >> There is probably some synergy between PCE, SFC, and SPRING that needs >>to be exploited >> >> Combine BFD and the OAM/protection switching part of MPLS >> >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 >> >> Yours Irrespectively, >> >> John >> >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian >>>Farrel >>> Sent: Friday, March 21, 2014 11:31 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Cc: Alia Atlas >>> Subject: [RTG-DIR] Routing Area Health Check >>> >>> Hello Directorate and WG chairs, >>> >>> Alia and I have been discussing the Routing Area, its work, its >>>output, and its >>> working groups. >>> >>> We have reached a conclusion (which perhaps we should have come to >>>sooner) >>> that we need your help and input. >>> >>> The crunch question for us is "What makes it hard to get work done in >>>the >>> Routing Area?" What gets in the way of your work? What is making life >>>hard >>> for document authors? How could working groups be doing better? We are >>> open to all and every type of answer. We are happy to have quick, >>>one-line >>> answers or deeply-considered essays. >>> >>> What do you think? >>> >>> Thanks for all your input, >>> Adrian and Alia >>> >>> PS Please respond to both aliases because not everyone is on both >>>lists. Sorry >>> that that means some of you will get duplicates. >>> >>> >> >> > >-- > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 > --_000_76e54cfca64a4709aacdd90d7af1f993AM3PR03MB532eurprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Acee, and all,=

This is a very good prese= ntation indeed.

 <= /p>

I just wonder whether sta= tistics from some other WGs is not needed for this – the current pres= entation actually calls for that in Slide 4…

 <= /p>

And, IMHO and FWIW, the m= ost important point is raised on Slide 14. Once upon a time existing implem= entation (=3D running code) has been a mandatory requirement for the Standards Tra= ck documents in the Routing Area. This requirement has been relaxed –= but my gut feeling is that restoration of this rule would really help in g= etting the job done better  and faster.

 <= /p>

My 2c,<= /p>

    &= nbsp;  Sasha

Email: Alexander.Vainshte= in@ecitele.com

Mobile: 054-9266302<= /o:p>

 <= /p>

From: rtg-dir = [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: Tuesday, March 25, 2014 11:44 AM
To: Jeff Tantsura
Cc: Adrian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; rtg= -dir@ietf.org
Subject: Re: [RTG-DIR] Routing Area Health Check

 

 

On Mar 25, 2014, at 12:22 AM, Jeff Tantsura <jeff.tantsura@ericsson.com>= ; wrote:



Perhaps would be worthwhile to present = Adrian's presentation "What makes for a quality RFC" for every wg= .

 

How about simply replaying it once in the Routing Ar= ea Open Meeting? 

 

Acee 



 

 

Cheers,

Jeff

 

From: Ines Robles <mariainesrobles@googlemail.com>
Date: Sunday, March 23, 2014 7:19 AM
To: Adrian Farrel <adrian@= olddog.co.uk>
Cc: "rtg-dir@ietf.org&q= uot; <rtg-dir@ietf.org>, &quo= t;rtg-chairs@ietf.org" <= rtg-chairs@ietf.org>, Alia Atlas <akatlas@juniper.net&g= t;
Subject: Re: [RTG-DIR] Routing Area Health Check
Resent-To: <jhaas@pfrc.org&= gt;, <nobo@cisco.com>, <dbrungard@att.com>, <lberger@labn.net>, <hadi@mojatatu.com>, <damascene.joach= impillai@verizon.com>, <jhaas@p= frc.org>, <edc@google.com&g= t;, <shares@ndzh.com>, <jgs@juniper.net>, <chopps@rawdofmt.org>, "hannes@juniper.net" <hannes@juniper.net>, Joel Halpern <jmh@joelhalpern.com>, &l= t;bew@cisco.com>, <nabil.n.bitar@verizon.com>, <giheron@cisco.com>, Thomas Morin <thomas.morin@orange.c= om>, Martin Vigoureux <martin.vigoureux@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, <sratliff@cisco.com>, <= swallow@cisco.com>, Loa Anderss= on <loa@pi.nu>, <rcallon@juniper.net>, <bensons@queuefull.net>, <matthew.bocci@alca= tel-lucent.com>, <akr@cisco.com<= /a>>, Acee Lindem Lindem III <acee.lindem@ericsson.com>, <jpv@cisco.com>, <julien.meuric@orange.com>, <mmcbride7@gmail.com&= gt;, <stig@venaas.com>, <matthew.bocci@alcatel-luc= ent.com>, <agmalis@gmail.com>, <mcr+ietf@sandelman.ca>= ;, <mariainesrobles@gmail.c= om>, Alvaro Retana <aretana@= cisco.com>, Jeff Tantsura <jeff.tants= ura@ericsson.com>, <narten@u= s.ibm.com>, <jguichar@cisco= .com>, <Sandra.Murphy= @sparta.com>, <morrowc@ops-netman.net&g= t;, Alvaro Retana <aretana@cisco.co= m>, <jgs@juniper.net>, = Alia Atlas <akatlas@gmail.com&g= t;, <adrian@olddog.co.uk>

 

Hi,=



About this: “What= is making life hard for document authors?”<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-s= erif"">



Maybe, one problem is that the authors do= n’t know all the steps, that a document goes through during the proce= ss of publication, of course it is responsibility of the authors read the required information to learn about it; This is the minimum thing= , that an author must do, if he/she wants to publish a document in the IETF= .



But, I think, sometimes the authors belie= ve that, the work is done when a document is submitted to the IESG, then fo= r example they forget to address the Gen-art review, AUTH48, and additionals reviews.



Thinking that maybe, a fast checklist is = going to help them to know what they should address to get a document publi= shed :-)



Thanks and Regards


Ines

&nb= sp;

2014-03-23 5:36 GMT-03:00 Adrian Farrel= <adrian@olddog= .co.uk>:

Yeah, I li= ke that all sorts of ideas are being thrown into the pot. We should be a su= fficiently adult subset of the crazies to be able to handle that.

 

However, w= e are talking like engineers :-)

Might be n= ice to focus back on the questions of what is a problem for getting work do= ne. We can come back to how to fix it.

 

Now, all o= f you complaining that the problem needs to be defined...

...please = define the problem :-)=

 

Adrian

 

From: Alia Atl= as [mailto:akatlas@g= mail.com]
Sent: 22 March 2014 22:48
To: Acee Lindem
Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.or= g; Alia Atlas
Subject: Re: [RTG-DIR] Routing Area Health Check

 =

Acee,<= /p>

 =

None of those different = directions seems to me to be bad.

The question was deliber= ately ask unframed and undefined.

Adrian and I will define= and frame it more - but first we wanted 

to hear the unframed but= thoughtful discussion.

 =

Providing reasoning does= help everyone determine if they are

on the same page.

 =

Regards,

Alia

 

On Sat, Mar 22, 2014 at = 6:18 PM, Acee Lindem <acee.lindem@ericsson.com> wrote:

I agree with Loa that th= e problem needs to be defined - this discussion
has already diverged into 4 different directions.

Thanks,
Acee


On 3/22/14 3:15 AM, "Loa Andersson" <loa@pi.nu> wrote:

>John,
>
>How about deciding what is broken first, and then looking at the
>actions??
>
>/Loa
>
>On 2014-03-21 21:44, John E Drake wrote:
>> Adrian,
>>
>> Combine IS-IS and OSPF
>>
>> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work the= re
>>
>> There is probably some synergy between PCE, SFC, and SPRING that n= eeds
>>to be exploited
>>
>> Combine BFD and the OAM/protection switching part of MPLS
>>
>> Close Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours Irrespectively,
>>
>> John
>>
>>> -----Original Message-----
>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, March 21, 2014 11:31 AM
>>> To: rtg-= dir@ietf.org; rtg-chairs@ietf.org
>>> Cc: Alia Atlas
>>> Subject: [RTG-DIR] Routing Area Health Check
>>>
>>> Hello Directorate and WG chairs,
>>>
>>> Alia and I have been discussing the Routing Area, its work, it= s
>>>output, and its
>>> working groups.
>>>
>>> We have reached a conclusion (which perhaps we should have com= e to
>>>sooner)
>>> that we need your help and input.
>>>
>>> The crunch question for us is "What makes it hard to get = work done in
>>>the
>>> Routing Area?" What gets in the way of your work? What is= making life
>>>hard
>>> for document authors? How could working groups be doing better= ? We are
>>> open to all and every type of answer. We are happy to have qui= ck,
>>>one-line
>>> answers or deeply-considered essays.
>>>
>>> What do you think?
>>>
>>> Thanks for all your input,
>>> Adrian and Alia
>>>
>>> PS Please respond to both aliases because not everyone is on b= oth
>>>lists. Sorry
>>> that that means some of you will get duplicates.
>>>
>>>
>>
>>
>
>--
>
>
>Loa Andersson                 &= nbsp;      email: loa@mail01.huawei.com
>Senior MPLS Expert               &nb= sp;          loa@pi.nu
>Huawei Technologies (consultant)     phone: +46 739 81 21 64
>

 =

 

 

--_000_76e54cfca64a4709aacdd90d7af1f993AM3PR03MB532eurprd03pro_-- From nobody Tue Mar 25 07:38:48 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95841A0150; Tue, 25 Mar 2014 07:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-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 G3ARwjGvn0al; Tue, 25 Mar 2014 07:38:44 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0353C1A0133; Tue, 25 Mar 2014 07:38:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 38E911C82935; Tue, 25 Mar 2014 07:38:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D5A9F1C82930; Tue, 25 Mar 2014 07:38:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Date: Tue, 25 Mar 2014 15:38:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/RqN4cAr3XIPteH3fuRzPQW6yd0I Cc: "" , Alia Atlas , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:38:46 -0000 Hello ADs, Directorate, Chairs, Interesting questions, thanks for caring and asking.=20 I am probably going to cut my answer into separate independent mails, as = there are vastly different topics in this question. First, as a member of the RTG Directorate, I actually feel a little = "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As = has been discussed widely lately, ADs are overworked and have too little = time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as = rather hard. I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to = mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the = tracker during IESG Evaluation. It doesn't matter what document or WG it = was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the = DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some = routing background), and -- most importantly -- (iv) getting a 10-page = DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the = document authors...its late, design decisions have been made, which are = being questioned, etc....it tires people out, pisses off authors, and = frustrates everybody involved. So, I've been playing around with a couple of ideas on the sideline, = unofficially, and with only unwitting assistance from others = involved.... Thought #1: I-Ds - when called for adoption as WG documents, or when published as = draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good = to take (or avoid) here". That same reviewer can, occasionally, be = invoked by the WG chairs or authors, in the "so, did we catch this = right?" -- and, of course, should be called in on the WGLC of the = document. I think of it a little as the "area advisors" but to a = document rather than a WG as a whole.=20 I've been playing around with that a bit, as an author:=20 o Since I know very little about security, I've looped in = somebody who did, when=20 having published a -00, and again the same person as = needed later in the process. I've gotten hugely valuable feedback - making the = ultimate SEC-DIR and SEC-AD=20 reviews a lot less painful for me (and, given how = little I knew about security, presumably=20 less frustrating/time-consuming for the ADs, too, than = if I had been just shooting blind). o Since I know even less about OPS stuff, Adrian looped an = OPS guy in on an individual -01, who asked a lot of good questions to = what we were doing, and why, and which is hugely helpful. As an author in the RTG Area, the SEC and OPS ADs are often real = "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the = whole context over once again since, even if they've already gotten the = story once, they have to follow sufficiently many documents and topics = that something is bound to be flushed from their cache. Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the = document (and, presumably, follows much fewer documents concurrently) = through the process with the authors would be great, as an author. And = possibly makes the ADs encounter less poor documents. I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) = be just as much of a roadblock as the SEC/OPS folks, and I have no = reason to not expect Alia to have the same high (or higher) = standards....so I imagine that a way the RTG-DIR could help "improve the = image of the ADs" and at the same time get the ADs time liberated from = writing 10-page discusses, would be something like the above.... In short, what I envision is a structured way of getting: o very early-reviews o a semi-permanent attachment of a reviewer from the = directorateS to a document o this, through the documents lifecycle. Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid = pitfalls. A final note: having been around for a while in the IETF, it is really = easy to ask around for help from among other IETFers that one knows -- = then again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it. This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved. Thought #2: So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review = cycle during IETF LC, or perhaps during "Publication Requested" and = before "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews = from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). = Authors and reviewer iterate until either (i) issues are squared off or = (ii) either authors or reviewer declare the other as "bat-crap-crazy" = (or, complains that the other side is not responsive) and raise the = issue to the AD. AD moves the document forward to "AD Evaluation" only = once happy with the outcome of directorate reviews. In short, hiving out = a lot more of the "problem fixing" that happens during these reviews off = to the directorates - and leaving ADs to process presumably "less = broken" documents. As an author, I have actually found it a LOT easier/faster to iterate = with a directorate reviewer (who has my document fresh in mind), than = with an AD who's preoccupied with a dozen or so documents at the same = time, and other emergencies. Now, mind you, some ADs are good at saying = "Busy, will come back to you in n days" -- others, alas, do "play dead" = if they feel they have more important fish to fry, and that's = frustrating. This might lessen the load on the ADs, but still has the disadvantage = that one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing. Thought #3: I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are = plenty able to do the necessary during WG processing, and as an author = in the RTG Area, I do usually know how to grab someone competent from = the same area for advice, as needed. While doing something like this = intra-area can be a good thing, the real boast that I, as document = author, have felt has been through getting cross-area feedback. Just as = (being forced to be) reviewing document outside of the RTG area has been = hugely educational and. Cheers, Thomas On 21 Mar 2014, at 19:31, Adrian Farrel wrote: > Hello Directorate and WG chairs, >=20 > Alia and I have been discussing the Routing Area, its work, its = output, and its > working groups. >=20 > We have reached a conclusion (which perhaps we should have come to = sooner) that > we need your help and input. >=20 > The crunch question for us is "What makes it hard to get work done in = the > Routing Area?" What gets in the way of your work? What is making life = hard for > document authors? How could working groups be doing better? We are = open to all > and every type of answer. We are happy to have quick, one-line answers = or > deeply-considered essays. >=20 > What do you think?=20 >=20 > Thanks for all your input, > Adrian and Alia >=20 > PS Please respond to both aliases because not everyone is on both = lists. Sorry > that that means some of you will get duplicates. >=20 From nobody Tue Mar 25 07:57:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349771A0165; Tue, 25 Mar 2014 07:57:17 -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 UMcpLuGrt7t5; Tue, 25 Mar 2014 07:57:13 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id CADC61A0160; Tue, 25 Mar 2014 07:57:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0A41C1C82B99; Tue, 25 Mar 2014 07:57:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7FCC01C82B96; Tue, 25 Mar 2014 07:57:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_25B4AD30-E1C8-473C-9E50-6D51182A8ED2" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <76e54cfca64a4709aacdd90d7af1f993@AM3PR03MB532.eurprd03.prod.outlook.com> Date: Tue, 25 Mar 2014 15:57:05 +0100 Message-Id: <10E73E4E-4084-43B3-8626-434522C7791B@thomasclausen.org> References: <532D62BE.3040102@pi.nu> <0b5501cf4673$0f56e4d0$2e04ae70$@olddog.co.uk> <26ACAF16-1CA4-45B3-9030-B51736FE8902@ericsson.com> <76e54cfca64a4709aacdd90d7af1f993@AM3PR03MB532.eurprd03.prod.outlook.com> To: Alexander Vainshtein X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/GSipv6hZiaFf3NmKPzbq-YtlV6s Cc: "rtg-dir@ietf.org" , Ines Robles , Jeff Tantsura , Acee Lindem , Alia Atlas , "rtg-chairs@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:57:17 -0000 --Apple-Mail=_25B4AD30-E1C8-473C-9E50-6D51182A8ED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 Mar 2014, at 14:45, Alexander Vainshtein = wrote: > Acee, and all, > This is a very good presentation indeed. > =20 > I just wonder whether statistics from some other WGs is not needed for = this =96 the current presentation actually calls for that in Slide 4=85 > =20 > And, IMHO and FWIW, the most important point is raised on Slide 14. = Once upon a time existing implementation (=3D running code) has been a = mandatory requirement for the Standards Track documents in the Routing = Area. This requirement has been relaxed =96 but my gut feeling is that = restoration of this rule would really help in getting the job done = better and faster. "Rough consensus and Running code" - very much so. I understand why the = requirement has been relaxed, and why it being a "rule" might be too = rigid. But I do believe that several blunders over the past years could have = been averted, had there been *running* code before standards. Thomas > =20 > My 2c, > Sasha > Email: Alexander.Vainshtein@ecitele.com > Mobile: 054-9266302 > =20 > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Acee = Lindem > Sent: Tuesday, March 25, 2014 11:44 AM > To: Jeff Tantsura > Cc: Adrian Farrel; Ines Robles; Alia Atlas; rtg-chairs@ietf.org; = rtg-dir@ietf.org > Subject: Re: [RTG-DIR] Routing Area Health Check > =20 > =20 > On Mar 25, 2014, at 12:22 AM, Jeff Tantsura = wrote: >=20 >=20 > Perhaps would be worthwhile to present Adrian's presentation "What = makes for a quality RFC" for every wg. > =20 > How about simply replaying it once in the Routing Area Open Meeting?=20= > =20 > Acee=20 >=20 >=20 > =20 > =20 > Cheers, > Jeff > =20 > From: Ines Robles > Date: Sunday, March 23, 2014 7:19 AM > To: Adrian Farrel > Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" = , Alia Atlas > Subject: Re: [RTG-DIR] Routing Area Health Check > Resent-To: , , , = , , = , , = , , , = , "hannes@juniper.net" , Joel = Halpern , , = , , Thomas Morin = , Martin Vigoureux = , , = , , Loa Andersson , = , , = , , Acee Lindem Lindem = III , , = , , , = , , = , , Alvaro Retana = , Jeff Tantsura , = , , , = , Alvaro Retana , = , Alia Atlas , > =20 > Hi, >=20 >=20 > About this: =93What is making life hard for document authors?=94 >=20 >=20 > Maybe, one problem is that the authors don=92t know all the steps, = that a document goes through during the process of publication, of = course it is responsibility of the authors read the required information = to learn about it; This is the minimum thing, that an author must do, if = he/she wants to publish a document in the IETF. >=20 >=20 > But, I think, sometimes the authors believe that, the work is done = when a document is submitted to the IESG, then for example they forget = to address the Gen-art review, AUTH48, and additionals reviews. >=20 >=20 > Thinking that maybe, a fast checklist is going to help them to know = what they should address to get a document published :-) >=20 >=20 > Thanks and Regards >=20 > Ines > =20 >=20 > 2014-03-23 5:36 GMT-03:00 Adrian Farrel : >=20 > Yeah, I like that all sorts of ideas are being thrown into the pot. We = should be a sufficiently adult subset of the crazies to be able to = handle that. > =20 > However, we are talking like engineers :-) > Might be nice to focus back on the questions of what is a problem for = getting work done. We can come back to how to fix it. > =20 > Now, all of you complaining that the problem needs to be defined... > ...please define the problem :-) > =20 > Adrian > =20 > From: Alia Atlas [mailto:akatlas@gmail.com]=20 > Sent: 22 March 2014 22:48 > To: Acee Lindem > Cc: Loa Andersson; John E Drake; adrian@olddog.co.uk; = rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia Atlas > Subject: Re: [RTG-DIR] Routing Area Health Check > =20 > Acee, > =20 > None of those different directions seems to me to be bad. > The question was deliberately ask unframed and undefined. > Adrian and I will define and frame it more - but first we wanted=20 > to hear the unframed but thoughtful discussion. > =20 > Providing reasoning does help everyone determine if they are > on the same page. > =20 > Regards, > Alia > =20 >=20 > On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem = wrote: > I agree with Loa that the problem needs to be defined - this = discussion > has already diverged into 4 different directions. >=20 > Thanks, > Acee >=20 > On 3/22/14 3:15 AM, "Loa Andersson" wrote: >=20 > >John, > > > >How about deciding what is broken first, and then looking at the > >actions?? > > > >/Loa > > > >On 2014-03-21 21:44, John E Drake wrote: > >> Adrian, > >> > >> Combine IS-IS and OSPF > >> > >> Combine L2 and L3 VPNs and move the CCAMP inter-domain TE work = there > >> > >> There is probably some synergy between PCE, SFC, and SPRING that = needs > >>to be exploited > >> > >> Combine BFD and the OAM/protection switching part of MPLS > >> > >> Close Secure IDR, FORCES, KARP, MANET, and NVO3 > >> > >> Yours Irrespectively, > >> > >> John > >> > >>> -----Original Message----- > >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of = Adrian > >>>Farrel > >>> Sent: Friday, March 21, 2014 11:31 AM > >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org > >>> Cc: Alia Atlas > >>> Subject: [RTG-DIR] Routing Area Health Check > >>> > >>> Hello Directorate and WG chairs, > >>> > >>> Alia and I have been discussing the Routing Area, its work, its > >>>output, and its > >>> working groups. > >>> > >>> We have reached a conclusion (which perhaps we should have come to > >>>sooner) > >>> that we need your help and input. > >>> > >>> The crunch question for us is "What makes it hard to get work done = in > >>>the > >>> Routing Area?" What gets in the way of your work? What is making = life > >>>hard > >>> for document authors? How could working groups be doing better? We = are > >>> open to all and every type of answer. We are happy to have quick, > >>>one-line > >>> answers or deeply-considered essays. > >>> > >>> What do you think? > >>> > >>> Thanks for all your input, > >>> Adrian and Alia > >>> > >>> PS Please respond to both aliases because not everyone is on both > >>>lists. Sorry > >>> that that means some of you will get duplicates. > >>> > >>> > >> > >> > > > >-- > > > > > >Loa Andersson email: loa@mail01.huawei.com > >Senior MPLS Expert loa@pi.nu > >Huawei Technologies (consultant) phone: +46 739 81 21 64 > > >=20 --Apple-Mail=_25B4AD30-E1C8-473C-9E50-6D51182A8ED2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 25 Mar 2014, at 14:45, Alexander = Vainshtein <Alexander.Vainshtein@ecit= ele.com> wrote:

Acee, and all,
This is a very good = presentation indeed.
 
I just wonder whether = statistics from some other WGs is not needed for this =96 the current = presentation actually calls for that in Slide = 4=85
 
And, IMHO and FWIW, the most important point is = raised on Slide 14. Once upon a time existing implementation (=3D running code) has = been a mandatory requirement for the Standards Track documents in the = Routing Area. This requirement has been relaxed =96 but my gut feeling = is that restoration of this rule would really help in getting the job = done better  and faster.

"Rough = consensus and Running code" - very much so. I understand why the = requirement has been relaxed, and why it being a "rule" might be too = rigid.

But I do believe that several blunders = over the past years could have been averted, had there been *running* = code before = standards.

Thomas

 
My 2c,
       = Sasha
Mobile: = 054-9266302
 
 
 
On = Mar 25, 2014, at 12:22 AM, Jeff Tantsura <jeff.tantsura@ericsson.com> = wrote:


Perhaps = would be worthwhile to present Adrian's presentation "What makes for a = quality RFC" for every wg.
 
How about simply replaying it once in the Routing = Area Open Meeting? 
 
Acee 


 
 
Cheers,
Jeff
 
From: Ines Robles = <mariainesrobles@googlemail.com>
Date: Sunday, March 23, 2014 = 7:19 AM
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtg-chairs@ietf.org" <rtg-chairs@ietf.org>, Alia Atlas = <akatlas@juniper.net>
Subject: Re: [RTG-DIR] Routing = Area Health Check
Resent-To: <jhaas@pfrc.org>, <nobo@cisco.com>, <dbrungard@att.com>, <lberger@labn.net>, <hadi@mojatatu.com>, <damascene.joachimpillai@verizon.com>, <jhaas@pfrc.org>, <edc@google.com>, <shares@ndzh.com>, <jgs@juniper.net>, <chopps@rawdofmt.org>, "hannes@juniper.net" <hannes@juniper.net>, Joel Halpern = <jmh@joelhalpern.com>, <bew@cisco.com>, <nabil.n.bitar@verizon.com>, <giheron@cisco.com>, Thomas Morin = <thomas.morin@orange.com>, Martin = Vigoureux <martin.vigoureux@alcatel-lucent.com>, <macker@itd.nrl.navy.mil>, <sratliff@cisco.com>, <swallow@cisco.com>, Loa Andersson = <loa@pi.nu>, <rcallon@juniper.net>, <bensons@queuefull.net>, <matthew.bocci@alcatel-lucent.com>, = <akr@cisco.com>, Acee Lindem Lindem = III <acee.lindem@ericsson.com>, = <jpv@cisco.com>, <julien.meuric@orange.com>, <mmcbride7@gmail.com>, <stig@venaas.com>, <matthew.bocci@alcatel-lucent.com>, = <agmalis@gmail.com>, <mcr+ietf@sandelman.ca>, <mariainesrobles@gmail.com>, Alvaro = Retana <aretana@cisco.com>, Jeff Tantsura = <jeff.tantsura@ericsson.com>, = <narten@us.ibm.com>, <jguichar@cisco.com>, <Sandra.Murphy@sparta.com>, <morrowc@ops-netman.net>, Alvaro = Retana <aretana@cisco.com>, <jgs@juniper.net>, Alia Atlas <akatlas@gmail.com>, <adrian@olddog.co.uk>
=
 
Hi,


About this: =93What is making life hard for document = authors?=94


Maybe, one problem is that the authors don=92t know all the = steps, that a document goes through during the process of publication, = of course it is responsibility of the authors read the required = information to learn about it; This is the minimum thing, that an author = must do, if he/she wants to publish a document in the IETF.


But, I think, sometimes the authors believe that, the work = is done when a document is submitted to the IESG, then for example they = forget to address the Gen-art review, AUTH48, and = additionals reviews.


Thinking that maybe, a fast checklist is going to = help them to know what they should address to get a document published = :-)


Thanks and Regards

Ines

 

2014-03-23 5:36 GMT-03:00 Adrian Farrel <adrian@olddog.co.uk>:

Yeah, I like that all sorts of ideas are being thrown = into the pot. We should be a sufficiently adult subset of the crazies to = be able to handle that.
 
However, we are talking = like engineers :-)
Might be nice to focus = back on the questions of what is a problem for getting work done. We can = come back to how to fix it.
 
Now, all of you = complaining that the problem needs to be defined...
...please define the = problem :-)
 
Adrian
 
From: Alia Atlas [mailto:akatlas@gmail.com] 
Sent: 22 March 2014 = 22:48
To: Acee= Lindem
Cc: Loa Andersson; John E = Drake; adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org; Alia = Atlas
Subject: Re: [RTG-DIR] Routing Area = Health Check
 
Acee,
 
None of those different directions = seems to me to be bad.
The question was deliberately ask = unframed and undefined.
Adrian and I will define and frame it = more - but first we wanted 
to hear the unframed but thoughtful = discussion.
 
Providing reasoning does help = everyone determine if they are
on the same = page.
 
Regards,
Alia

 

On Sat, Mar 22, 2014 at 6:18 PM, Acee Lindem = <acee.lindem@ericsson.com> = wrote:
I agree with Loa that the problem needs to be defined - = this discussion
has already diverged into 4 different = directions.

Thanks,
Acee


On = 3/22/14 3:15 AM, "Loa Andersson" <loa@pi.nu> wrote:

>John,
>
>How = about deciding what is broken first, and then looking at = the
>actions??
>
>/Loa
>
>On 2014-03-21 = 21:44, John E Drake wrote:
>> Adrian,
>>
>> = Combine IS-IS and OSPF
>>
>> Combine L2 and L3 VPNs = and move the CCAMP inter-domain TE work there
>>
>> = There is probably some synergy between PCE, SFC, and SPRING that = needs
>>to be exploited
>>
>> Combine BFD and = the OAM/protection switching part of MPLS
>>
>> Close = Secure IDR, FORCES, KARP, MANET, and NVO3
>>
>> Yours = Irrespectively,
>>
>> John
>>
>>> = -----Original Message-----
>>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On = Behalf Of Adrian
>>>Farrel
>>> Sent: Friday, = March 21, 2014 11:31 AM
>>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org
>>> Cc: Alia = Atlas
>>> Subject: [RTG-DIR] Routing Area Health = Check
>>>
>>> Hello Directorate and WG = chairs,
>>>
>>> Alia and I have been discussing = the Routing Area, its work, its
>>>output, and = its
>>> working groups.
>>>
>>> We = have reached a conclusion (which perhaps we should have come = to
>>>sooner)
>>> that we need your help and = input.
>>>
>>> The crunch question for us is = "What makes it hard to get work done = in
>>>the
>>> Routing Area?" What gets in the = way of your work? What is making = life
>>>hard
>>> for document authors? How could = working groups be doing better? We are
>>> open to all and = every type of answer. We are happy to have = quick,
>>>one-line
>>> answers or = deeply-considered essays.
>>>
>>> What do you = think?
>>>
>>> Thanks for all your = input,
>>> Adrian and Alia
>>>
>>> = PS Please respond to both aliases because not everyone is on = both
>>>lists. Sorry
>>> that that means some of = you will get = duplicates.
>>>
>>>
>>
>>
>= ;
>--
>
>
>Loa Andersson       =                 =  email: loa@mail01.huawei.com
>Senior MPLS Expert   =                     =    loa@pi.nu
>Huawei Technologies (consultant)   =   phone: +46 739 81 21 = 64
>

<= /blockquote>

= --Apple-Mail=_25B4AD30-E1C8-473C-9E50-6D51182A8ED2-- From nobody Tue Mar 25 07:58:42 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA181A0168; Tue, 25 Mar 2014 07:58:39 -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 Chqdlms5NGM6; Tue, 25 Mar 2014 07:58:36 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 36FEE1A0160; Tue, 25 Mar 2014 07:58:36 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id b6so569803yha.16 for ; Tue, 25 Mar 2014 07:58:35 -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=9FL+B4j98ftRvG7e0s/Tlwnl6LRlD1fZkYJe0prl6b4=; b=aY/1uQOMucx+qPooC18QsT88uN/FVuxUUiXLMzsg6rLUqQdJfG7Ss3sz0Vua2Gsygx eBsQYMHDifcGvwWowR8bmjmT75gstNdYU2c1+Nsc0eeWZIu3dcsYEKeMAFX/0ceKgZrg vAikEbc8ppKUQLqtILkiCNYIl12E+5Up8ScgdrLYx1TF7ljnJw9uUsmejKlMZipiSaV1 LA320T8g18TV06sCZwlRiAW03Dv+2BgnVXENpGDaLEwBF9xXerborlRUGhlob9Go+1u/ F6LV/npcSeV4Bumsp/aNaky4vC1jvU9xABxC2JoLzU9XPsJM3Uv5F/M3aPqU8GR7p/x9 2bfA== MIME-Version: 1.0 X-Received: by 10.236.138.73 with SMTP id z49mr1654684yhi.152.1395759515024; Tue, 25 Mar 2014 07:58:35 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Tue, 25 Mar 2014 07:58:34 -0700 (PDT) In-Reply-To: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Date: Tue, 25 Mar 2014 10:58:34 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=20cf303ea63415df6904f56f9679 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/KU_SRtsz-Es4cU83wIr4ysj0jsQ Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 14:58:40 -0000 --20cf303ea63415df6904f56f9679 Content-Type: text/plain; charset=ISO-8859-1 Thomas, Thanks very much for your thoughts. On the being underutilized and on cross-area review, what do you and others in the Routing Directorate think about being asked to follow a single additional working group that is not in RTG and may have routing related issues? For the time speedup of ADs, I'm told that it'd be really really useful to have more active document shepherds - who can facilitate getting comments and having them addressed. I'm not sure how to put that into place really. As a WG chair, I felt like I was processing and pushing few enough drafts that I could do the shepherd job also - but I know that there are some WGs where there is higher throughput. It's also a good way of growing a person, to let them see the whole process and deal with the discussions. For the drafts, I'd love to see earlier reviews. I'm not sure if at WG adoption is quite the right time, but it is a good approximation of "early in the process". We could ask WG chairs to request a reviewer at that point for drafts that may need it and see what the load looks like. For a start-up, having interested WG chairs identify WG drafts that could benefit from review would be helpful/interesting in terms of seeing the workload. Regards, Alia On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen wrote: > Hello ADs, Directorate, Chairs, > > Interesting questions, thanks for caring and asking. > > I am probably going to cut my answer into separate independent mails, as > there are vastly different topics in this question. > > First, as a member of the RTG Directorate, I actually feel a little > "under-utilized". An occasional review of an I-D at an extremely late state > of its process, and a very rare more global question like this. As has been > discussed widely lately, ADs are overworked and have too little time, so > perhaps they do not call on the directorate enough - and, also, delegation > of tasks that the ADs have to do is probably perceived as rather hard. > > I've been dumbfounded by some of the reviews I have seen from ADs, either > during AD Evaluation or IESG Reviews: one particular case came to mind > where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker > during IESG Evaluation. It doesn't matter what document or WG it was, what > matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of > Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs > that required the wizardry of a yellow dot (just some routing background), > and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during > IESG Evaluation really isn't helpful to the document authors...its late, > design decisions have been made, which are being questioned, etc....it > tires people out, pisses off authors, and frustrates everybody involved. > > So, I've been playing around with a couple of ideas on the sideline, > unofficially, and with only unwitting assistance from others involved.... > > Thought #1: > I-Ds - when called for adoption as WG documents, or when published as > draft-ietf-...-00's, gets someone from the directorate assigned, to provide > an initial review and thoughts on "what directions would be good to take > (or avoid) here". That same reviewer can, occasionally, be invoked by the > WG chairs or authors, in the "so, did we catch this right?" -- and, of > course, should be called in on the WGLC of the document. I think of it a > little as the "area advisors" but to a document rather than a WG as a whole. > > I've been playing around with that a bit, as an author: > > o Since I know very little about security, I've looped in > somebody who did, when > having published a -00, and again the same person as > needed later in the process. > I've gotten hugely valuable feedback - making the > ultimate SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how little > I knew about security, presumably > less frustrating/time-consuming for the ADs, too, than if > I had been just shooting blind). > > o Since I know even less about OPS stuff, Adrian looped an > OPS guy in on an > individual -01, who asked a lot of good questions to what > we were doing, and why, > and which is hugely helpful. > > As an author in the RTG Area, the SEC and OPS ADs are often real > "roadblocks". Reasonably so, of course, they represent important concerns. > And gosh, every time I encounter any AD, I have to explain the whole > context over once again since, even if they've already gotten the story > once, they have to follow sufficiently many documents and topics that > something is bound to be flushed from their cache. > > Having someone, from the respective directorate, be more of a facilitator, > sparring-partner, and who - over time - follows the document (and, > presumably, follows much fewer documents concurrently) through the process > with the authors would be great, as an author. And possibly makes the ADs > encounter less poor documents. > > I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be > just as much of a roadblock as the SEC/OPS folks, and I have no reason to > not expect Alia to have the same high (or higher) standards....so I imagine > that a way the RTG-DIR could help "improve the image of the ADs" and at the > same time get the ADs time liberated from writing 10-page discusses, would > be something like the above.... > > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the > directorateS to a document > o this, through the documents lifecycle. > > Not sure if it scales, either, but as an author I've greatly enjoyed > having such a "ongoing relationship" with people helping me avoid pitfalls. > > A final note: having been around for a while in the IETF, it is really > easy to ask around for help from among other IETFers that one knows -- then > again, having been around for a while, presumably one has more experience > and needs less help in avoiding pitfalls. For a new(ish) author, who knows > few people and who presumably might be likely to need more help in avoiding > said pitfalls, it's a lot harder to actually reach out and get the right > people's eyes on a document -- and, even to know what eyes are good to get > on it. > > This might, actually, therefore be also a good way of the IETF to be more > welcoming and inclusive to new folks wanting to get involved. > > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version > of thought #1 is to have a more structure directorate review cycle during > IETF LC, or perhaps during "Publication Requested" and before "AD > Evaluation". I am thinking that these be of the form: an I-D hits the AD, > the responsible/sponsoring AD requests directorate reviews from all the > concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer > iterate until either (i) issues are squared off or (ii) either authors or > reviewer declare the other as "bat-crap-crazy" (or, complains that the > other side is not responsive) and raise the issue to the AD. AD moves the > document forward to "AD Evaluation" only once happy with the outcome of > directorate reviews. In short, hiving out a lot more of the "problem > fixing" that happens during these reviews off to the directorates - and > leaving ADs to process presumably "less broken" documents. > > As an author, I have actually found it a LOT easier/faster to iterate with > a directorate reviewer (who has my document fresh in mind), than with an AD > who's preoccupied with a dozen or so documents at the same time, and other > emergencies. Now, mind you, some ADs are good at saying "Busy, will come > back to you in n days" -- others, alas, do "play dead" if they feel they > have more important fish to fry, and that's frustrating. > > This might lessen the load on the ADs, but still has the disadvantage that > one gets feedback *very* late in the process....just a little bit earlier > than during IESG processing. > > Thought #3: > I thought it's worth calling out, that either of the above are not really > related to RTG documents: I should think that RTG WG Chairs are plenty able > to do the necessary during WG processing, and as an author in the RTG Area, > I do usually know how to grab someone competent from the same area for > advice, as needed. While doing something like this intra-area can be a good > thing, the real boast that I, as document author, have felt has been > through getting cross-area feedback. Just as (being forced to be) reviewing > document outside of the RTG area has been hugely educational and. > > Cheers, > > Thomas > > > On 21 Mar 2014, at 19:31, Adrian Farrel wrote: > > > Hello Directorate and WG chairs, > > > > Alia and I have been discussing the Routing Area, its work, its output, > and its > > working groups. > > > > We have reached a conclusion (which perhaps we should have come to > sooner) that > > we need your help and input. > > > > The crunch question for us is "What makes it hard to get work done in the > > Routing Area?" What gets in the way of your work? What is making life > hard for > > document authors? How could working groups be doing better? We are open > to all > > and every type of answer. We are happy to have quick, one-line answers or > > deeply-considered essays. > > > > What do you think? > > > > Thanks for all your input, > > Adrian and Alia > > > > PS Please respond to both aliases because not everyone is on both lists. > Sorry > > that that means some of you will get duplicates. > > > > --20cf303ea63415df6904f56f9679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thomas,

Thanks very much for your thoug= hts. =A0On the being underutilized and on cross-area review, what do you an= d others in the Routing Directorate think about being asked to follow a sin= gle additional working group that is not in RTG and may have routing relate= d issues?

For the time speedup of ADs, I'm told that it'd= be really really useful to have more active document shepherds - who can f= acilitate getting comments and having them addressed. =A0I'm not sure h= ow to put that into place really. =A0As a WG chair, I felt like I was proce= ssing and pushing few enough drafts that I could do the shepherd job also -= but I know that there are some WGs where there is higher throughput. =A0It= 's also a good way of growing a person, to let them see the whole proce= ss and deal with the discussions.

For the drafts, I'd love to see earlier reviews. = =A0I'm not sure if at WG adoption is quite the right time, but it is a = good approximation of "early in the process". =A0 We could ask WG= chairs to request a reviewer at that point for drafts that may need it and= see what the load looks like. =A0For a start-up, having interested WG chai= rs identify WG drafts that could benefit from review would be helpful/inter= esting in terms of seeing the workload.

Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM,= Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as th= ere are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "u= nder-utilized". An occasional review of an I-D at an extremely late st= ate of its process, and a very rare more global question like this. As has = been discussed widely lately, ADs are overworked and have too little time, = so perhaps they do not call on the directorate enough - and, also, delegati= on of tasks that the ADs have to do is probably perceived as rather hard.
I've been dumbfounded by some of the reviews I have seen from ADs, eith= er during AD Evaluation or IESG Reviews: one particular case came to mind w= here Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker = during IESG Evaluation. It doesn't matter what document or WG it was, w= hat matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the DI= SCUSS/COMMENTs that required the wizardry of a yellow dot (just some routin= g background), and -- most importantly -- (iv) getting a 10-page DISCUSS/CO= MMENT during IESG Evaluation really isn't helpful to the document autho= rs...its late, design decisions have been made, which are being questioned,= etc....it tires people out, pisses off authors, and frustrates everybody i= nvolved.

So, I've been playing around with a couple of ideas on the sideline, un= officially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft= -ietf-...-00's, gets someone from the directorate assigned, to provide = an initial review and thoughts on "what directions would be good to ta= ke (or avoid) here". That same reviewer can, occasionally, be invoked = by the WG chairs or authors, in the "so, did we catch this right?"= ; -- and, of course, should be called in on the WGLC of the document. I thi= nk of it a little as the "area advisors" but to a document rather= than a WG as a whole.

I've been playing around with that a bit, as an author:

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 Since I know very little about security, I= 9;ve looped in somebody who did, when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 having published a -00, and again the same = person as needed later in the process.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I've gotten =A0hugely valuable feedback= - making the ultimate SEC-DIR and SEC-AD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reviews a lot =A0less painful for me (and, = given how little I knew about security, presumably
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 less =A0frustrating/time-consuming for the = ADs, too, than if I had been just shooting blind).

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 Since I know even less about OPS stuff, Adria= n looped an OPS guy in on an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 individual -01, who asked a lot of good que= stions to what we were doing, and why,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "road= blocks". Reasonably so, of course, they represent important concerns. = And gosh, every time I encounter any AD, I have to explain the whole contex= t over once again since, even if they've already gotten the story once,= they have to follow sufficiently many documents and topics that something = is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, = sparring-partner, and who - over time - follows the document (and, presumab= ly, follows much fewer documents concurrently) through the process with the= authors would be great, as an author. And possibly makes the ADs encounter= less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be = just as much of a roadblock as the SEC/OPS folks, and I have no reason to n= ot expect Alia to have the same high (or higher) standards....so I imagine = that a way the RTG-DIR could help "improve the image of the ADs" = and at the same time get the ADs time liberated from writing 10-page discus= ses, would be something like the above....

In short, what I envision is a structured way of getting:
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 very early-reviews
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 a semi-permanent attachment of a reviewer fro= m the directorateS to a document
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed ha= ving such a "ongoing relationship" with people helping me avoid p= itfalls.

A final note: having been around for a while in the IETF, it is really easy= to ask around for help from among other IETFers that one knows -- then aga= in, having been around for a while, presumably one has more experience and = needs less help in avoiding pitfalls. For a new(ish) author, who knows few = people and who presumably might be likely to need more help in avoiding sai= d pitfalls, it's a lot harder to actually reach out and get the right p= eople's eyes on a document -- and, even to know what eyes are good to g= et on it.

This might, actually, therefore be also a good way of the IETF to be more w= elcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter vers= ion of thought #1 is to have a more structure directorate review cycle duri= ng IETF LC, or perhaps during "Publication Requested" and before = "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews fro= m all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors an= d reviewer iterate until either (i) issues are squared off or (ii) either a= uthors or reviewer declare the other as "bat-crap-crazy" (or, com= plains that the other side is not responsive) and raise the issue to the AD= . AD moves the document forward to "AD Evaluation" only once happ= y with the outcome of directorate reviews. In short, hiving out a lot more = of the "problem fixing" that happens during these reviews off to = the directorates - and leaving ADs to process presumably "less broken&= quot; documents.

As an author, I have actually found it a LOT easier/faster to iterate with = a directorate reviewer (who has my document fresh in mind), than with an AD= who's preoccupied with a dozen or so documents at the same time, and o= ther emergencies. Now, mind you, some ADs are good at saying "Busy, wi= ll come back to you in n days" -- others, alas, do "play dead&quo= t; if they feel they have more important fish to fry, and that's frustr= ating.

This might lessen the load on the ADs, but still has the disadvantage that = one gets feedback *very* late in the process....just a little bit earlier t= han during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not real= ly related to RTG documents: I should think that RTG WG Chairs are plenty a= ble to do the necessary during WG processing, and as an author in the RTG A= rea, I do usually know how to grab someone competent from the same area for= advice, as needed. While doing something like this intra-area can be a goo= d thing, the real boast that I, as document author, have felt has been thro= ugh getting cross-area feedback. Just as (being forced to be) reviewing doc= ument outside of the RTG area has been hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its output= , and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to soo= ner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work don= e in the
> Routing Area?" What gets in the way of your work? What is making = life hard for
> document authors? How could working groups be doing better? We are ope= n to all
> and every type of answer. We are happy to have quick, one-line answers= or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both list= s. Sorry
> that that means some of you will get duplicates.
>


--20cf303ea63415df6904f56f9679-- From nobody Tue Mar 25 08:10:41 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E16E1A01C0; Tue, 25 Mar 2014 08:10:18 -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 mbaQhquUYjgi; Tue, 25 Mar 2014 08:10:10 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 644E71A017D; Tue, 25 Mar 2014 08:09:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 98FED160B91; Tue, 25 Mar 2014 08:09:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4AEE6160B8B; Tue, 25 Mar 2014 08:09:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F703175A-E84D-4520-B245-A67C42B6D69A" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Tue, 25 Mar 2014 16:09:41 +0100 Message-Id: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> To: Alia Atlas X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wkCkBfhHeQ8uNDkuRCPIH4BPQR0 Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:10:18 -0000 --Apple-Mail=_F703175A-E84D-4520-B245-A67C42B6D69A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Alia, On 25 Mar 2014, at 15:58, Alia Atlas wrote: > Thomas, >=20 > Thanks very much for your thoughts. On the being underutilized and on = cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that = is not in RTG and may have routing related issues? Can't speak for the others, but I'd be glad to, personally. >=20 > For the time speedup of ADs, I'm told that it'd be really really = useful to have more active document shepherds - who can facilitate = getting comments and having them addressed. I'm not sure how to put = that into place really. As a WG chair, I felt like I was processing and = pushing few enough drafts that I could do the shepherd job also - but I = know that there are some WGs where there is higher throughput. It's = also a good way of growing a person, to let them see the whole process = and deal with the discussions. That is a good point. Honestly, I do not know, and am really torn on = this issue. On one hand, sometimes having a shepherd as "go-between" to whip lazy = ADs ;) or reviewers to come back with "So, did this address your = concerns?" could perhaps be helpful. Oftentimes, however - and this is = the "have been in this for long enough to have many of the ADs on Jabber = by now" - the shepherd is just-another-go-in-the-way: popping an IM to = Adrian (or whoever), getting a resolution, moving on, is a faster way of = waking him up from hibernation than waiting for a third-party to do the = same. Same for an AD holding a discuss, adding an extra intermediary to = go through ....not sold on the idea. So, I really do not know what to think about this. In the rare cases = where I have needed some whipping that I couldn't do myself, it has been = an AD so non-responsive that I doubt that a shepherd would do (was a = long time ago) and it required several other ADs ganging up....or (more = recently) where there was an issue with IANA requiring resolution = (Adrian helped out there, but possibly somebody else could have, too). > For the drafts, I'd love to see earlier reviews. I'm not sure if at = WG adoption is quite the right time, but it is a good approximation of = "early in the process". =20 I agree. It was just the least-arbitrary version number I could come up = with on short notice ;) > We could ask WG chairs to request a reviewer at that point for drafts = that may need it and see what the load looks like. For a start-up, = having interested WG chairs identify WG drafts that could benefit from = review would be helpful/interesting in terms of seeing the workload. Can't disagree on this. Thomas >=20 > Regards, > Alia >=20 >=20 > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen = wrote: > Hello ADs, Directorate, Chairs, >=20 > Interesting questions, thanks for caring and asking. >=20 > I am probably going to cut my answer into separate independent mails, = as there are vastly different topics in this question. >=20 > First, as a member of the RTG Directorate, I actually feel a little = "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As = has been discussed widely lately, ADs are overworked and have too little = time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as = rather hard. >=20 > I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to = mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the = tracker during IESG Evaluation. It doesn't matter what document or WG it = was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the = DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some = routing background), and -- most importantly -- (iv) getting a 10-page = DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the = document authors...its late, design decisions have been made, which are = being questioned, etc....it tires people out, pisses off authors, and = frustrates everybody involved. >=20 > So, I've been playing around with a couple of ideas on the sideline, = unofficially, and with only unwitting assistance from others = involved.... >=20 > Thought #1: > I-Ds - when called for adoption as WG documents, or when published as = draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good = to take (or avoid) here". That same reviewer can, occasionally, be = invoked by the WG chairs or authors, in the "so, did we catch this = right?" -- and, of course, should be called in on the WGLC of the = document. I think of it a little as the "area advisors" but to a = document rather than a WG as a whole. >=20 > I've been playing around with that a bit, as an author: >=20 > o Since I know very little about security, I've looped = in somebody who did, when > having published a -00, and again the same person as = needed later in the process. > I've gotten hugely valuable feedback - making the = ultimate SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how = little I knew about security, presumably > less frustrating/time-consuming for the ADs, too, = than if I had been just shooting blind). >=20 > o Since I know even less about OPS stuff, Adrian looped = an OPS guy in on an > individual -01, who asked a lot of good questions to = what we were doing, and why, > and which is hugely helpful. >=20 > As an author in the RTG Area, the SEC and OPS ADs are often real = "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the = whole context over once again since, even if they've already gotten the = story once, they have to follow sufficiently many documents and topics = that something is bound to be flushed from their cache. >=20 > Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the = document (and, presumably, follows much fewer documents concurrently) = through the process with the authors would be great, as an author. And = possibly makes the ADs encounter less poor documents. >=20 > I know that Adrian can (cf. the aforementioned 10-page = DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, = and I have no reason to not expect Alia to have the same high (or = higher) standards....so I imagine that a way the RTG-DIR could help = "improve the image of the ADs" and at the same time get the ADs time = liberated from writing 10-page discusses, would be something like the = above.... >=20 > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the = directorateS to a document > o this, through the documents lifecycle. >=20 > Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid = pitfalls. >=20 > A final note: having been around for a while in the IETF, it is really = easy to ask around for help from among other IETFers that one knows -- = then again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it. >=20 > This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved. >=20 > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review = cycle during IETF LC, or perhaps during "Publication Requested" and = before "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews = from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). = Authors and reviewer iterate until either (i) issues are squared off or = (ii) either authors or reviewer declare the other as "bat-crap-crazy" = (or, complains that the other side is not responsive) and raise the = issue to the AD. AD moves the document forward to "AD Evaluation" only = once happy with the outcome of directorate reviews. In short, hiving out = a lot more of the "problem fixing" that happens during these reviews off = to the directorates - and leaving ADs to process presumably "less = broken" documents. >=20 > As an author, I have actually found it a LOT easier/faster to iterate = with a directorate reviewer (who has my document fresh in mind), than = with an AD who's preoccupied with a dozen or so documents at the same = time, and other emergencies. Now, mind you, some ADs are good at saying = "Busy, will come back to you in n days" -- others, alas, do "play dead" = if they feel they have more important fish to fry, and that's = frustrating. >=20 > This might lessen the load on the ADs, but still has the disadvantage = that one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing. >=20 > Thought #3: > I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are = plenty able to do the necessary during WG processing, and as an author = in the RTG Area, I do usually know how to grab someone competent from = the same area for advice, as needed. While doing something like this = intra-area can be a good thing, the real boast that I, as document = author, have felt has been through getting cross-area feedback. Just as = (being forced to be) reviewing document outside of the RTG area has been = hugely educational and. >=20 > Cheers, >=20 > Thomas >=20 >=20 > On 21 Mar 2014, at 19:31, Adrian Farrel wrote: >=20 > > Hello Directorate and WG chairs, > > > > Alia and I have been discussing the Routing Area, its work, its = output, and its > > working groups. > > > > We have reached a conclusion (which perhaps we should have come to = sooner) that > > we need your help and input. > > > > The crunch question for us is "What makes it hard to get work done = in the > > Routing Area?" What gets in the way of your work? What is making = life hard for > > document authors? How could working groups be doing better? We are = open to all > > and every type of answer. We are happy to have quick, one-line = answers or > > deeply-considered essays. > > > > What do you think? > > > > Thanks for all your input, > > Adrian and Alia > > > > PS Please respond to both aliases because not everyone is on both = lists. Sorry > > that that means some of you will get duplicates. > > >=20 >=20 --Apple-Mail=_F703175A-E84D-4520-B245-A67C42B6D69A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Alia,

On 25 Mar 2014, at 15:58, = Alia Atlas <akatlas@gmail.com> = wrote:

Thomas,

Thanks very = much for your thoughts.  On the being underutilized and on = cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that = is not in RTG and may have routing related = issues?

Can't speak for the = others, but I'd be glad to, personally.


For the time speedup of ADs, I'm told that it'd be = really really useful to have more active document shepherds - who can = facilitate getting comments and having them addressed.  I'm not = sure how to put that into place really.  As a WG chair, I felt like = I was processing and pushing few enough drafts that I could do the = shepherd job also - but I know that there are some WGs where there is = higher throughput.  It's also a good way of growing a person, to = let them see the whole process and deal with the = discussions.

That is a good = point. Honestly, I do not know, and am really torn on this = issue.

On one hand, sometimes having a shepherd = as "go-between" to whip lazy ADs ;) or reviewers to come back with "So, = did this address your concerns?" could perhaps be helpful. Oftentimes, = however - and this is the "have been in this for long enough to have = many of the ADs on Jabber by now" - the shepherd is = just-another-go-in-the-way: popping an IM to Adrian (or whoever), = getting a resolution, moving on, is a faster way of waking him up from = hibernation than waiting for a third-party to do the same. Same for an = AD holding a discuss, adding an extra intermediary to go through ....not = sold on the idea.

So, I really do not know what = to think about this. In the rare cases where I have needed some whipping = that I couldn't do myself, it has been an AD so non-responsive that I = doubt that a shepherd would do (was a long time ago) and it required = several other ADs ganging up....or (more recently) where there was an = issue with IANA requiring resolution (Adrian helped out there, but = possibly somebody else could have, too).

For the drafts, I'd love to see = earlier reviews.  I'm not sure if at WG adoption is quite the right = time, but it is a good approximation of "early in the process". =  

I agree. It was just = the least-arbitrary version number I could come up with on short notice = ;)

We could = ask WG chairs to request a reviewer at that point for drafts that may = need it and see what the load looks like.  For a start-up, having = interested WG chairs identify WG drafts that could benefit from review = would be helpful/interesting in terms of seeing the = workload.

Can't disagree on = this.

Thomas


Regards,
Alia


On Tue, Mar 25, = 2014 at 10:38 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, = Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as = there are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little = "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As = has been discussed widely lately, ADs are overworked and have too little = time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as = rather hard.

I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to = mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the = tracker during IESG Evaluation. It doesn't matter what document or WG it = was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the = DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some = routing background), and -- most importantly -- (iv) getting a 10-page = DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the = document authors...its late, design decisions have been made, which are = being questioned, etc....it tires people out, pisses off authors, and = frustrates everybody involved.

So, I've been playing around with a couple of ideas on the sideline, = unofficially, and with only unwitting assistance from others = involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as = draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good = to take (or avoid) here". That same reviewer can, occasionally, be = invoked by the WG chairs or authors, in the "so, did we catch this = right?" -- and, of course, should be called in on the WGLC of the = document. I think of it a little as the "area advisors" but to a = document rather than a WG as a whole.

I've been playing around with that a bit, as an author:

        o       Since I know very = little about security, I've looped in somebody who did, when
                having published = a -00, and again the same person as needed later in the process.
                I've gotten =  hugely valuable feedback - making the ultimate SEC-DIR and = SEC-AD
                reviews a lot =  less painful for me (and, given how little I knew about security, = presumably
                less =  frustrating/time-consuming for the ADs, too, than if I had been = just shooting blind).

        o       Since I know even = less about OPS stuff, Adrian looped an OPS guy in on an
                individual -01, = who asked a lot of good questions to what we were doing, and why,
                and which is = hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real = "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the = whole context over once again since, even if they've already gotten the = story once, they have to follow sufficiently many documents and topics = that something is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the = document (and, presumably, follows much fewer documents concurrently) = through the process with the authors would be great, as an author. And = possibly makes the ADs encounter less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) = be just as much of a roadblock as the SEC/OPS folks, and I have no = reason to not expect Alia to have the same high (or higher) = standards....so I imagine that a way the RTG-DIR could help "improve the = image of the ADs" and at the same time get the ADs time liberated from = writing 10-page discusses, would be something like the above....

In short, what I envision is a structured way of getting:
        o       very = early-reviews
        o       a semi-permanent = attachment of a reviewer from the directorateS to a document
        o       this, through the = documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid = pitfalls.

A final note: having been around for a while in the IETF, it is really = easy to ask around for help from among other IETFers that one knows -- = then again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it.

This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review = cycle during IETF LC, or perhaps during "Publication Requested" and = before "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews = from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). = Authors and reviewer iterate until either (i) issues are squared off or = (ii) either authors or reviewer declare the other as "bat-crap-crazy" = (or, complains that the other side is not responsive) and raise the = issue to the AD. AD moves the document forward to "AD Evaluation" only = once happy with the outcome of directorate reviews. In short, hiving out = a lot more of the "problem fixing" that happens during these reviews off = to the directorates - and leaving ADs to process presumably "less = broken" documents.

As an author, I have actually found it a LOT easier/faster to iterate = with a directorate reviewer (who has my document fresh in mind), than = with an AD who's preoccupied with a dozen or so documents at the same = time, and other emergencies. Now, mind you, some ADs are good at saying = "Busy, will come back to you in n days" -- others, alas, do "play dead" = if they feel they have more important fish to fry, and that's = frustrating.

This might lessen the load on the ADs, but still has the disadvantage = that one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are = plenty able to do the necessary during WG processing, and as an author = in the RTG Area, I do usually know how to grab someone competent from = the same area for advice, as needed. While doing something like this = intra-area can be a good thing, the real boast that I, as document = author, have felt has been through getting cross-area feedback. Just as = (being forced to be) reviewing document outside of the RTG area has been = hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> = wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its = output, and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to = sooner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work done = in the
> Routing Area?" What gets in the way of your work? What is making = life hard for
> document authors? How could working groups be doing better? We are = open to all
> and every type of answer. We are happy to have quick, one-line = answers or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both = lists. Sorry
> that that means some of you will get duplicates.
>



= --Apple-Mail=_F703175A-E84D-4520-B245-A67C42B6D69A-- From nobody Tue Mar 25 08:20:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AE61A0178; Tue, 25 Mar 2014 08:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 JuPLbDqEbRuQ; Tue, 25 Mar 2014 08:20:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D26591A016D; Tue, 25 Mar 2014 08:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23353; q=dns/txt; s=iport; t=1395760825; x=1396970425; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9lKJREXAT17bcWogWqnZqQqct+5AN2p6irTA1pdZCeI=; b=l41Mkdp0dqbMfOnmIk6BKJepcd/m+kibCLGYtrtWkGuNRiqtGwj7iz5k SADBj9g9zvjGFdegdZnyxbUfTabrqXSsG2wTZf3Q1VaZd1fFfBdmv/m3w F2ULIVPKaRyk16zleD0d7UWGiYNMXmB0RwzBkn2O33sn+5NkpKB1U/3ra 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAIADaeMVOtJXHA/2dsb2JhbABPCoMGgRK/K4NCgRoWdIIlAQEBAwFxAQcFCwIBCA4xByERFBEBAQQOBRmHTAMJCMgNDYcyF4lCgxCBQFwHgySBFASJGo1GgW2MaIVKgy6CKw X-IronPort-AV: E=Sophos;i="4.97,728,1389744000"; d="scan'208,217";a="312817765" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 25 Mar 2014 15:20:24 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2PFKN7S014619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 15:20:24 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.176]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 10:20:23 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgDLhgGAAACyXgAAAMLoAA== Date: Tue, 25 Mar 2014 15:20:23 +0000 Message-ID: <6CBA50AB-1754-47BC-A273-51A92A12CAB8@cisco.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: multipart/alternative; boundary="_000_6CBA50AB175447BCA27351A92A12CAB8ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/QYAO2d55xmgit95MITp-aW8cbNw Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:20:30 -0000 --_000_6CBA50AB175447BCA27351A92A12CAB8ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Alia, On Mar 25, 2014, at 10:58 AM, Alia Atlas > wrote: Thomas, Thanks very much for your thoughts. On the being underutilized and on cros= s-area review, what do you and others in the Routing Directorate think abou= t being asked to follow a single additional working group that is not in RT= G and may have routing related issues? I think this is a great idea and a best practice. Something of a "liaison" = to key WGs that could have routing-related issues. It can help with early i= dentification of issues and raise appropriate flags, but also it can be inp= ut into the early review queue (point you also make below). Thanks, -- Carlos. For the time speedup of ADs, I'm told that it'd be really really useful to = have more active document shepherds - who can facilitate getting comments a= nd having them addressed. I'm not sure how to put that into place really. = As a WG chair, I felt like I was processing and pushing few enough drafts = that I could do the shepherd job also - but I know that there are some WGs = where there is higher throughput. It's also a good way of growing a person= , to let them see the whole process and deal with the discussions. For the drafts, I'd love to see earlier reviews. I'm not sure if at WG ado= ption is quite the right time, but it is a good approximation of "early in = the process". We could ask WG chairs to request a reviewer at that point = for drafts that may need it and see what the load looks like. For a start-= up, having interested WG chairs identify WG drafts that could benefit from = review would be helpful/interesting in terms of seeing the workload. Regards, Alia On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > wrote: Hello ADs, Directorate, Chairs, Interesting questions, thanks for caring and asking. I am probably going to cut my answer into separate independent mails, as th= ere are vastly different topics in this question. First, as a member of the RTG Directorate, I actually feel a little "under-= utilized". An occasional review of an I-D at an extremely late state of its= process, and a very rare more global question like this. As has been discu= ssed widely lately, ADs are overworked and have too little time, so perhaps= they do not call on the directorate enough - and, also, delegation of task= s that the ADs have to do is probably perceived as rather hard. I've been dumbfounded by some of the reviews I have seen from ADs, either d= uring AD Evaluation or IESG Reviews: one particular case came to mind where= Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker duri= ng IESG Evaluation. It doesn't matter what document or WG it was, what matt= ers is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's = time, (iii) there wasn't really something in the DISCUSS/COMMENTs that requ= ired the wizardry of a yellow dot (just some routing background), and -- mo= st importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG Evalua= tion really isn't helpful to the document authors...its late, design decisi= ons have been made, which are being questioned, etc....it tires people out,= pisses off authors, and frustrates everybody involved. So, I've been playing around with a couple of ideas on the sideline, unoffi= cially, and with only unwitting assistance from others involved.... Thought #1: I-Ds - when called for adoption as WG documents, or when published as draft= -ietf-...-00's, gets someone from the directorate assigned, to provide an i= nitial review and thoughts on "what directions would be good to take (or av= oid) here". That same reviewer can, occasionally, be invoked by the WG chai= rs or authors, in the "so, did we catch this right?" -- and, of course, sho= uld be called in on the WGLC of the document. I think of it a little as the= "area advisors" but to a document rather than a WG as a whole. I've been playing around with that a bit, as an author: o Since I know very little about security, I've looped in som= ebody who did, when having published a -00, and again the same person as needed= later in the process. I've gotten hugely valuable feedback - making the ultimate= SEC-DIR and SEC-AD reviews a lot less painful for me (and, given how little I= knew about security, presumably less frustrating/time-consuming for the ADs, too, than if = I had been just shooting blind). o Since I know even less about OPS stuff, Adrian looped an OP= S guy in on an individual -01, who asked a lot of good questions to what w= e were doing, and why, and which is hugely helpful. As an author in the RTG Area, the SEC and OPS ADs are often real "roadblock= s". Reasonably so, of course, they represent important concerns. And gosh, = every time I encounter any AD, I have to explain the whole context over onc= e again since, even if they've already gotten the story once, they have to = follow sufficiently many documents and topics that something is bound to be= flushed from their cache. Having someone, from the respective directorate, be more of a facilitator, = sparring-partner, and who - over time - follows the document (and, presumab= ly, follows much fewer documents concurrently) through the process with the= authors would be great, as an author. And possibly makes the ADs encounter= less poor documents. I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be = just as much of a roadblock as the SEC/OPS folks, and I have no reason to n= ot expect Alia to have the same high (or higher) standards....so I imagine = that a way the RTG-DIR could help "improve the image of the ADs" and at the= same time get the ADs time liberated from writing 10-page discusses, would= be something like the above.... In short, what I envision is a structured way of getting: o very early-reviews o a semi-permanent attachment of a reviewer from the director= ateS to a document o this, through the documents lifecycle. Not sure if it scales, either, but as an author I've greatly enjoyed having= such a "ongoing relationship" with people helping me avoid pitfalls. A final note: having been around for a while in the IETF, it is really easy= to ask around for help from among other IETFers that one knows -- then aga= in, having been around for a while, presumably one has more experience and = needs less help in avoiding pitfalls. For a new(ish) author, who knows few = people and who presumably might be likely to need more help in avoiding sai= d pitfalls, it's a lot harder to actually reach out and get the right peopl= e's eyes on a document -- and, even to know what eyes are good to get on it= . This might, actually, therefore be also a good way of the IETF to be more w= elcoming and inclusive to new folks wanting to get involved. Thought #2: So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version = of thought #1 is to have a more structure directorate review cycle during I= ETF LC, or perhaps during "Publication Requested" and before "AD Evaluation= ". I am thinking that these be of the form: an I-D hits the AD, the respons= ible/sponsoring AD requests directorate reviews from all the concerned dire= ctorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer iterate until= either (i) issues are squared off or (ii) either authors or reviewer decla= re the other as "bat-crap-crazy" (or, complains that the other side is not = responsive) and raise the issue to the AD. AD moves the document forward to= "AD Evaluation" only once happy with the outcome of directorate reviews. I= n short, hiving out a lot more of the "problem fixing" that happens during = these reviews off to the directorates - and leaving ADs to process presumab= ly "less broken" documents. As an author, I have actually found it a LOT easier/faster to iterate with = a directorate reviewer (who has my document fresh in mind), than with an AD= who's preoccupied with a dozen or so documents at the same time, and other= emergencies. Now, mind you, some ADs are good at saying "Busy, will come b= ack to you in n days" -- others, alas, do "play dead" if they feel they hav= e more important fish to fry, and that's frustrating. This might lessen the load on the ADs, but still has the disadvantage that = one gets feedback *very* late in the process....just a little bit earlier t= han during IESG processing. Thought #3: I thought it's worth calling out, that either of the above are not really r= elated to RTG documents: I should think that RTG WG Chairs are plenty able = to do the necessary during WG processing, and as an author in the RTG Area,= I do usually know how to grab someone competent from the same area for adv= ice, as needed. While doing something like this intra-area can be a good th= ing, the real boast that I, as document author, have felt has been through = getting cross-area feedback. Just as (being forced to be) reviewing documen= t outside of the RTG area has been hugely educational and. Cheers, Thomas On 21 Mar 2014, at 19:31, Adrian Farrel > wrote: > Hello Directorate and WG chairs, > > Alia and I have been discussing the Routing Area, its work, its output, a= nd its > working groups. > > We have reached a conclusion (which perhaps we should have come to sooner= ) that > we need your help and input. > > The crunch question for us is "What makes it hard to get work done in the > Routing Area?" What gets in the way of your work? What is making life har= d for > document authors? How could working groups be doing better? We are open t= o all > and every type of answer. We are happy to have quick, one-line answers or > deeply-considered essays. > > What do you think? > > Thanks for all your input, > Adrian and Alia > > PS Please respond to both aliases because not everyone is on both lists. = Sorry > that that means some of you will get duplicates. > --_000_6CBA50AB175447BCA27351A92A12CAB8ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable Hi, Alia,

On Mar 25, 2014, at 10:58 AM, Alia Atlas <akatlas@gmail.com> wrote:

Thomas,

Thanks very much for your thoughts.  On the being underutilized a= nd on cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that is= not in RTG and may have routing related issues?

I think this is a great idea and a best practice. Something of a "= ;liaison" to key WGs that could have routing-related issues. It can he= lp with early identification of issues and raise appropriate flags, but als= o it can be input into the early review queue (point you also make below).

Thanks,

-- Carlos.


For the time speedup of ADs, I'm told that it'd be really really usefu= l to have more active document shepherds - who can facilitate getting comme= nts and having them addressed.  I'm not sure how to put that into plac= e really.  As a WG chair, I felt like I was processing and pushing few enough drafts that I could do the shepher= d job also - but I know that there are some WGs where there is higher throu= ghput.  It's also a good way of growing a person, to let them see the = whole process and deal with the discussions.

For the drafts, I'd love to see earlier reviews.  I'm not sure if= at WG adoption is quite the right time, but it is a good approximation of = "early in the process".   We could ask WG chairs to request = a reviewer at that point for drafts that may need it and see what the load looks like.  For a start-up, having interested = WG chairs identify WG drafts that could benefit from review would be helpfu= l/interesting in terms of seeing the workload.

Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen= <thomas@th= omasclausen.org> wrote:
Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as th= ere are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "u= nder-utilized". An occasional review of an I-D at an extremely late st= ate of its process, and a very rare more global question like this. As has = been discussed widely lately, ADs are overworked and have too little time, so perhaps they do not call on the directorate e= nough - and, also, delegation of tasks that the ADs have to do is probably = perceived as rather hard.

I've been dumbfounded by some of the reviews I have seen from ADs, either d= uring AD Evaluation or IESG Reviews: one particular case came to mind where= Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker duri= ng IESG Evaluation. It doesn't matter what document or WG it was, what matters is that (i) it doesn't scale IETF= -wide, (ii) it's poor use of Adrian's time, (iii) there wasn't really somet= hing in the DISCUSS/COMMENTs that required the wizardry of a yellow dot (ju= st some routing background), and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG = Evaluation really isn't helpful to the document authors...its late, design = decisions have been made, which are being questioned, etc....it tires peopl= e out, pisses off authors, and frustrates everybody involved.

So, I've been playing around with a couple of ideas on the sideline, unoffi= cially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft= -ietf-...-00's, gets someone from the directorate assigned, to provide an i= nitial review and thoughts on "what directions would be good to take (= or avoid) here". That same reviewer can, occasionally, be invoked by the WG chairs or authors, in the "so, did= we catch this right?" -- and, of course, should be called in on the W= GLC of the document. I think of it a little as the "area advisors"= ; but to a document rather than a WG as a whole.

I've been playing around with that a bit, as an author:

        o       Since I know very little= about security, I've looped in somebody who did, when
                having published a = -00, and again the same person as needed later in the process.
                I've gotten  h= ugely valuable feedback - making the ultimate SEC-DIR and SEC-AD
                reviews a lot  = ;less painful for me (and, given how little I knew about security, presumab= ly
                less  frustrat= ing/time-consuming for the ADs, too, than if I had been just shooting blind= ).

        o       Since I know even less a= bout OPS stuff, Adrian looped an OPS guy in on an
                individual -01, who= asked a lot of good questions to what we were doing, and why,
                and which is hugely= helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "road= blocks". Reasonably so, of course, they represent important concerns. = And gosh, every time I encounter any AD, I have to explain the whole contex= t over once again since, even if they've already gotten the story once, they have to follow sufficiently many documents and= topics that something is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, = sparring-partner, and who - over time - follows the document (and, presumab= ly, follows much fewer documents concurrently) through the process with the= authors would be great, as an author. And possibly makes the ADs encounter less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be = just as much of a roadblock as the SEC/OPS folks, and I have no reason to n= ot expect Alia to have the same high (or higher) standards....so I imagine = that a way the RTG-DIR could help "improve the image of the ADs" and at the same time get the ADs = time liberated from writing 10-page discusses, would be something like the = above....

In short, what I envision is a structured way of getting:
        o       very early-reviews
        o       a semi-permanent attachm= ent of a reviewer from the directorateS to a document
        o       this, through the docume= nts lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed having= such a "ongoing relationship" with people helping me avoid pitfa= lls.

A final note: having been around for a while in the IETF, it is really easy= to ask around for help from among other IETFers that one knows -- then aga= in, having been around for a while, presumably one has more experience and = needs less help in avoiding pitfalls. For a new(ish) author, who knows few people and who presumably might be li= kely to need more help in avoiding said pitfalls, it's a lot harder to actu= ally reach out and get the right people's eyes on a document -- and, even t= o know what eyes are good to get on it.

This might, actually, therefore be also a good way of the IETF to be more w= elcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version = of thought #1 is to have a more structure directorate review cycle during I= ETF LC, or perhaps during "Publication Requested" and before &quo= t;AD Evaluation". I am thinking that these be of the form: an I-D hits the AD, the responsible/sponsoring AD requests direc= torate reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP= , ...). Authors and reviewer iterate until either (i) issues are squared of= f or (ii) either authors or reviewer declare the other as "bat-crap-crazy" (or, complains that the ot= her side is not responsive) and raise the issue to the AD. AD moves the doc= ument forward to "AD Evaluation" only once happy with the outcome= of directorate reviews. In short, hiving out a lot more of the "problem fixing" that happens during these reviews o= ff to the directorates - and leaving ADs to process presumably "less b= roken" documents.

As an author, I have actually found it a LOT easier/faster to iterate with = a directorate reviewer (who has my document fresh in mind), than with an AD= who's preoccupied with a dozen or so documents at the same time, and other= emergencies. Now, mind you, some ADs are good at saying "Busy, will come back to you in n days" -= - others, alas, do "play dead" if they feel they have more import= ant fish to fry, and that's frustrating.

This might lessen the load on the ADs, but still has the disadvantage that = one gets feedback *very* late in the process....just a little bit earlier t= han during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not really r= elated to RTG documents: I should think that RTG WG Chairs are plenty able = to do the necessary during WG processing, and as an author in the RTG Area,= I do usually know how to grab someone competent from the same area for advice, as needed. While doing something = like this intra-area can be a good thing, the real boast that I, as documen= t author, have felt has been through getting cross-area feedback. Just as (= being forced to be) reviewing document outside of the RTG area has been hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its output= , and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to soo= ner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work don= e in the
> Routing Area?" What gets in the way of your work? What is making = life hard for
> document authors? How could working groups be doing better? We are ope= n to all
> and every type of answer. We are happy to have quick, one-line answers= or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both list= s. Sorry
> that that means some of you will get duplicates.
>



--_000_6CBA50AB175447BCA27351A92A12CAB8ciscocom_-- From nobody Tue Mar 25 08:22:17 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6361A016E; Tue, 25 Mar 2014 08:21: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 0AEBcryZ4k3Z; Tue, 25 Mar 2014 08:21:49 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 683181A016D; Tue, 25 Mar 2014 08:21:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9C661160D73; Tue, 25 Mar 2014 08:21:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 7C86B160D58; Tue, 25 Mar 2014 08:21:45 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6512CD0E-259B-4B6A-BA97-B9A7E03FA736" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Tue, 25 Mar 2014 16:21:42 +0100 Message-Id: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> To: Alia Atlas X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/vnTe3DjZBBRaQcbHDT5jCnoAU_A Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:21:57 -0000 --Apple-Mail=_6512CD0E-259B-4B6A-BA97-B9A7E03FA736 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello ADs, Directorate and Chairs, Oh, and one more thing.....I know, I live a sad life when I realise that = I socialise with IETFers over the weekend, and this email became the = topic of conversation....but, hey... This mail thread started out with some folks making proposals on = closing, merging, and moving WGs, which I briefly mentioned as a = discussion-point during the aforementioned conversation - thought I'd = bring the resulting discussion out here. The exchange (sanitised for public consumption by removing swear-words) = went roughly like this: Me: So the RTG ADs asked for a "health check" of the RTG = Area, to the RTG-WG chairs and RTG-DIR, what=20 could be done to better the area, make it more = efficient, etc. Me: Someone suggested that the best was to close = and merge , and perhaps IETFer #1 (who has been in the IETF for 5-6 years) interrupted: That's the F***ING problem with the IETF, all = discussions happen behind closed doors, and we do not have a say in things. IETFer #2 (who's been having an on-again-off-again relationship = with the IETF for a decade or so): That's the same with all those secret directorates, = whose reviews we now have to contend with, where did they suddenly come from, secret committees. I am not sure that this is RTG-area specific, but it is not the first = time that I have heard someone do a double-take when presented with a = GEN-ART, SEC-DIR, or other such review, or heard of discussions within = such groups, or the existence of such groups.=20 Perhaps a root cause of this is, that these groups are seen (like the = IESG) as "roadblocks, not facilitators" because...getting a huge = critical review during an IETF LC is just that...a roadblock. And, = perhaps, getting the directorates more involved much earlier would also = solve such "image problems" of the IETF being an "old-folks-club"? Thomas On 25 Mar 2014, at 15:58, Alia Atlas wrote: > Thomas, >=20 > Thanks very much for your thoughts. On the being underutilized and on = cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that = is not in RTG and may have routing related issues? >=20 > For the time speedup of ADs, I'm told that it'd be really really = useful to have more active document shepherds - who can facilitate = getting comments and having them addressed. I'm not sure how to put = that into place really. As a WG chair, I felt like I was processing and = pushing few enough drafts that I could do the shepherd job also - but I = know that there are some WGs where there is higher throughput. It's = also a good way of growing a person, to let them see the whole process = and deal with the discussions. >=20 > For the drafts, I'd love to see earlier reviews. I'm not sure if at = WG adoption is quite the right time, but it is a good approximation of = "early in the process". We could ask WG chairs to request a reviewer = at that point for drafts that may need it and see what the load looks = like. For a start-up, having interested WG chairs identify WG drafts = that could benefit from review would be helpful/interesting in terms of = seeing the workload. >=20 > Regards, > Alia >=20 >=20 > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen = wrote: > Hello ADs, Directorate, Chairs, >=20 > Interesting questions, thanks for caring and asking. >=20 > I am probably going to cut my answer into separate independent mails, = as there are vastly different topics in this question. >=20 > First, as a member of the RTG Directorate, I actually feel a little = "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As = has been discussed widely lately, ADs are overworked and have too little = time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as = rather hard. >=20 > I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to = mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the = tracker during IESG Evaluation. It doesn't matter what document or WG it = was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the = DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some = routing background), and -- most importantly -- (iv) getting a 10-page = DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the = document authors...its late, design decisions have been made, which are = being questioned, etc....it tires people out, pisses off authors, and = frustrates everybody involved. >=20 > So, I've been playing around with a couple of ideas on the sideline, = unofficially, and with only unwitting assistance from others = involved.... >=20 > Thought #1: > I-Ds - when called for adoption as WG documents, or when published as = draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good = to take (or avoid) here". That same reviewer can, occasionally, be = invoked by the WG chairs or authors, in the "so, did we catch this = right?" -- and, of course, should be called in on the WGLC of the = document. I think of it a little as the "area advisors" but to a = document rather than a WG as a whole. >=20 > I've been playing around with that a bit, as an author: >=20 > o Since I know very little about security, I've looped = in somebody who did, when > having published a -00, and again the same person as = needed later in the process. > I've gotten hugely valuable feedback - making the = ultimate SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how = little I knew about security, presumably > less frustrating/time-consuming for the ADs, too, = than if I had been just shooting blind). >=20 > o Since I know even less about OPS stuff, Adrian looped = an OPS guy in on an > individual -01, who asked a lot of good questions to = what we were doing, and why, > and which is hugely helpful. >=20 > As an author in the RTG Area, the SEC and OPS ADs are often real = "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the = whole context over once again since, even if they've already gotten the = story once, they have to follow sufficiently many documents and topics = that something is bound to be flushed from their cache. >=20 > Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the = document (and, presumably, follows much fewer documents concurrently) = through the process with the authors would be great, as an author. And = possibly makes the ADs encounter less poor documents. >=20 > I know that Adrian can (cf. the aforementioned 10-page = DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, = and I have no reason to not expect Alia to have the same high (or = higher) standards....so I imagine that a way the RTG-DIR could help = "improve the image of the ADs" and at the same time get the ADs time = liberated from writing 10-page discusses, would be something like the = above.... >=20 > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the = directorateS to a document > o this, through the documents lifecycle. >=20 > Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid = pitfalls. >=20 > A final note: having been around for a while in the IETF, it is really = easy to ask around for help from among other IETFers that one knows -- = then again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it. >=20 > This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved. >=20 > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review = cycle during IETF LC, or perhaps during "Publication Requested" and = before "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews = from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). = Authors and reviewer iterate until either (i) issues are squared off or = (ii) either authors or reviewer declare the other as "bat-crap-crazy" = (or, complains that the other side is not responsive) and raise the = issue to the AD. AD moves the document forward to "AD Evaluation" only = once happy with the outcome of directorate reviews. In short, hiving out = a lot more of the "problem fixing" that happens during these reviews off = to the directorates - and leaving ADs to process presumably "less = broken" documents. >=20 > As an author, I have actually found it a LOT easier/faster to iterate = with a directorate reviewer (who has my document fresh in mind), than = with an AD who's preoccupied with a dozen or so documents at the same = time, and other emergencies. Now, mind you, some ADs are good at saying = "Busy, will come back to you in n days" -- others, alas, do "play dead" = if they feel they have more important fish to fry, and that's = frustrating. >=20 > This might lessen the load on the ADs, but still has the disadvantage = that one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing. >=20 > Thought #3: > I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are = plenty able to do the necessary during WG processing, and as an author = in the RTG Area, I do usually know how to grab someone competent from = the same area for advice, as needed. While doing something like this = intra-area can be a good thing, the real boast that I, as document = author, have felt has been through getting cross-area feedback. Just as = (being forced to be) reviewing document outside of the RTG area has been = hugely educational and. >=20 > Cheers, >=20 > Thomas >=20 >=20 > On 21 Mar 2014, at 19:31, Adrian Farrel wrote: >=20 > > Hello Directorate and WG chairs, > > > > Alia and I have been discussing the Routing Area, its work, its = output, and its > > working groups. > > > > We have reached a conclusion (which perhaps we should have come to = sooner) that > > we need your help and input. > > > > The crunch question for us is "What makes it hard to get work done = in the > > Routing Area?" What gets in the way of your work? What is making = life hard for > > document authors? How could working groups be doing better? We are = open to all > > and every type of answer. We are happy to have quick, one-line = answers or > > deeply-considered essays. > > > > What do you think? > > > > Thanks for all your input, > > Adrian and Alia > > > > PS Please respond to both aliases because not everyone is on both = lists. Sorry > > that that means some of you will get duplicates. > > >=20 >=20 --Apple-Mail=_6512CD0E-259B-4B6A-BA97-B9A7E03FA736 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hello ADs, Directorate and = Chairs,

Oh, and one more thing.....I know, I = live a sad life when I realise that I socialise with IETFers over the = weekend, and this email became the topic of conversation....but, = hey...

This mail thread started out with some = folks making proposals on closing, merging, and moving WGs, which I = briefly mentioned as a discussion-point during the aforementioned = conversation - thought I'd bring the resulting discussion out = here.

The exchange (sanitised for public = consumption by removing swear-words) went roughly like = this:

Me: So the RTG ADs asked for a = "health check" of the RTG Area, to the RTG-WG chairs and RTG-DIR, = what 
could be done to better the area, make it more = efficient, etc.

Me: Someone suggested that the best = was to close <list-of-wg's> and merge <other-list-of-wg's>, = and perhaps

IETFer #1 (who has been in the = IETF for 5-6 years) interrupted:
That's  the F***ING = problem with the IETF, all discussions happen behind closed doors, and = we
= do not have a say in = things.

IETFer #2 (who's been having an = on-again-off-again relationship with the IETF for a decade or = so):
That's the same with all those secret = directorates, whose reviews we now have to contend with, = where
did they suddenly come from, secret = committees.

<rant went on for a bit, then = we veered into much more consensual subjects, like = the 
  the existence of extraterrestrials, if = mint-jelly really belongs in a hot meal, if 
=   vegemite qualifies as food,and who should win this = years premier league in football>

I am = not sure that this is RTG-area specific, but it is not the first time = that I have heard someone do a double-take when presented with a = GEN-ART, SEC-DIR, or other such review, or heard of discussions within = such groups, or the existence of such = groups. 

Perhaps a root cause of this is, = that these groups are seen (like the IESG) as "roadblocks, not = facilitators" because...getting a huge critical review during an IETF LC = is just that...a roadblock. And, perhaps, getting the directorates more = involved much earlier would also solve such "image problems" of the IETF = being an = "old-folks-club"?

Thomas


On 25 Mar 2014, at 15:58, Alia Atlas <akatlas@gmail.com> = wrote:

Thomas,

Thanks very = much for your thoughts.  On the being underutilized and on = cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that = is not in RTG and may have routing related issues?

For the time speedup of ADs, I'm told that it'd be = really really useful to have more active document shepherds - who can = facilitate getting comments and having them addressed.  I'm not = sure how to put that into place really.  As a WG chair, I felt like = I was processing and pushing few enough drafts that I could do the = shepherd job also - but I know that there are some WGs where there is = higher throughput.  It's also a good way of growing a person, to = let them see the whole process and deal with the discussions.

For the drafts, I'd love to see earlier reviews. =  I'm not sure if at WG adoption is quite the right time, but it is = a good approximation of "early in the process".   We could ask WG = chairs to request a reviewer at that point for drafts that may need it = and see what the load looks like.  For a start-up, having = interested WG chairs identify WG drafts that could benefit from review = would be helpful/interesting in terms of seeing the workload.

Regards,
Alia


On Tue, Mar 25, = 2014 at 10:38 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, = Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as = there are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little = "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As = has been discussed widely lately, ADs are overworked and have too little = time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as = rather hard.

I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to = mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the = tracker during IESG Evaluation. It doesn't matter what document or WG it = was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the = DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some = routing background), and -- most importantly -- (iv) getting a 10-page = DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the = document authors...its late, design decisions have been made, which are = being questioned, etc....it tires people out, pisses off authors, and = frustrates everybody involved.

So, I've been playing around with a couple of ideas on the sideline, = unofficially, and with only unwitting assistance from others = involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as = draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good = to take (or avoid) here". That same reviewer can, occasionally, be = invoked by the WG chairs or authors, in the "so, did we catch this = right?" -- and, of course, should be called in on the WGLC of the = document. I think of it a little as the "area advisors" but to a = document rather than a WG as a whole.

I've been playing around with that a bit, as an author:

        o       Since I know very = little about security, I've looped in somebody who did, when
                having published = a -00, and again the same person as needed later in the process.
                I've gotten =  hugely valuable feedback - making the ultimate SEC-DIR and = SEC-AD
                reviews a lot =  less painful for me (and, given how little I knew about security, = presumably
                less =  frustrating/time-consuming for the ADs, too, than if I had been = just shooting blind).

        o       Since I know even = less about OPS stuff, Adrian looped an OPS guy in on an
                individual -01, = who asked a lot of good questions to what we were doing, and why,
                and which is = hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real = "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the = whole context over once again since, even if they've already gotten the = story once, they have to follow sufficiently many documents and topics = that something is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the = document (and, presumably, follows much fewer documents concurrently) = through the process with the authors would be great, as an author. And = possibly makes the ADs encounter less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) = be just as much of a roadblock as the SEC/OPS folks, and I have no = reason to not expect Alia to have the same high (or higher) = standards....so I imagine that a way the RTG-DIR could help "improve the = image of the ADs" and at the same time get the ADs time liberated from = writing 10-page discusses, would be something like the above....

In short, what I envision is a structured way of getting:
        o       very = early-reviews
        o       a semi-permanent = attachment of a reviewer from the directorateS to a document
        o       this, through the = documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid = pitfalls.

A final note: having been around for a while in the IETF, it is really = easy to ask around for help from among other IETFers that one knows -- = then again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it.

This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review = cycle during IETF LC, or perhaps during "Publication Requested" and = before "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews = from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). = Authors and reviewer iterate until either (i) issues are squared off or = (ii) either authors or reviewer declare the other as "bat-crap-crazy" = (or, complains that the other side is not responsive) and raise the = issue to the AD. AD moves the document forward to "AD Evaluation" only = once happy with the outcome of directorate reviews. In short, hiving out = a lot more of the "problem fixing" that happens during these reviews off = to the directorates - and leaving ADs to process presumably "less = broken" documents.

As an author, I have actually found it a LOT easier/faster to iterate = with a directorate reviewer (who has my document fresh in mind), than = with an AD who's preoccupied with a dozen or so documents at the same = time, and other emergencies. Now, mind you, some ADs are good at saying = "Busy, will come back to you in n days" -- others, alas, do "play dead" = if they feel they have more important fish to fry, and that's = frustrating.

This might lessen the load on the ADs, but still has the disadvantage = that one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are = plenty able to do the necessary during WG processing, and as an author = in the RTG Area, I do usually know how to grab someone competent from = the same area for advice, as needed. While doing something like this = intra-area can be a good thing, the real boast that I, as document = author, have felt has been through getting cross-area feedback. Just as = (being forced to be) reviewing document outside of the RTG area has been = hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> = wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its = output, and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to = sooner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work done = in the
> Routing Area?" What gets in the way of your work? What is making = life hard for
> document authors? How could working groups be doing better? We are = open to all
> and every type of answer. We are happy to have quick, one-line = answers or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both = lists. Sorry
> that that means some of you will get duplicates.
>



= --Apple-Mail=_6512CD0E-259B-4B6A-BA97-B9A7E03FA736-- From nobody Tue Mar 25 08:45:05 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2CE1A016E; Tue, 25 Mar 2014 08:44:50 -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 rR0R--Bwrhtn; Tue, 25 Mar 2014 08:44:48 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id A95871A0144; Tue, 25 Mar 2014 08:44:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DC9DB161265; Tue, 25 Mar 2014 08:44:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C7C48161261; Tue, 25 Mar 2014 08:44:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Date: Tue, 25 Mar 2014 16:44:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/8vsuiY47J-crtu8LF33pv5g1UiU Cc: "" , Alia Atlas , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:44:50 -0000 Hello ADs, Directorate, and Chairs, I promise, this is going to be my last mail on this for a bit - it's the = last "topic" that I believe I have queued up in my mind that needs to = get out. I think that WG chairs have a hard job: they need to facilitate = progress, advance the work-items, satisfy the milestones and pressure = from the ADs wanting progress -- and, at the same time -- remain = carefully impartial.=20 Essentially, we want "interested, but disinterested" chairs -- with = enough of stakes in the race to invest the necessary time to see = progress, but who do not have any stakes causing them to favour one = solution/architecture/approach over another. We have some "guidelines" = to this effect (chair-author separation), but this balance has turned = out to remarkably difficult to get right -- and, we have seen things go = haywire by swinging to either side, in the recent and not-so-recent = past. Making this difficult trade-off work may require more active involvement = by the ADs to ensure that chairs recuse when they need to, and step = aside if they become part of the problem. That is not an easy thing to = ask the chairs, who don't have an easy job in some of the working = groups, so the ADs -- in my view -- need to take a more proactive role = in managing the chairs, being alert to potential problems, and affecting = timely corrective actions. Of course, "managing their WG chairs" are already in the job-description = of the ADs, and doing so (well) takes effort and time.=20 Hence, as indicated previously, we should see if we can find a way of = easing some of the load on our ADs so that they have that necessary time = available. Best, Thomas On 21 Mar 2014, at 19:31, Adrian Farrel wrote: > Hello Directorate and WG chairs, >=20 > Alia and I have been discussing the Routing Area, its work, its = output, and its > working groups. >=20 > We have reached a conclusion (which perhaps we should have come to = sooner) that > we need your help and input. >=20 > The crunch question for us is "What makes it hard to get work done in = the > Routing Area?" What gets in the way of your work? What is making life = hard for > document authors? How could working groups be doing better? We are = open to all > and every type of answer. We are happy to have quick, one-line answers = or > deeply-considered essays. >=20 > What do you think?=20 >=20 > Thanks for all your input, > Adrian and Alia >=20 > PS Please respond to both aliases because not everyone is on both = lists. Sorry > that that means some of you will get duplicates. >=20 From nobody Tue Mar 25 10:46:59 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD381A0158; Tue, 25 Mar 2014 10:46:41 -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 Hc43mmJvx1zL; Tue, 25 Mar 2014 10:46:38 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id D6F541A0171; Tue, 25 Mar 2014 10:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 118431623FC; Tue, 25 Mar 2014 10:46:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-57.clppva.east.verizon.net [70.106.134.57]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 498CE162402; Tue, 25 Mar 2014 10:46:36 -0700 (PDT) Message-ID: <5331C0FA.3040008@joelhalpern.com> Date: Tue, 25 Mar 2014 13:46:34 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alia Atlas , Thomas Clausen References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> 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/rtg-dir/fFoK_UUF65q1mpjmb_jtJUXBGnA Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:46:41 -0000 I am a little concerned that assigned directorate members to working groups will produce negative effects: 1) It will lead to more scheduling conflict. 2) It will lead to an assumption that this one person will review all the output of a given WG. I think we are actually better off if that task sometimes moves, as it ensures that fresh eyes are looking, for example to detect that assumptions are actually stated rather than merely in the minds of the WG. Yours, Joel On 3/25/14, 10:58 AM, Alia Atlas wrote: > Thomas, > > Thanks very much for your thoughts. On the being underutilized and on > cross-area review, what do you and others in the Routing Directorate > think about being asked to follow a single additional working group that > is not in RTG and may have routing related issues? > > For the time speedup of ADs, I'm told that it'd be really really useful > to have more active document shepherds - who can facilitate getting > comments and having them addressed. I'm not sure how to put that into > place really. As a WG chair, I felt like I was processing and pushing > few enough drafts that I could do the shepherd job also - but I know > that there are some WGs where there is higher throughput. It's also a > good way of growing a person, to let them see the whole process and deal > with the discussions. > > For the drafts, I'd love to see earlier reviews. I'm not sure if at WG > adoption is quite the right time, but it is a good approximation of > "early in the process". We could ask WG chairs to request a reviewer > at that point for drafts that may need it and see what the load looks > like. For a start-up, having interested WG chairs identify WG drafts > that could benefit from review would be helpful/interesting in terms of > seeing the workload. > > Regards, > Alia > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > > wrote: > > Hello ADs, Directorate, Chairs, > > Interesting questions, thanks for caring and asking. > > I am probably going to cut my answer into separate independent > mails, as there are vastly different topics in this question. > > First, as a member of the RTG Directorate, I actually feel a little > "under-utilized". An occasional review of an I-D at an extremely > late state of its process, and a very rare more global question like > this. As has been discussed widely lately, ADs are overworked and > have too little time, so perhaps they do not call on the directorate > enough - and, also, delegation of tasks that the ADs have to do is > probably perceived as rather hard. > > I've been dumbfounded by some of the reviews I have seen from ADs, > either during AD Evaluation or IESG Reviews: one particular case > came to mind where Adrian sent what looked like a 10-page > DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't > matter what document or WG it was, what matters is that (i) it > doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) > there wasn't really something in the DISCUSS/COMMENTs that required > the wizardry of a yellow dot (just some routing background), and -- > most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during > IESG Evaluation really isn't helpful to the document authors...its > late, design decisions have been made, which are being questioned, > etc....it tires people out, pisses off authors, and frustrates > everybody involved. > > So, I've been playing around with a couple of ideas on the sideline, > unofficially, and with only unwitting assistance from others > involved.... > > Thought #1: > I-Ds - when called for adoption as WG documents, or when published > as draft-ietf-...-00's, gets someone from the directorate assigned, > to provide an initial review and thoughts on "what directions would > be good to take (or avoid) here". That same reviewer can, > occasionally, be invoked by the WG chairs or authors, in the "so, > did we catch this right?" -- and, of course, should be called in on > the WGLC of the document. I think of it a little as the "area > advisors" but to a document rather than a WG as a whole. > > I've been playing around with that a bit, as an author: > > o Since I know very little about security, I've > looped in somebody who did, when > having published a -00, and again the same person > as needed later in the process. > I've gotten hugely valuable feedback - making the > ultimate SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how > little I knew about security, presumably > less frustrating/time-consuming for the ADs, too, > than if I had been just shooting blind). > > o Since I know even less about OPS stuff, Adrian > looped an OPS guy in on an > individual -01, who asked a lot of good questions > to what we were doing, and why, > and which is hugely helpful. > > As an author in the RTG Area, the SEC and OPS ADs are often real > "roadblocks". Reasonably so, of course, they represent important > concerns. And gosh, every time I encounter any AD, I have to explain > the whole context over once again since, even if they've already > gotten the story once, they have to follow sufficiently many > documents and topics that something is bound to be flushed from > their cache. > > Having someone, from the respective directorate, be more of a > facilitator, sparring-partner, and who - over time - follows the > document (and, presumably, follows much fewer documents > concurrently) through the process with the authors would be great, > as an author. And possibly makes the ADs encounter less poor documents. > > I know that Adrian can (cf. the aforementioned 10-page > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS > folks, and I have no reason to not expect Alia to have the same high > (or higher) standards....so I imagine that a way the RTG-DIR could > help "improve the image of the ADs" and at the same time get the ADs > time liberated from writing 10-page discusses, would be something > like the above.... > > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the > directorateS to a document > o this, through the documents lifecycle. > > Not sure if it scales, either, but as an author I've greatly enjoyed > having such a "ongoing relationship" with people helping me avoid > pitfalls. > > A final note: having been around for a while in the IETF, it is > really easy to ask around for help from among other IETFers that one > knows -- then again, having been around for a while, presumably one > has more experience and needs less help in avoiding pitfalls. For a > new(ish) author, who knows few people and who presumably might be > likely to need more help in avoiding said pitfalls, it's a lot > harder to actually reach out and get the right people's eyes on a > document -- and, even to know what eyes are good to get on it. > > This might, actually, therefore be also a good way of the IETF to be > more welcoming and inclusive to new folks wanting to get involved. > > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > version of thought #1 is to have a more structure directorate review > cycle during IETF LC, or perhaps during "Publication Requested" and > before "AD Evaluation". I am thinking that these be of the form: an > I-D hits the AD, the responsible/sponsoring AD requests directorate > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, > TSP, ...). Authors and reviewer iterate until either (i) issues are > squared off or (ii) either authors or reviewer declare the other as > "bat-crap-crazy" (or, complains that the other side is not > responsive) and raise the issue to the AD. AD moves the document > forward to "AD Evaluation" only once happy with the outcome of > directorate reviews. In short, hiving out a lot more of the "problem > fixing" that happens during these reviews off to the directorates - > and leaving ADs to process presumably "less broken" documents. > > As an author, I have actually found it a LOT easier/faster to > iterate with a directorate reviewer (who has my document fresh in > mind), than with an AD who's preoccupied with a dozen or so > documents at the same time, and other emergencies. Now, mind you, > some ADs are good at saying "Busy, will come back to you in n days" > -- others, alas, do "play dead" if they feel they have more > important fish to fry, and that's frustrating. > > This might lessen the load on the ADs, but still has the > disadvantage that one gets feedback *very* late in the > process....just a little bit earlier than during IESG processing. > > Thought #3: > I thought it's worth calling out, that either of the above are not > really related to RTG documents: I should think that RTG WG Chairs > are plenty able to do the necessary during WG processing, and as an > author in the RTG Area, I do usually know how to grab someone > competent from the same area for advice, as needed. While doing > something like this intra-area can be a good thing, the real boast > that I, as document author, have felt has been through getting > cross-area feedback. Just as (being forced to be) reviewing document > outside of the RTG area has been hugely educational and. > > Cheers, > > Thomas > > > On 21 Mar 2014, at 19:31, Adrian Farrel > wrote: > > > Hello Directorate and WG chairs, > > > > Alia and I have been discussing the Routing Area, its work, its > output, and its > > working groups. > > > > We have reached a conclusion (which perhaps we should have come > to sooner) that > > we need your help and input. > > > > The crunch question for us is "What makes it hard to get work > done in the > > Routing Area?" What gets in the way of your work? What is making > life hard for > > document authors? How could working groups be doing better? We > are open to all > > and every type of answer. We are happy to have quick, one-line > answers or > > deeply-considered essays. > > > > What do you think? > > > > Thanks for all your input, > > Adrian and Alia > > > > PS Please respond to both aliases because not everyone is on both > lists. Sorry > > that that means some of you will get duplicates. > > > > From nobody Tue Mar 25 10:49:32 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE651A01B9; Tue, 25 Mar 2014 10:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.31 X-Spam-Level: X-Spam-Status: No, score=-8.31 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, J_CHICKENPOX_22=0.6, J_CHICKENPOX_27=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 JS1E5HIcEmiT; Tue, 25 Mar 2014 10:48:37 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 132311A0171; Tue, 25 Mar 2014 10:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35485; q=dns/txt; s=iport; t=1395769715; x=1396979315; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=ixQokNi5vvGLcclHZu3Kna+TGRcq/v97ToA79nNiitU=; b=Ilt2/xq8AxpVTgMd/IWRWiT83KH6KXRGBrXy/O2Ed4wmd38pxuFKYVfV dohXOKiBknyzlFBXm/pY9pJAhmj/mXRWLiTnrf8Ss2CDkkk/u2PR8pZVX w5LCU1S9dICMhN1utXpKmdisnOj9mDrqfOKT7UkeI0IDNctLGuDkJCgTN 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACTBMVOQ/khL/2dsb2JhbABPCoMGO4k8ugiBHBZ0giUBAQEDARpXAQYBBQsLGAkWAQEGBwkDAgECAQ8lEQYBDAEFAgEBFQWHRwMJCA2yeZUnDYcVF4lCgxCBOgYKAgEuHAUHhDgElmCBbYxohUqDLg X-IronPort-AV: E=Sophos;i="4.97,730,1389744000"; d="scan'208,217";a="6570535" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 25 Mar 2014 17:48:33 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2PHmW29014817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2014 17:48:33 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id s2PHmVnt023218; Tue, 25 Mar 2014 17:48:31 GMT Message-ID: <5331C16F.9090601@cisco.com> Date: Tue, 25 Mar 2014 17:48:31 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Thomas Clausen , Alia Atlas References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000703010006030208020605" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/t1MF6cJKjpAoh1LtEchovCz6BvA Cc: Adrian Farrel , Alia Atlas , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:48:42 -0000 This is a multi-part message in MIME format. --------------000703010006030208020605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thomas If it were not for those directorates the work of some of the ADs would go from difficult to impossible. Remember that whilst a RTG AD can skim a draft and say - "nothing that effects the routing system here - no objection", the OPS, SEC and GEN ADs need to look at pretty much everything in detail. Stewart On 25/03/2014 15:21, Thomas Clausen wrote: > Hello ADs, Directorate and Chairs, > > Oh, and one more thing.....I know, I live a sad life when I realise > that I socialise with IETFers over the weekend, and this email became > the topic of conversation....but, hey... > > This mail thread started out with some folks making proposals on > closing, merging, and moving WGs, which I briefly mentioned as a > discussion-point during the aforementioned conversation - thought I'd > bring the resulting discussion out here. > > The exchange (sanitised for public consumption by removing > swear-words) went roughly like this: > > Me:So the RTG ADs asked for a "health check" of the RTG Area, to the > RTG-WG chairs and RTG-DIR, what > could be done to better the area, make it more efficient, etc. > > Me:Someone suggested that the best was to close and > merge , and perhaps > > IETFer #1 (who has been in the IETF for 5-6 years) interrupted: > That's the F***ING problem with the IETF, all discussions happen > behind closed doors, and we > do not have a say in things. > > IETFer #2 (who's been having an on-again-off-again relationship with > the IETF for a decade or so): > That's the same with all those secret directorates, whose reviews we > now have to contend with, where > did they suddenly come from, secret committees. > > subjects, like the > the existence of extraterrestrials, if mint-jelly really belongs in > a hot meal, if > vegemite qualifies as food,and who should win this years premier > league in football> > > I am not sure that this is RTG-area specific, but it is not the first > time that I have heard someone do a double-take when presented with a > GEN-ART, SEC-DIR, or other such review, or heard of discussions within > such groups, or the existence of such groups. > > Perhaps a root cause of this is, that these groups are seen (like the > IESG) as "roadblocks, not facilitators" because...getting a huge > critical review during an IETF LC is just that...a roadblock. And, > perhaps, getting the directorates more involved much earlier would > also solve such "image problems" of the IETF being an "old-folks-club"? > > Thomas > > > On 25 Mar 2014, at 15:58, Alia Atlas > wrote: > >> Thomas, >> >> Thanks very much for your thoughts. On the being underutilized and >> on cross-area review, what do you and others in the Routing >> Directorate think about being asked to follow a single additional >> working group that is not in RTG and may have routing related issues? >> >> For the time speedup of ADs, I'm told that it'd be really really >> useful to have more active document shepherds - who can facilitate >> getting comments and having them addressed. I'm not sure how to put >> that into place really. As a WG chair, I felt like I was processing >> and pushing few enough drafts that I could do the shepherd job also - >> but I know that there are some WGs where there is higher throughput. >> It's also a good way of growing a person, to let them see the whole >> process and deal with the discussions. >> >> For the drafts, I'd love to see earlier reviews. I'm not sure if at >> WG adoption is quite the right time, but it is a good approximation >> of "early in the process". We could ask WG chairs to request a >> reviewer at that point for drafts that may need it and see what the >> load looks like. For a start-up, having interested WG chairs >> identify WG drafts that could benefit from review would be >> helpful/interesting in terms of seeing the workload. >> >> Regards, >> Alia >> >> >> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen >> > wrote: >> >> Hello ADs, Directorate, Chairs, >> >> Interesting questions, thanks for caring and asking. >> >> I am probably going to cut my answer into separate independent >> mails, as there are vastly different topics in this question. >> >> First, as a member of the RTG Directorate, I actually feel a >> little "under-utilized". An occasional review of an I-D at an >> extremely late state of its process, and a very rare more global >> question like this. As has been discussed widely lately, ADs are >> overworked and have too little time, so perhaps they do not call >> on the directorate enough - and, also, delegation of tasks that >> the ADs have to do is probably perceived as rather hard. >> >> I've been dumbfounded by some of the reviews I have seen from >> ADs, either during AD Evaluation or IESG Reviews: one particular >> case came to mind where Adrian sent what looked like a 10-page >> DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't >> matter what document or WG it was, what matters is that (i) it >> doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, >> (iii) there wasn't really something in the DISCUSS/COMMENTs that >> required the wizardry of a yellow dot (just some routing >> background), and -- most importantly -- (iv) getting a 10-page >> DISCUSS/COMMENT during IESG Evaluation really isn't helpful to >> the document authors...its late, design decisions have been made, >> which are being questioned, etc....it tires people out, pisses >> off authors, and frustrates everybody involved. >> >> So, I've been playing around with a couple of ideas on the >> sideline, unofficially, and with only unwitting assistance from >> others involved.... >> >> Thought #1: >> I-Ds - when called for adoption as WG documents, or when >> published as draft-ietf-...-00's, gets someone from the >> directorate assigned, to provide an initial review and thoughts >> on "what directions would be good to take (or avoid) here". That >> same reviewer can, occasionally, be invoked by the WG chairs or >> authors, in the "so, did we catch this right?" -- and, of course, >> should be called in on the WGLC of the document. I think of it a >> little as the "area advisors" but to a document rather than a WG >> as a whole. >> >> I've been playing around with that a bit, as an author: >> >> o Since I know very little about security, I've >> looped in somebody who did, when >> having published a -00, and again the same person >> as needed later in the process. >> I've gotten hugely valuable feedback - making >> the ultimate SEC-DIR and SEC-AD >> reviews a lot less painful for me (and, given >> how little I knew about security, presumably >> less frustrating/time-consuming for the ADs, >> too, than if I had been just shooting blind). >> >> o Since I know even less about OPS stuff, Adrian >> looped an OPS guy in on an >> individual -01, who asked a lot of good questions >> to what we were doing, and why, >> and which is hugely helpful. >> >> As an author in the RTG Area, the SEC and OPS ADs are often real >> "roadblocks". Reasonably so, of course, they represent important >> concerns. And gosh, every time I encounter any AD, I have to >> explain the whole context over once again since, even if they've >> already gotten the story once, they have to follow sufficiently >> many documents and topics that something is bound to be flushed >> from their cache. >> >> Having someone, from the respective directorate, be more of a >> facilitator, sparring-partner, and who - over time - follows the >> document (and, presumably, follows much fewer documents >> concurrently) through the process with the authors would be >> great, as an author. And possibly makes the ADs encounter less >> poor documents. >> >> I know that Adrian can (cf. the aforementioned 10-page >> DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS >> folks, and I have no reason to not expect Alia to have the same >> high (or higher) standards....so I imagine that a way the RTG-DIR >> could help "improve the image of the ADs" and at the same time >> get the ADs time liberated from writing 10-page discusses, would >> be something like the above.... >> >> In short, what I envision is a structured way of getting: >> o very early-reviews >> o a semi-permanent attachment of a reviewer from >> the directorateS to a document >> o this, through the documents lifecycle. >> >> Not sure if it scales, either, but as an author I've greatly >> enjoyed having such a "ongoing relationship" with people helping >> me avoid pitfalls. >> >> A final note: having been around for a while in the IETF, it is >> really easy to ask around for help from among other IETFers that >> one knows -- then again, having been around for a while, >> presumably one has more experience and needs less help in >> avoiding pitfalls. For a new(ish) author, who knows few people >> and who presumably might be likely to need more help in avoiding >> said pitfalls, it's a lot harder to actually reach out and get >> the right people's eyes on a document -- and, even to know what >> eyes are good to get on it. >> >> This might, actually, therefore be also a good way of the IETF to >> be more welcoming and inclusive to new folks wanting to get involved. >> >> Thought #2: >> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, >> lighter version of thought #1 is to have a more structure >> directorate review cycle during IETF LC, or perhaps during >> "Publication Requested" and before "AD Evaluation". I am thinking >> that these be of the form: an I-D hits the AD, the >> responsible/sponsoring AD requests directorate reviews from all >> the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). >> Authors and reviewer iterate until either (i) issues are squared >> off or (ii) either authors or reviewer declare the other as >> "bat-crap-crazy" (or, complains that the other side is not >> responsive) and raise the issue to the AD. AD moves the document >> forward to "AD Evaluation" only once happy with the outcome of >> directorate reviews. In short, hiving out a lot more of the >> "problem fixing" that happens during these reviews off to the >> directorates - and leaving ADs to process presumably "less >> broken" documents. >> >> As an author, I have actually found it a LOT easier/faster to >> iterate with a directorate reviewer (who has my document fresh in >> mind), than with an AD who's preoccupied with a dozen or so >> documents at the same time, and other emergencies. Now, mind you, >> some ADs are good at saying "Busy, will come back to you in n >> days" -- others, alas, do "play dead" if they feel they have more >> important fish to fry, and that's frustrating. >> >> This might lessen the load on the ADs, but still has the >> disadvantage that one gets feedback *very* late in the >> process....just a little bit earlier than during IESG processing. >> >> Thought #3: >> I thought it's worth calling out, that either of the above are >> not really related to RTG documents: I should think that RTG WG >> Chairs are plenty able to do the necessary during WG processing, >> and as an author in the RTG Area, I do usually know how to grab >> someone competent from the same area for advice, as needed. While >> doing something like this intra-area can be a good thing, the >> real boast that I, as document author, have felt has been through >> getting cross-area feedback. Just as (being forced to be) >> reviewing document outside of the RTG area has been hugely >> educational and. >> >> Cheers, >> >> Thomas >> >> >> On 21 Mar 2014, at 19:31, Adrian Farrel > > wrote: >> >> > Hello Directorate and WG chairs, >> > >> > Alia and I have been discussing the Routing Area, its work, its >> output, and its >> > working groups. >> > >> > We have reached a conclusion (which perhaps we should have come >> to sooner) that >> > we need your help and input. >> > >> > The crunch question for us is "What makes it hard to get work >> done in the >> > Routing Area?" What gets in the way of your work? What is >> making life hard for >> > document authors? How could working groups be doing better? We >> are open to all >> > and every type of answer. We are happy to have quick, one-line >> answers or >> > deeply-considered essays. >> > >> > What do you think? >> > >> > Thanks for all your input, >> > Adrian and Alia >> > >> > PS Please respond to both aliases because not everyone is on >> both lists. Sorry >> > that that means some of you will get duplicates. >> > >> >> > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000703010006030208020605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Thomas

If it were not for those directorates the work of some of the ADs would
go from difficult to impossible. Remember that whilst a RTG AD can skim
a draft and say - "nothing that effects the routing system here - no objection",
the OPS, SEC and GEN ADs need to look at pretty much everything in detail.

Stewart

On 25/03/2014 15:21, Thomas Clausen wrote:
Hello ADs, Directorate and Chairs,

Oh, and one more thing.....I know, I live a sad life when I realise that I socialise with IETFers over the weekend, and this email became the topic of conversation....but, hey...

This mail thread started out with some folks making proposals on closing, merging, and moving WGs, which I briefly mentioned as a discussion-point during the aforementioned conversation - thought I'd bring the resulting discussion out here.

The exchange (sanitised for public consumption by removing swear-words) went roughly like this:

Me: So the RTG ADs asked for a "health check" of the RTG Area, to the RTG-WG chairs and RTG-DIR, what 
could be done to better the area, make it more efficient, etc.

Me: Someone suggested that the best was to close <list-of-wg's> and merge <other-list-of-wg's>, and perhaps

IETFer #1 (who has been in the IETF for 5-6 years) interrupted:
That's  the F***ING problem with the IETF, all discussions happen behind closed doors, and we
do not have a say in things.

IETFer #2 (who's been having an on-again-off-again relationship with the IETF for a decade or so):
That's the same with all those secret directorates, whose reviews we now have to contend with, where
did they suddenly come from, secret committees.

<rant went on for a bit, then we veered into much more consensual subjects, like the 
  the existence of extraterrestrials, if mint-jelly really belongs in a hot meal, if 
  vegemite qualifies as food,and who should win this years premier league in football>

I am not sure that this is RTG-area specific, but it is not the first time that I have heard someone do a double-take when presented with a GEN-ART, SEC-DIR, or other such review, or heard of discussions within such groups, or the existence of such groups. 

Perhaps a root cause of this is, that these groups are seen (like the IESG) as "roadblocks, not facilitators" because...getting a huge critical review during an IETF LC is just that...a roadblock. And, perhaps, getting the directorates more involved much earlier would also solve such "image problems" of the IETF being an "old-folks-club"?

Thomas


On 25 Mar 2014, at 15:58, Alia Atlas <akatlas@gmail.com> wrote:

Thomas,

Thanks very much for your thoughts.  On the being underutilized and on cross-area review, what do you and others in the Routing Directorate think about being asked to follow a single additional working group that is not in RTG and may have routing related issues?

For the time speedup of ADs, I'm told that it'd be really really useful to have more active document shepherds - who can facilitate getting comments and having them addressed.  I'm not sure how to put that into place really.  As a WG chair, I felt like I was processing and pushing few enough drafts that I could do the shepherd job also - but I know that there are some WGs where there is higher throughput.  It's also a good way of growing a person, to let them see the whole process and deal with the discussions.

For the drafts, I'd love to see earlier reviews.  I'm not sure if at WG adoption is quite the right time, but it is a good approximation of "early in the process".   We could ask WG chairs to request a reviewer at that point for drafts that may need it and see what the load looks like.  For a start-up, having interested WG chairs identify WG drafts that could benefit from review would be helpful/interesting in terms of seeing the workload.

Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as there are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "under-utilized". An occasional review of an I-D at an extremely late state of its process, and a very rare more global question like this. As has been discussed widely lately, ADs are overworked and have too little time, so perhaps they do not call on the directorate enough - and, also, delegation of tasks that the ADs have to do is probably perceived as rather hard.

I've been dumbfounded by some of the reviews I have seen from ADs, either during AD Evaluation or IESG Reviews: one particular case came to mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't matter what document or WG it was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some routing background), and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the document authors...its late, design decisions have been made, which are being questioned, etc....it tires people out, pisses off authors, and frustrates everybody involved.

So, I've been playing around with a couple of ideas on the sideline, unofficially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft-ietf-...-00's, gets someone from the directorate assigned, to provide an initial review and thoughts on "what directions would be good to take (or avoid) here". That same reviewer can, occasionally, be invoked by the WG chairs or authors, in the "so, did we catch this right?" -- and, of course, should be called in on the WGLC of the document. I think of it a little as the "area advisors" but to a document rather than a WG as a whole.

I've been playing around with that a bit, as an author:

        o       Since I know very little about security, I've looped in somebody who did, when
                having published a -00, and again the same person as needed later in the process.
                I've gotten  hugely valuable feedback - making the ultimate SEC-DIR and SEC-AD
                reviews a lot  less painful for me (and, given how little I knew about security, presumably
                less  frustrating/time-consuming for the ADs, too, than if I had been just shooting blind).

        o       Since I know even less about OPS stuff, Adrian looped an OPS guy in on an
                individual -01, who asked a lot of good questions to what we were doing, and why,
                and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "roadblocks". Reasonably so, of course, they represent important concerns. And gosh, every time I encounter any AD, I have to explain the whole context over once again since, even if they've already gotten the story once, they have to follow sufficiently many documents and topics that something is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, sparring-partner, and who - over time - follows the document (and, presumably, follows much fewer documents concurrently) through the process with the authors would be great, as an author. And possibly makes the ADs encounter less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, and I have no reason to not expect Alia to have the same high (or higher) standards....so I imagine that a way the RTG-DIR could help "improve the image of the ADs" and at the same time get the ADs time liberated from writing 10-page discusses, would be something like the above....

In short, what I envision is a structured way of getting:
        o       very early-reviews
        o       a semi-permanent attachment of a reviewer from the directorateS to a document
        o       this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed having such a "ongoing relationship" with people helping me avoid pitfalls.

A final note: having been around for a while in the IETF, it is really easy to ask around for help from among other IETFers that one knows -- then again, having been around for a while, presumably one has more experience and needs less help in avoiding pitfalls. For a new(ish) author, who knows few people and who presumably might be likely to need more help in avoiding said pitfalls, it's a lot harder to actually reach out and get the right people's eyes on a document -- and, even to know what eyes are good to get on it.

This might, actually, therefore be also a good way of the IETF to be more welcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version of thought #1 is to have a more structure directorate review cycle during IETF LC, or perhaps during "Publication Requested" and before "AD Evaluation". I am thinking that these be of the form: an I-D hits the AD, the responsible/sponsoring AD requests directorate reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer iterate until either (i) issues are squared off or (ii) either authors or reviewer declare the other as "bat-crap-crazy" (or, complains that the other side is not responsive) and raise the issue to the AD. AD moves the document forward to "AD Evaluation" only once happy with the outcome of directorate reviews. In short, hiving out a lot more of the "problem fixing" that happens during these reviews off to the directorates - and leaving ADs to process presumably "less broken" documents.

As an author, I have actually found it a LOT easier/faster to iterate with a directorate reviewer (who has my document fresh in mind), than with an AD who's preoccupied with a dozen or so documents at the same time, and other emergencies. Now, mind you, some ADs are good at saying "Busy, will come back to you in n days" -- others, alas, do "play dead" if they feel they have more important fish to fry, and that's frustrating.

This might lessen the load on the ADs, but still has the disadvantage that one gets feedback *very* late in the process....just a little bit earlier than during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not really related to RTG documents: I should think that RTG WG Chairs are plenty able to do the necessary during WG processing, and as an author in the RTG Area, I do usually know how to grab someone competent from the same area for advice, as needed. While doing something like this intra-area can be a good thing, the real boast that I, as document author, have felt has been through getting cross-area feedback. Just as (being forced to be) reviewing document outside of the RTG area has been hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its output, and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to sooner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work done in the
> Routing Area?" What gets in the way of your work? What is making life hard for
> document authors? How could working groups be doing better? We are open to all
> and every type of answer. We are happy to have quick, one-line answers or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both lists. Sorry
> that that means some of you will get duplicates.
>





-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000703010006030208020605-- From nobody Tue Mar 25 10:51:36 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8351A0171; Tue, 25 Mar 2014 10:51:15 -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 W8oHYvQ81MHV; Tue, 25 Mar 2014 10:51:11 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 23AC91A0158; Tue, 25 Mar 2014 10:51:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 51699162488; Tue, 25 Mar 2014 10:51:10 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8F7C916248E; Tue, 25 Mar 2014 10:51:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EFEE6D1E-8ECE-4203-8E72-587E07ED970A" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <5331C16F.9090601@cisco.com> Date: Tue, 25 Mar 2014 18:51:03 +0100 Message-Id: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331C16F.9090601@cisco.com> To: Stewart Bryant X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/FW_DfnwJtymoDGjcf9HkKi1D-3k Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" , Alia Atlas Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:51:15 -0000 --Apple-Mail=_EFEE6D1E-8ECE-4203-8E72-587E07ED970A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Stewart, Please don't shoot the messenger.=20 I've grown to love GEN-ART and SEC-DIR and friends -- having had some = darn good people review my docs has helped. I was relaying what I'd seen/heard other people express, and figured = that these entities had an image-problem, rather easy to solve. And yes, you're very very right, the role of a SEC-DIR review is very = very different..... Thomas On 25 Mar 2014, at 18:48, Stewart Bryant wrote: >=20 > Thomas >=20 > If it were not for those directorates the work of some of the ADs = would=20 > go from difficult to impossible. Remember that whilst a RTG AD can = skim > a draft and say - "nothing that effects the routing system here - no = objection", > the OPS, SEC and GEN ADs need to look at pretty much everything in = detail. >=20 > Stewart >=20 > On 25/03/2014 15:21, Thomas Clausen wrote: >> Hello ADs, Directorate and Chairs, >>=20 >> Oh, and one more thing.....I know, I live a sad life when I realise = that I socialise with IETFers over the weekend, and this email became = the topic of conversation....but, hey... >>=20 >> This mail thread started out with some folks making proposals on = closing, merging, and moving WGs, which I briefly mentioned as a = discussion-point during the aforementioned conversation - thought I'd = bring the resulting discussion out here. >>=20 >> The exchange (sanitised for public consumption by removing = swear-words) went roughly like this: >>=20 >> Me: So the RTG ADs asked for a "health check" of the RTG Area, to = the RTG-WG chairs and RTG-DIR, what=20 >> could be done to better the area, make it more efficient, etc. >>=20 >> Me: Someone suggested that the best was to close and = merge , and perhaps >>=20 >> IETFer #1 (who has been in the IETF for 5-6 years) interrupted: >> That's the F***ING problem with the IETF, all discussions happen = behind closed doors, and we >> do not have a say in things. >>=20 >> IETFer #2 (who's been having an on-again-off-again relationship with = the IETF for a decade or so): >> That's the same with all those secret directorates, whose reviews we = now have to contend with, where >> did they suddenly come from, secret committees. >>=20 >> > the existence of extraterrestrials, if mint-jelly really belongs = in a hot meal, if=20 >> vegemite qualifies as food,and who should win this years premier = league in football> >>=20 >> I am not sure that this is RTG-area specific, but it is not the first = time that I have heard someone do a double-take when presented with a = GEN-ART, SEC-DIR, or other such review, or heard of discussions within = such groups, or the existence of such groups.=20 >>=20 >> Perhaps a root cause of this is, that these groups are seen (like the = IESG) as "roadblocks, not facilitators" because...getting a huge = critical review during an IETF LC is just that...a roadblock. And, = perhaps, getting the directorates more involved much earlier would also = solve such "image problems" of the IETF being an "old-folks-club"? >>=20 >> Thomas >>=20 >>=20 >> On 25 Mar 2014, at 15:58, Alia Atlas wrote: >>=20 >>> Thomas, >>>=20 >>> Thanks very much for your thoughts. On the being underutilized and = on cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that = is not in RTG and may have routing related issues? >>>=20 >>> For the time speedup of ADs, I'm told that it'd be really really = useful to have more active document shepherds - who can facilitate = getting comments and having them addressed. I'm not sure how to put = that into place really. As a WG chair, I felt like I was processing and = pushing few enough drafts that I could do the shepherd job also - but I = know that there are some WGs where there is higher throughput. It's = also a good way of growing a person, to let them see the whole process = and deal with the discussions. >>>=20 >>> For the drafts, I'd love to see earlier reviews. I'm not sure if at = WG adoption is quite the right time, but it is a good approximation of = "early in the process". We could ask WG chairs to request a reviewer = at that point for drafts that may need it and see what the load looks = like. For a start-up, having interested WG chairs identify WG drafts = that could benefit from review would be helpful/interesting in terms of = seeing the workload. >>>=20 >>> Regards, >>> Alia >>>=20 >>>=20 >>> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen = wrote: >>> Hello ADs, Directorate, Chairs, >>>=20 >>> Interesting questions, thanks for caring and asking. >>>=20 >>> I am probably going to cut my answer into separate independent = mails, as there are vastly different topics in this question. >>>=20 >>> First, as a member of the RTG Directorate, I actually feel a little = "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As = has been discussed widely lately, ADs are overworked and have too little = time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as = rather hard. >>>=20 >>> I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to = mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the = tracker during IESG Evaluation. It doesn't matter what document or WG it = was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the = DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some = routing background), and -- most importantly -- (iv) getting a 10-page = DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the = document authors...its late, design decisions have been made, which are = being questioned, etc....it tires people out, pisses off authors, and = frustrates everybody involved. >>>=20 >>> So, I've been playing around with a couple of ideas on the sideline, = unofficially, and with only unwitting assistance from others = involved.... >>>=20 >>> Thought #1: >>> I-Ds - when called for adoption as WG documents, or when published = as draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good = to take (or avoid) here". That same reviewer can, occasionally, be = invoked by the WG chairs or authors, in the "so, did we catch this = right?" -- and, of course, should be called in on the WGLC of the = document. I think of it a little as the "area advisors" but to a = document rather than a WG as a whole. >>>=20 >>> I've been playing around with that a bit, as an author: >>>=20 >>> o Since I know very little about security, I've looped = in somebody who did, when >>> having published a -00, and again the same person as = needed later in the process. >>> I've gotten hugely valuable feedback - making the = ultimate SEC-DIR and SEC-AD >>> reviews a lot less painful for me (and, given how = little I knew about security, presumably >>> less frustrating/time-consuming for the ADs, too, = than if I had been just shooting blind). >>>=20 >>> o Since I know even less about OPS stuff, Adrian = looped an OPS guy in on an >>> individual -01, who asked a lot of good questions to = what we were doing, and why, >>> and which is hugely helpful. >>>=20 >>> As an author in the RTG Area, the SEC and OPS ADs are often real = "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the = whole context over once again since, even if they've already gotten the = story once, they have to follow sufficiently many documents and topics = that something is bound to be flushed from their cache. >>>=20 >>> Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the = document (and, presumably, follows much fewer documents concurrently) = through the process with the authors would be great, as an author. And = possibly makes the ADs encounter less poor documents. >>>=20 >>> I know that Adrian can (cf. the aforementioned 10-page = DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, = and I have no reason to not expect Alia to have the same high (or = higher) standards....so I imagine that a way the RTG-DIR could help = "improve the image of the ADs" and at the same time get the ADs time = liberated from writing 10-page discusses, would be something like the = above.... >>>=20 >>> In short, what I envision is a structured way of getting: >>> o very early-reviews >>> o a semi-permanent attachment of a reviewer from the = directorateS to a document >>> o this, through the documents lifecycle. >>>=20 >>> Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid = pitfalls. >>>=20 >>> A final note: having been around for a while in the IETF, it is = really easy to ask around for help from among other IETFers that one = knows -- then again, having been around for a while, presumably one has = more experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it. >>>=20 >>> This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved. >>>=20 >>> Thought #2: >>> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review = cycle during IETF LC, or perhaps during "Publication Requested" and = before "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews = from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). = Authors and reviewer iterate until either (i) issues are squared off or = (ii) either authors or reviewer declare the other as "bat-crap-crazy" = (or, complains that the other side is not responsive) and raise the = issue to the AD. AD moves the document forward to "AD Evaluation" only = once happy with the outcome of directorate reviews. In short, hiving out = a lot more of the "problem fixing" that happens during these reviews off = to the directorates - and leaving ADs to process presumably "less = broken" documents. >>>=20 >>> As an author, I have actually found it a LOT easier/faster to = iterate with a directorate reviewer (who has my document fresh in mind), = than with an AD who's preoccupied with a dozen or so documents at the = same time, and other emergencies. Now, mind you, some ADs are good at = saying "Busy, will come back to you in n days" -- others, alas, do "play = dead" if they feel they have more important fish to fry, and that's = frustrating. >>>=20 >>> This might lessen the load on the ADs, but still has the = disadvantage that one gets feedback *very* late in the process....just a = little bit earlier than during IESG processing. >>>=20 >>> Thought #3: >>> I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are = plenty able to do the necessary during WG processing, and as an author = in the RTG Area, I do usually know how to grab someone competent from = the same area for advice, as needed. While doing something like this = intra-area can be a good thing, the real boast that I, as document = author, have felt has been through getting cross-area feedback. Just as = (being forced to be) reviewing document outside of the RTG area has been = hugely educational and. >>>=20 >>> Cheers, >>>=20 >>> Thomas >>>=20 >>>=20 >>> On 21 Mar 2014, at 19:31, Adrian Farrel wrote: >>>=20 >>> > Hello Directorate and WG chairs, >>> > >>> > Alia and I have been discussing the Routing Area, its work, its = output, and its >>> > working groups. >>> > >>> > We have reached a conclusion (which perhaps we should have come to = sooner) that >>> > we need your help and input. >>> > >>> > The crunch question for us is "What makes it hard to get work done = in the >>> > Routing Area?" What gets in the way of your work? What is making = life hard for >>> > document authors? How could working groups be doing better? We are = open to all >>> > and every type of answer. We are happy to have quick, one-line = answers or >>> > deeply-considered essays. >>> > >>> > What do you think? >>> > >>> > Thanks for all your input, >>> > Adrian and Alia >>> > >>> > PS Please respond to both aliases because not everyone is on both = lists. Sorry >>> > that that means some of you will get duplicates. >>> > >>>=20 >>>=20 >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 --Apple-Mail=_EFEE6D1E-8ECE-4203-8E72-587E07ED970A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Stewart,

Please don't shoot the messenger. 

I've grown to love GEN-ART and SEC-DIR and friends -- having had some darn good people review my docs has helped.

I was relaying what I'd seen/heard other people express, and figured that these entities had an image-problem, rather easy to solve.

And yes, you're very very right, the role of a SEC-DIR review is very very different.....

Thomas

On 25 Mar 2014, at 18:48, Stewart Bryant <stbryant@cisco.com> wrote:


Thomas

If it were not for those directorates the work of some of the ADs would
go from difficult to impossible. Remember that whilst a RTG AD can skim
a draft and say - "nothing that effects the routing system here - no objection",
the OPS, SEC and GEN ADs need to look at pretty much everything in detail.

Stewart

On 25/03/2014 15:21, Thomas Clausen wrote:
Hello ADs, Directorate and Chairs,

Oh, and one more thing.....I know, I live a sad life when I realise that I socialise with IETFers over the weekend, and this email became the topic of conversation....but, hey...

This mail thread started out with some folks making proposals on closing, merging, and moving WGs, which I briefly mentioned as a discussion-point during the aforementioned conversation - thought I'd bring the resulting discussion out here.

The exchange (sanitised for public consumption by removing swear-words) went roughly like this:

Me: So the RTG ADs asked for a "health check" of the RTG Area, to the RTG-WG chairs and RTG-DIR, what 
could be done to better the area, make it more efficient, etc.

Me: Someone suggested that the best was to close <list-of-wg's> and merge <other-list-of-wg's>, and perhaps

IETFer #1 (who has been in the IETF for 5-6 years) interrupted:
That's  the F***ING problem with the IETF, all discussions happen behind closed doors, and we
do not have a say in things.

IETFer #2 (who's been having an on-again-off-again relationship with the IETF for a decade or so):
That's the same with all those secret directorates, whose reviews we now have to contend with, where
did they suddenly come from, secret committees.

<rant went on for a bit, then we veered into much more consensual subjects, like the 
  the existence of extraterrestrials, if mint-jelly really belongs in a hot meal, if 
  vegemite qualifies as food,and who should win this years premier league in football>

I am not sure that this is RTG-area specific, but it is not the first time that I have heard someone do a double-take when presented with a GEN-ART, SEC-DIR, or other such review, or heard of discussions within such groups, or the existence of such groups. 

Perhaps a root cause of this is, that these groups are seen (like the IESG) as "roadblocks, not facilitators" because...getting a huge critical review during an IETF LC is just that...a roadblock. And, perhaps, getting the directorates more involved much earlier would also solve such "image problems" of the IETF being an "old-folks-club"?

Thomas


On 25 Mar 2014, at 15:58, Alia Atlas <akatlas@gmail.com> wrote:

Thomas,

Thanks very much for your thoughts.  On the being underutilized and on cross-area review, what do you and others in the Routing Directorate think about being asked to follow a single additional working group that is not in RTG and may have routing related issues?

For the time speedup of ADs, I'm told that it'd be really really useful to have more active document shepherds - who can facilitate getting comments and having them addressed.  I'm not sure how to put that into place really.  As a WG chair, I felt like I was processing and pushing few enough drafts that I could do the shepherd job also - but I know that there are some WGs where there is higher throughput.  It's also a good way of growing a person, to let them see the whole process and deal with the discussions.

For the drafts, I'd love to see earlier reviews.  I'm not sure if at WG adoption is quite the right time, but it is a good approximation of "early in the process".   We could ask WG chairs to request a reviewer at that point for drafts that may need it and see what the load looks like.  For a start-up, having interested WG chairs identify WG drafts that could benefit from review would be helpful/interesting in terms of seeing the workload.

Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as there are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "under-utilized". An occasional review of an I-D at an extremely late state of its process, and a very rare more global question like this. As has been discussed widely lately, ADs are overworked and have too little time, so perhaps they do not call on the directorate enough - and, also, delegation of tasks that the ADs have to do is probably perceived as rather hard.

I've been dumbfounded by some of the reviews I have seen from ADs, either during AD Evaluation or IESG Reviews: one particular case came to mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't matter what document or WG it was, what matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs that required the wizardry of a yellow dot (just some routing background), and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the document authors...its late, design decisions have been made, which are being questioned, etc....it tires people out, pisses off authors, and frustrates everybody involved.

So, I've been playing around with a couple of ideas on the sideline, unofficially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft-ietf-...-00's, gets someone from the directorate assigned, to provide an initial review and thoughts on "what directions would be good to take (or avoid) here". That same reviewer can, occasionally, be invoked by the WG chairs or authors, in the "so, did we catch this right?" -- and, of course, should be called in on the WGLC of the document. I think of it a little as the "area advisors" but to a document rather than a WG as a whole.

I've been playing around with that a bit, as an author:

        o       Since I know very little about security, I've looped in somebody who did, when
                having published a -00, and again the same person as needed later in the process.
                I've gotten  hugely valuable feedback - making the ultimate SEC-DIR and SEC-AD
                reviews a lot  less painful for me (and, given how little I knew about security, presumably
                less  frustrating/time-consuming for the ADs, too, than if I had been just shooting blind).

        o       Since I know even less about OPS stuff, Adrian looped an OPS guy in on an
                individual -01, who asked a lot of good questions to what we were doing, and why,
                and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "roadblocks". Reasonably so, of course, they represent important concerns. And gosh, every time I encounter any AD, I have to explain the whole context over once again since, even if they've already gotten the story once, they have to follow sufficiently many documents and topics that something is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, sparring-partner, and who - over time - follows the document (and, presumably, follows much fewer documents concurrently) through the process with the authors would be great, as an author. And possibly makes the ADs encounter less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, and I have no reason to not expect Alia to have the same high (or higher) standards....so I imagine that a way the RTG-DIR could help "improve the image of the ADs" and at the same time get the ADs time liberated from writing 10-page discusses, would be something like the above....

In short, what I envision is a structured way of getting:
        o       very early-reviews
        o       a semi-permanent attachment of a reviewer from the directorateS to a document
        o       this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed having such a "ongoing relationship" with people helping me avoid pitfalls.

A final note: having been around for a while in the IETF, it is really easy to ask around for help from among other IETFers that one knows -- then again, having been around for a while, presumably one has more experience and needs less help in avoiding pitfalls. For a new(ish) author, who knows few people and who presumably might be likely to need more help in avoiding said pitfalls, it's a lot harder to actually reach out and get the right people's eyes on a document -- and, even to know what eyes are good to get on it.

This might, actually, therefore be also a good way of the IETF to be more welcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter version of thought #1 is to have a more structure directorate review cycle during IETF LC, or perhaps during "Publication Requested" and before "AD Evaluation". I am thinking that these be of the form: an I-D hits the AD, the responsible/sponsoring AD requests directorate reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer iterate until either (i) issues are squared off or (ii) either authors or reviewer declare the other as "bat-crap-crazy" (or, complains that the other side is not responsive) and raise the issue to the AD. AD moves the document forward to "AD Evaluation" only once happy with the outcome of directorate reviews. In short, hiving out a lot more of the "problem fixing" that happens during these reviews off to the directorates - and leaving ADs to process presumably "less broken" documents.

As an author, I have actually found it a LOT easier/faster to iterate with a directorate reviewer (who has my document fresh in mind), than with an AD who's preoccupied with a dozen or so documents at the same time, and other emergencies. Now, mind you, some ADs are good at saying "Busy, will come back to you in n days" -- others, alas, do "play dead" if they feel they have more important fish to fry, and that's frustrating.

This might lessen the load on the ADs, but still has the disadvantage that one gets feedback *very* late in the process....just a little bit earlier than during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not really related to RTG documents: I should think that RTG WG Chairs are plenty able to do the necessary during WG processing, and as an author in the RTG Area, I do usually know how to grab someone competent from the same area for advice, as needed. While doing something like this intra-area can be a good thing, the real boast that I, as document author, have felt has been through getting cross-area feedback. Just as (being forced to be) reviewing document outside of the RTG area has been hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its output, and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to sooner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work done in the
> Routing Area?" What gets in the way of your work? What is making life hard for
> document authors? How could working groups be doing better? We are open to all
> and every type of answer. We are happy to have quick, one-line answers or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both lists. Sorry
> that that means some of you will get duplicates.
>





-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

--Apple-Mail=_EFEE6D1E-8ECE-4203-8E72-587E07ED970A-- From nobody Tue Mar 25 10:57:27 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0FA1A01E1; Tue, 25 Mar 2014 10:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 D6r-orn3z8Ax; Tue, 25 Mar 2014 10:57:07 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 564251A01B9; Tue, 25 Mar 2014 10:57:07 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3B5D8C2E5; Tue, 25 Mar 2014 13:57:06 -0400 (EDT) Date: Tue, 25 Mar 2014 13:57:06 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140325175706.GK13937@pfrc> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> 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/rtg-dir/3q7tl_JGiRuwif56YrrdOLLsePU Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "rtg-chairs@ietf.org" , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 17:57:08 -0000 On Tue, Mar 25, 2014 at 10:58:34AM -0400, Alia Atlas wrote: > For the drafts, I'd love to see earlier reviews. I'm not sure if at WG > adoption is quite the right time, but it is a good approximation of "early > in the process". We could ask WG chairs to request a reviewer at that > point for drafts that may need it and see what the load looks like. For a > start-up, having interested WG chairs identify WG drafts that could benefit > from review would be helpful/interesting in terms of seeing the workload. If we *really* have reviewers who'll do language level reviews, it may be reasonable to request such review prior to WG adoption. That way the technical issues will also let language nits be resolved rather than having to squish language nits very late. -- Jeff From nobody Tue Mar 25 12:13:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6811A016F; Tue, 25 Mar 2014 12:12:57 -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 FTC9RoF61hdk; Tue, 25 Mar 2014 12:12:52 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1E11A0144; Tue, 25 Mar 2014 12:12:52 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so1011509yhn.0 for ; Tue, 25 Mar 2014 12:12: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=q8xGQCVM9XZaFMDnzG7tXEfeBJh2Dq8zxwm6WhHIhao=; b=AAU4I01W6ezNo07mK0sDKMj3QjX0fOQcbLncGs1f0r/sya1vczq4te+rURxaW5TYNk lMSd2zz7H9OlMMgTN2n4wprvBvV1c83hkocGXtM+9gFwFaWDXtAVaHG5YVFjgRf/d8L/ 9sM1G+HXsAcmwnsX92wjVmw3GToEf72TQd469EW1F4uTUsH5TllWOwmtKFqj/6Dbflyp ASkHX6G88YqZiQht6sgfvfLRBikvW+9Waeae//VPOFyAQJnfmVpRjvifL0o8fD579fn7 iskdJV9GTkFnpR3GB6THmQgwg5dvA5V8DzBVn0YubSlIYW64znex2NWOJ4jOWvWb+NN1 KHNg== MIME-Version: 1.0 X-Received: by 10.236.220.72 with SMTP id n68mr7098594yhp.102.1395774770951; Tue, 25 Mar 2014 12:12:50 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Tue, 25 Mar 2014 12:12:50 -0700 (PDT) In-Reply-To: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Date: Tue, 25 Mar 2014 15:12:50 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=001a11c2bada68d5d904f5732398 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/weVEVak6oVkNsf28PqBX9CwRUB0 Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:12:57 -0000 --001a11c2bada68d5d904f5732398 Content-Type: text/plain; charset=ISO-8859-1 Adrian and I have discussed the need for good early review and follow through of drafts starting with WG adoption. We have also heard that the Routing Directorate could be used more (though the situation may vary by individual). We are writing up the idea of a "Document Mentor". More details to follow (plan for next week) once Adrian and I have agreement on paper for the idea. As far as English language mentoring, it sounds like George, Loa, and Ross have a trial run going in MPLS. We can discuss having common organization for volunteers on each WG's wiki or on the routing-area wiki. Thoughts? Alia On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen wrote: > Alia, > > On 25 Mar 2014, at 15:58, Alia Atlas wrote: > > Thomas, > > Thanks very much for your thoughts. On the being underutilized and on > cross-area review, what do you and others in the Routing Directorate think > about being asked to follow a single additional working group that is not > in RTG and may have routing related issues? > > > Can't speak for the others, but I'd be glad to, personally. > > > For the time speedup of ADs, I'm told that it'd be really really useful to > have more active document shepherds - who can facilitate getting comments > and having them addressed. I'm not sure how to put that into place really. > As a WG chair, I felt like I was processing and pushing few enough drafts > that I could do the shepherd job also - but I know that there are some WGs > where there is higher throughput. It's also a good way of growing a > person, to let them see the whole process and deal with the discussions. > > > That is a good point. Honestly, I do not know, and am really torn on this > issue. > > On one hand, sometimes having a shepherd as "go-between" to whip lazy ADs > ;) or reviewers to come back with "So, did this address your concerns?" > could perhaps be helpful. Oftentimes, however - and this is the "have been > in this for long enough to have many of the ADs on Jabber by now" - the > shepherd is just-another-go-in-the-way: popping an IM to Adrian (or > whoever), getting a resolution, moving on, is a faster way of waking him up > from hibernation than waiting for a third-party to do the same. Same for an > AD holding a discuss, adding an extra intermediary to go through ....not > sold on the idea. > > So, I really do not know what to think about this. In the rare cases where > I have needed some whipping that I couldn't do myself, it has been an AD so > non-responsive that I doubt that a shepherd would do (was a long time ago) > and it required several other ADs ganging up....or (more recently) where > there was an issue with IANA requiring resolution (Adrian helped out there, > but possibly somebody else could have, too). > > For the drafts, I'd love to see earlier reviews. I'm not sure if at WG > adoption is quite the right time, but it is a good approximation of "early > in the process". > > > I agree. It was just the least-arbitrary version number I could come up > with on short notice ;) > > We could ask WG chairs to request a reviewer at that point for drafts that > may need it and see what the load looks like. For a start-up, having > interested WG chairs identify WG drafts that could benefit from review > would be helpful/interesting in terms of seeing the workload. > > > Can't disagree on this. > > Thomas > > > Regards, > Alia > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > wrote: > >> Hello ADs, Directorate, Chairs, >> >> Interesting questions, thanks for caring and asking. >> >> I am probably going to cut my answer into separate independent mails, as >> there are vastly different topics in this question. >> >> First, as a member of the RTG Directorate, I actually feel a little >> "under-utilized". An occasional review of an I-D at an extremely late state >> of its process, and a very rare more global question like this. As has been >> discussed widely lately, ADs are overworked and have too little time, so >> perhaps they do not call on the directorate enough - and, also, delegation >> of tasks that the ADs have to do is probably perceived as rather hard. >> >> I've been dumbfounded by some of the reviews I have seen from ADs, either >> during AD Evaluation or IESG Reviews: one particular case came to mind >> where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker >> during IESG Evaluation. It doesn't matter what document or WG it was, what >> matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of >> Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs >> that required the wizardry of a yellow dot (just some routing background), >> and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during >> IESG Evaluation really isn't helpful to the document authors...its late, >> design decisions have been made, which are being questioned, etc....it >> tires people out, pisses off authors, and frustrates everybody involved. >> >> So, I've been playing around with a couple of ideas on the sideline, >> unofficially, and with only unwitting assistance from others involved.... >> >> Thought #1: >> I-Ds - when called for adoption as WG documents, or when published as >> draft-ietf-...-00's, gets someone from the directorate assigned, to provide >> an initial review and thoughts on "what directions would be good to take >> (or avoid) here". That same reviewer can, occasionally, be invoked by the >> WG chairs or authors, in the "so, did we catch this right?" -- and, of >> course, should be called in on the WGLC of the document. I think of it a >> little as the "area advisors" but to a document rather than a WG as a whole. >> >> I've been playing around with that a bit, as an author: >> >> o Since I know very little about security, I've looped in >> somebody who did, when >> having published a -00, and again the same person as >> needed later in the process. >> I've gotten hugely valuable feedback - making the >> ultimate SEC-DIR and SEC-AD >> reviews a lot less painful for me (and, given how little >> I knew about security, presumably >> less frustrating/time-consuming for the ADs, too, than >> if I had been just shooting blind). >> >> o Since I know even less about OPS stuff, Adrian looped an >> OPS guy in on an >> individual -01, who asked a lot of good questions to what >> we were doing, and why, >> and which is hugely helpful. >> >> As an author in the RTG Area, the SEC and OPS ADs are often real >> "roadblocks". Reasonably so, of course, they represent important concerns. >> And gosh, every time I encounter any AD, I have to explain the whole >> context over once again since, even if they've already gotten the story >> once, they have to follow sufficiently many documents and topics that >> something is bound to be flushed from their cache. >> >> Having someone, from the respective directorate, be more of a >> facilitator, sparring-partner, and who - over time - follows the document >> (and, presumably, follows much fewer documents concurrently) through the >> process with the authors would be great, as an author. And possibly makes >> the ADs encounter less poor documents. >> >> I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) >> be just as much of a roadblock as the SEC/OPS folks, and I have no reason >> to not expect Alia to have the same high (or higher) standards....so I >> imagine that a way the RTG-DIR could help "improve the image of the ADs" >> and at the same time get the ADs time liberated from writing 10-page >> discusses, would be something like the above.... >> >> In short, what I envision is a structured way of getting: >> o very early-reviews >> o a semi-permanent attachment of a reviewer from the >> directorateS to a document >> o this, through the documents lifecycle. >> >> Not sure if it scales, either, but as an author I've greatly enjoyed >> having such a "ongoing relationship" with people helping me avoid pitfalls. >> >> A final note: having been around for a while in the IETF, it is really >> easy to ask around for help from among other IETFers that one knows -- then >> again, having been around for a while, presumably one has more experience >> and needs less help in avoiding pitfalls. For a new(ish) author, who knows >> few people and who presumably might be likely to need more help in avoiding >> said pitfalls, it's a lot harder to actually reach out and get the right >> people's eyes on a document -- and, even to know what eyes are good to get >> on it. >> >> This might, actually, therefore be also a good way of the IETF to be more >> welcoming and inclusive to new folks wanting to get involved. >> >> Thought #2: >> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter >> version of thought #1 is to have a more structure directorate review cycle >> during IETF LC, or perhaps during "Publication Requested" and before "AD >> Evaluation". I am thinking that these be of the form: an I-D hits the AD, >> the responsible/sponsoring AD requests directorate reviews from all the >> concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer >> iterate until either (i) issues are squared off or (ii) either authors or >> reviewer declare the other as "bat-crap-crazy" (or, complains that the >> other side is not responsive) and raise the issue to the AD. AD moves the >> document forward to "AD Evaluation" only once happy with the outcome of >> directorate reviews. In short, hiving out a lot more of the "problem >> fixing" that happens during these reviews off to the directorates - and >> leaving ADs to process presumably "less broken" documents. >> >> As an author, I have actually found it a LOT easier/faster to iterate >> with a directorate reviewer (who has my document fresh in mind), than with >> an AD who's preoccupied with a dozen or so documents at the same time, and >> other emergencies. Now, mind you, some ADs are good at saying "Busy, will >> come back to you in n days" -- others, alas, do "play dead" if they feel >> they have more important fish to fry, and that's frustrating. >> >> This might lessen the load on the ADs, but still has the disadvantage >> that one gets feedback *very* late in the process....just a little bit >> earlier than during IESG processing. >> >> Thought #3: >> I thought it's worth calling out, that either of the above are not really >> related to RTG documents: I should think that RTG WG Chairs are plenty able >> to do the necessary during WG processing, and as an author in the RTG Area, >> I do usually know how to grab someone competent from the same area for >> advice, as needed. While doing something like this intra-area can be a good >> thing, the real boast that I, as document author, have felt has been >> through getting cross-area feedback. Just as (being forced to be) reviewing >> document outside of the RTG area has been hugely educational and. >> >> Cheers, >> >> Thomas >> >> >> On 21 Mar 2014, at 19:31, Adrian Farrel wrote: >> >> > Hello Directorate and WG chairs, >> > >> > Alia and I have been discussing the Routing Area, its work, its output, >> and its >> > working groups. >> > >> > We have reached a conclusion (which perhaps we should have come to >> sooner) that >> > we need your help and input. >> > >> > The crunch question for us is "What makes it hard to get work done in >> the >> > Routing Area?" What gets in the way of your work? What is making life >> hard for >> > document authors? How could working groups be doing better? We are open >> to all >> > and every type of answer. We are happy to have quick, one-line answers >> or >> > deeply-considered essays. >> > >> > What do you think? >> > >> > Thanks for all your input, >> > Adrian and Alia >> > >> > PS Please respond to both aliases because not everyone is on both >> lists. Sorry >> > that that means some of you will get duplicates. >> > >> >> > > --001a11c2bada68d5d904f5732398 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian and I have discussed the need for good early review= and follow through of drafts starting with
WG adoption. =A0We have als= o heard that the Routing Directorate could be used more (though the situati= on may
vary by individual).

We are writing up the id= ea of a "Document Mentor". =A0 More details to follow (plan for n= ext week) once Adrian
and I have agreement on paper for the idea.=

As far as English language mentoring, it sounds like Ge= orge, Loa, and Ross have a trial run going in MPLS.
We can discus= s having common organization for volunteers on each WG's wiki or on the= routing-area wiki.

Thoughts?

Alia


On Tue, Mar 25, 2= 014 at 11:09 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:
Alia,
On 25 Mar 2014, at 15:58, Alia Atlas <akatlas@gmail.com&= gt; wrote:

Thomas,

T= hanks very much for your thoughts. =A0On the being underutilized and on cro= ss-area review, what do you and others in the Routing Directorate think abo= ut being asked to follow a single additional working group that is not in R= TG and may have routing related issues?

Can't speak for the others, but= I'd be glad to, personally.


For the time speedup of ADs, I'm told that it'd= be really really useful to have more active document shepherds - who can f= acilitate getting comments and having them addressed. =A0I'm not sure h= ow to put that into place really. =A0As a WG chair, I felt like I was proce= ssing and pushing few enough drafts that I could do the shepherd job also -= but I know that there are some WGs where there is higher throughput. =A0It= 's also a good way of growing a person, to let them see the whole proce= ss and deal with the discussions.

That is a good point. Honestly, I d= o not know, and am really torn on this issue.

On o= ne hand, sometimes having a shepherd as "go-between" to whip lazy= ADs ;) or reviewers to come back with "So, did this address your conc= erns?" could perhaps be helpful. Oftentimes, however - and this is the= "have been in this for long enough to have many of the ADs on Jabber = by now" - the shepherd is just-another-go-in-the-way: popping an IM to= Adrian (or whoever), getting a resolution, moving on, is a faster way of w= aking him up from hibernation than waiting for a third-party to do the same= . Same for an AD holding a discuss, adding an extra intermediary to go thro= ugh ....not sold on the idea.

So, I really do not know what to think about this. In t= he rare cases where I have needed some whipping that I couldn't do myse= lf, it has been an AD so non-responsive that I doubt that a shepherd would = do (was a long time ago) and it required several other ADs ganging up....or= (more recently) where there was an issue with IANA requiring resolution (A= drian helped out there, but possibly somebody else could have, too).

Fo= r the drafts, I'd love to see earlier reviews. =A0I'm not sure if a= t WG adoption is quite the right time, but it is a good approximation of &q= uot;early in the process". =A0

I agree. It was just the least= -arbitrary version number I could come up with on short notice ;)

We could a= sk WG chairs to request a reviewer at that point for drafts that may need i= t and see what the load looks like. =A0For a start-up, having interested WG= chairs identify WG drafts that could benefit from review would be helpful/= interesting in terms of seeing the workload.

Can't disagree on this.

Thoma= s


Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM,= Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as th= ere are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "u= nder-utilized". An occasional review of an I-D at an extremely late st= ate of its process, and a very rare more global question like this. As has = been discussed widely lately, ADs are overworked and have too little time, = so perhaps they do not call on the directorate enough - and, also, delegati= on of tasks that the ADs have to do is probably perceived as rather hard.
I've been dumbfounded by some of the reviews I have seen from ADs, eith= er during AD Evaluation or IESG Reviews: one particular case came to mind w= here Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker = during IESG Evaluation. It doesn't matter what document or WG it was, w= hat matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the DI= SCUSS/COMMENTs that required the wizardry of a yellow dot (just some routin= g background), and -- most importantly -- (iv) getting a 10-page DISCUSS/CO= MMENT during IESG Evaluation really isn't helpful to the document autho= rs...its late, design decisions have been made, which are being questioned,= etc....it tires people out, pisses off authors, and frustrates everybody i= nvolved.

So, I've been playing around with a couple of ideas on the sideline, un= officially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft= -ietf-...-00's, gets someone from the directorate assigned, to provide = an initial review and thoughts on "what directions would be good to ta= ke (or avoid) here". That same reviewer can, occasionally, be invoked = by the WG chairs or authors, in the "so, did we catch this right?"= ; -- and, of course, should be called in on the WGLC of the document. I thi= nk of it a little as the "area advisors" but to a document rather= than a WG as a whole.

I've been playing around with that a bit, as an author:

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 Since I know very little about security, I= 9;ve looped in somebody who did, when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 having published a -00, and again the same = person as needed later in the process.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I've gotten =A0hugely valuable feedback= - making the ultimate SEC-DIR and SEC-AD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reviews a lot =A0less painful for me (and, = given how little I knew about security, presumably
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 less =A0frustrating/time-consuming for the = ADs, too, than if I had been just shooting blind).

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 Since I know even less about OPS stuff, Adria= n looped an OPS guy in on an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 individual -01, who asked a lot of good que= stions to what we were doing, and why,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "road= blocks". Reasonably so, of course, they represent important concerns. = And gosh, every time I encounter any AD, I have to explain the whole contex= t over once again since, even if they've already gotten the story once,= they have to follow sufficiently many documents and topics that something = is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, = sparring-partner, and who - over time - follows the document (and, presumab= ly, follows much fewer documents concurrently) through the process with the= authors would be great, as an author. And possibly makes the ADs encounter= less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be = just as much of a roadblock as the SEC/OPS folks, and I have no reason to n= ot expect Alia to have the same high (or higher) standards....so I imagine = that a way the RTG-DIR could help "improve the image of the ADs" = and at the same time get the ADs time liberated from writing 10-page discus= ses, would be something like the above....

In short, what I envision is a structured way of getting:
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 very early-reviews
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 a semi-permanent attachment of a reviewer fro= m the directorateS to a document
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed ha= ving such a "ongoing relationship" with people helping me avoid p= itfalls.

A final note: having been around for a while in the IETF, it is really easy= to ask around for help from among other IETFers that one knows -- then aga= in, having been around for a while, presumably one has more experience and = needs less help in avoiding pitfalls. For a new(ish) author, who knows few = people and who presumably might be likely to need more help in avoiding sai= d pitfalls, it's a lot harder to actually reach out and get the right p= eople's eyes on a document -- and, even to know what eyes are good to g= et on it.

This might, actually, therefore be also a good way of the IETF to be more w= elcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter vers= ion of thought #1 is to have a more structure directorate review cycle duri= ng IETF LC, or perhaps during "Publication Requested" and before = "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews fro= m all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors an= d reviewer iterate until either (i) issues are squared off or (ii) either a= uthors or reviewer declare the other as "bat-crap-crazy" (or, com= plains that the other side is not responsive) and raise the issue to the AD= . AD moves the document forward to "AD Evaluation" only once happ= y with the outcome of directorate reviews. In short, hiving out a lot more = of the "problem fixing" that happens during these reviews off to = the directorates - and leaving ADs to process presumably "less broken&= quot; documents.

As an author, I have actually found it a LOT easier/faster to iterate with = a directorate reviewer (who has my document fresh in mind), than with an AD= who's preoccupied with a dozen or so documents at the same time, and o= ther emergencies. Now, mind you, some ADs are good at saying "Busy, wi= ll come back to you in n days" -- others, alas, do "play dead&quo= t; if they feel they have more important fish to fry, and that's frustr= ating.

This might lessen the load on the ADs, but still has the disadvantage that = one gets feedback *very* late in the process....just a little bit earlier t= han during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not real= ly related to RTG documents: I should think that RTG WG Chairs are plenty a= ble to do the necessary during WG processing, and as an author in the RTG A= rea, I do usually know how to grab someone competent from the same area for= advice, as needed. While doing something like this intra-area can be a goo= d thing, the real boast that I, as document author, have felt has been thro= ugh getting cross-area feedback. Just as (being forced to be) reviewing doc= ument outside of the RTG area has been hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its output= , and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to soo= ner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work don= e in the
> Routing Area?" What gets in the way of your work? What is making = life hard for
> document authors? How could working groups be doing better? We are ope= n to all
> and every type of answer. We are happy to have quick, one-line answers= or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both list= s. Sorry
> that that means some of you will get duplicates.
>




 --001a11c2bada68d5d904f5732398-- From nobody Tue Mar 25 12:23:24 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8011A01DC for ; Tue, 25 Mar 2014 12:23:00 -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 D3nWUOT8x9P5 for ; Tue, 25 Mar 2014 12:22:56 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) by ietfa.amsl.com (Postfix) with SMTP id 04FDB1A01EC for ; Tue, 25 Mar 2014 12:22:55 -0700 (PDT) Received: (qmail 15650 invoked by uid 0); 25 Mar 2014 19:22:54 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy3.mail.unifiedlayer.com with SMTP; 25 Mar 2014 19:22:54 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id i2Nn1n00Q2SSUrH012Nqdp; Tue, 25 Mar 2014 20:22:53 -0600 X-Authority-Analysis: v=2.1 cv=L+eOHYj8 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=Tvs_GUuyyx4A:10 a=WspU9PCzxMAA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=sa-A9YEWRNkUT_MTyG8A: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=8wNFnynZ9Apt/lJRcwoGA5XJrWWNLQOgtVP5/Be38/U=; b=hrABOekUh8p72s+ZNdGmkqr5OP5eRGSpDD8XMTwVnKM7AofH4lzSlpjfSIf5g0Z8+SZIy8tOJF1ix9zGGz6HDkqIxvNHRGciZgx6DY02ayKNo58gkqwzkXoP6TJiMZCQ; Received: from box313.bluehost.com ([69.89.31.113]:44764 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WSWvw-0006aX-LR; Tue, 25 Mar 2014 13:22:48 -0600 Message-ID: <5331D785.5030800@labn.net> Date: Tue, 25 Mar 2014 15:22:45 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alia Atlas References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> 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/rtg-dir/h37NrvTMzPNoeXPeCUMVdU_G4jE Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:23:01 -0000 On 3/25/2014 3:12 PM, Alia Atlas wrote: > As far as English language mentoring, it sounds like George, Loa, and > Ross have a trial run going in MPLS. > We can discuss having common organization for volunteers on each WG's > wiki or on the routing-area wiki. > > Thoughts? > I think language review would be *hugely* helpful. Personally I'd like it to occur right *after* WG adoption and once again after the authors declare a document ready for LC (from the technical perspective). Lou From nobody Tue Mar 25 12:28:43 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F74D1A0198; Tue, 25 Mar 2014 12:28:25 -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_21=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 BQmGkpftX3QQ; Tue, 25 Mar 2014 12:28:22 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B899E1A0157; Tue, 25 Mar 2014 12:28:21 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 200so2407501ykr.3 for ; Tue, 25 Mar 2014 12:28:20 -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=oEy1e88oHMRHh7rhrRYnRcPiS6B/0qGTCBUXTPA8B7k=; b=pf/s2VORQyuBjWH5Wr4SOikxvXoWXDP2evGVrNyr2EMv/wGQKTs28heYbKxebLdaDX QThIhYw30rF7GRIRI56bcUhXAFH10Rtyuho27U2Y8E+2EBgRVIwdcGPPySjuJwKbEex6 oigbDgK53Hi6RnHrRxrP6qGHJk4t3BjPXyEO1Fy0Ee7KpUstH8VpcC2RVJ56hnkT67P/ o8lIcGNkDS0SRTrn7MSDfpKSRVhQDVIlH/2n19K2M6GlQ8KV5s0dHaIEyuvenlYI8m9m 0oaPonIY56PEIYCD9TtWsuF9CqoX8YkHHxGBahMytUogP4aZUcm8cPN1BzTIAQrgy9Rp 3HVA== MIME-Version: 1.0 X-Received: by 10.236.150.205 with SMTP id z53mr76379618yhj.75.1395775700419; Tue, 25 Mar 2014 12:28:20 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Tue, 25 Mar 2014 12:28:20 -0700 (PDT) In-Reply-To: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> Date: Tue, 25 Mar 2014 15:28:20 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=20cf303a2d61cf4a9a04f5735a06 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/mdfFRKbbUCmL6Aje0NKb8y5zWgg Cc: Adrian Farrel , "rtg-chairs@ietf.org" , Alia Atlas , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:28:25 -0000 --20cf303a2d61cf4a9a04f5735a06 Content-Type: text/plain; charset=ISO-8859-1 Hi Thomas, On Tue, Mar 25, 2014 at 11:21 AM, Thomas Clausen wrote: > Hello ADs, Directorate and Chairs, > > Oh, and one more thing.....I know, I live a sad life when I realise that I > socialise with IETFers over the weekend, and this email became the topic of > conversation....but, hey... > Not that sad... or maybe this just sounds familiar... > This mail thread started out with some folks making proposals on closing, > merging, and moving WGs, which I briefly mentioned as a discussion-point > during the aforementioned conversation - thought I'd bring the resulting > discussion out here. > > The exchange (sanitised for public consumption by removing swear-words) > went roughly like this: > > Me: So the RTG ADs asked for a "health check" of the RTG Area, to the > RTG-WG chairs and RTG-DIR, what > could be done to better the area, make it more efficient, etc. > > Me: Someone suggested that the best was to close and merge > , and perhaps > > IETFer #1 (who has been in the IETF for 5-6 years) interrupted: > That's the F***ING problem with the IETF, all discussions happen behind > closed doors, and we > do not have a say in things. > *sigh* A directorate is "just" a group of people whose opinion is trusted by the ADs and who have agreed to do work to help the area, such as requested reviews. As you (of course) well know, anyone can do the reviews. There are multiple steps to developing a plan. The WG chairs and rtg-dir have valuable and diverse perspectives into the routing area. Other participants do too - but it can be harder to have a completely unstructured and yet productive discussion. I certainly intend to discuss and ask for feedback and advice from the area, but at the end of the day, it is advice. If your friend has opinions that she/he would like to share, I'm happy to listen. > IETFer #2 (who's been having an on-again-off-again relationship with the > IETF for a decade or so): > That's the same with all those secret directorates, whose reviews we now > have to contend with, where > did they suddenly come from, secret committees. > Interestingly, they've been around for at least the last 12+ years. And, just like the IETF, IAB, and IESG being "secret" cabals, just because one doesn't know about them doesn't make them secret. There is, of course, the Routing Area wiki (http://wiki.tools.ietf.org/area/rtg/trac/wiki) and the Routing Directorate is linked to there as: https://www.ietf.org/iesg/directorate/routing.html > subjects, like the > the existence of extraterrestrials, if mint-jelly really belongs in a > hot meal, if > vegemite qualifies as food,and who should win this years premier league > in football> > > I am not sure that this is RTG-area specific, but it is not the first time > that I have heard someone do a double-take when presented with a GEN-ART, > SEC-DIR, or other such review, or heard of discussions within such groups, > or the existence of such groups. > > Perhaps a root cause of this is, that these groups are seen (like the > IESG) as "roadblocks, not facilitators" because...getting a huge critical > review during an IETF LC is just that...a roadblock. And, perhaps, getting > the directorates more involved much earlier would also solve such "image > problems" of the IETF being an "old-folks-club"? > I think the double-take is because, for a document author, each document and the process is lovingly hand-crafted. From the AD perspective, these reviews are a well known part of the process and we'e trying to figure out how to churn out better docs with less back-loading. As for an "old-folks-club", is that over 25, 30, 40, 50? The IETF does tend to be reputation-based, but it is possible to come in and do lots of very good work quickly and gain that reputation. Any group with people forms networks of trust and they all look like insider clubs to those not involved. I'm not sure how to fix that... Regards, Alia > Thomas > > > On 25 Mar 2014, at 15:58, Alia Atlas wrote: > > Thomas, > > Thanks very much for your thoughts. On the being underutilized and on > cross-area review, what do you and others in the Routing Directorate think > about being asked to follow a single additional working group that is not > in RTG and may have routing related issues? > > For the time speedup of ADs, I'm told that it'd be really really useful to > have more active document shepherds - who can facilitate getting comments > and having them addressed. I'm not sure how to put that into place really. > As a WG chair, I felt like I was processing and pushing few enough drafts > that I could do the shepherd job also - but I know that there are some WGs > where there is higher throughput. It's also a good way of growing a > person, to let them see the whole process and deal with the discussions. > > For the drafts, I'd love to see earlier reviews. I'm not sure if at WG > adoption is quite the right time, but it is a good approximation of "early > in the process". We could ask WG chairs to request a reviewer at that > point for drafts that may need it and see what the load looks like. For a > start-up, having interested WG chairs identify WG drafts that could benefit > from review would be helpful/interesting in terms of seeing the workload. > > Regards, > Alia > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > wrote: > >> Hello ADs, Directorate, Chairs, >> >> Interesting questions, thanks for caring and asking. >> >> I am probably going to cut my answer into separate independent mails, as >> there are vastly different topics in this question. >> >> First, as a member of the RTG Directorate, I actually feel a little >> "under-utilized". An occasional review of an I-D at an extremely late state >> of its process, and a very rare more global question like this. As has been >> discussed widely lately, ADs are overworked and have too little time, so >> perhaps they do not call on the directorate enough - and, also, delegation >> of tasks that the ADs have to do is probably perceived as rather hard. >> >> I've been dumbfounded by some of the reviews I have seen from ADs, either >> during AD Evaluation or IESG Reviews: one particular case came to mind >> where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker >> during IESG Evaluation. It doesn't matter what document or WG it was, what >> matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of >> Adrian's time, (iii) there wasn't really something in the DISCUSS/COMMENTs >> that required the wizardry of a yellow dot (just some routing background), >> and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during >> IESG Evaluation really isn't helpful to the document authors...its late, >> design decisions have been made, which are being questioned, etc....it >> tires people out, pisses off authors, and frustrates everybody involved. >> >> So, I've been playing around with a couple of ideas on the sideline, >> unofficially, and with only unwitting assistance from others involved.... >> >> Thought #1: >> I-Ds - when called for adoption as WG documents, or when published as >> draft-ietf-...-00's, gets someone from the directorate assigned, to provide >> an initial review and thoughts on "what directions would be good to take >> (or avoid) here". That same reviewer can, occasionally, be invoked by the >> WG chairs or authors, in the "so, did we catch this right?" -- and, of >> course, should be called in on the WGLC of the document. I think of it a >> little as the "area advisors" but to a document rather than a WG as a whole. >> >> I've been playing around with that a bit, as an author: >> >> o Since I know very little about security, I've looped in >> somebody who did, when >> having published a -00, and again the same person as >> needed later in the process. >> I've gotten hugely valuable feedback - making the >> ultimate SEC-DIR and SEC-AD >> reviews a lot less painful for me (and, given how little >> I knew about security, presumably >> less frustrating/time-consuming for the ADs, too, than >> if I had been just shooting blind). >> >> o Since I know even less about OPS stuff, Adrian looped an >> OPS guy in on an >> individual -01, who asked a lot of good questions to what >> we were doing, and why, >> and which is hugely helpful. >> >> As an author in the RTG Area, the SEC and OPS ADs are often real >> "roadblocks". Reasonably so, of course, they represent important concerns. >> And gosh, every time I encounter any AD, I have to explain the whole >> context over once again since, even if they've already gotten the story >> once, they have to follow sufficiently many documents and topics that >> something is bound to be flushed from their cache. >> >> Having someone, from the respective directorate, be more of a >> facilitator, sparring-partner, and who - over time - follows the document >> (and, presumably, follows much fewer documents concurrently) through the >> process with the authors would be great, as an author. And possibly makes >> the ADs encounter less poor documents. >> >> I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) >> be just as much of a roadblock as the SEC/OPS folks, and I have no reason >> to not expect Alia to have the same high (or higher) standards....so I >> imagine that a way the RTG-DIR could help "improve the image of the ADs" >> and at the same time get the ADs time liberated from writing 10-page >> discusses, would be something like the above.... >> >> In short, what I envision is a structured way of getting: >> o very early-reviews >> o a semi-permanent attachment of a reviewer from the >> directorateS to a document >> o this, through the documents lifecycle. >> >> Not sure if it scales, either, but as an author I've greatly enjoyed >> having such a "ongoing relationship" with people helping me avoid pitfalls. >> >> A final note: having been around for a while in the IETF, it is really >> easy to ask around for help from among other IETFers that one knows -- then >> again, having been around for a while, presumably one has more experience >> and needs less help in avoiding pitfalls. For a new(ish) author, who knows >> few people and who presumably might be likely to need more help in avoiding >> said pitfalls, it's a lot harder to actually reach out and get the right >> people's eyes on a document -- and, even to know what eyes are good to get >> on it. >> >> This might, actually, therefore be also a good way of the IETF to be more >> welcoming and inclusive to new folks wanting to get involved. >> >> Thought #2: >> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter >> version of thought #1 is to have a more structure directorate review cycle >> during IETF LC, or perhaps during "Publication Requested" and before "AD >> Evaluation". I am thinking that these be of the form: an I-D hits the AD, >> the responsible/sponsoring AD requests directorate reviews from all the >> concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and reviewer >> iterate until either (i) issues are squared off or (ii) either authors or >> reviewer declare the other as "bat-crap-crazy" (or, complains that the >> other side is not responsive) and raise the issue to the AD. AD moves the >> document forward to "AD Evaluation" only once happy with the outcome of >> directorate reviews. In short, hiving out a lot more of the "problem >> fixing" that happens during these reviews off to the directorates - and >> leaving ADs to process presumably "less broken" documents. >> >> As an author, I have actually found it a LOT easier/faster to iterate >> with a directorate reviewer (who has my document fresh in mind), than with >> an AD who's preoccupied with a dozen or so documents at the same time, and >> other emergencies. Now, mind you, some ADs are good at saying "Busy, will >> come back to you in n days" -- others, alas, do "play dead" if they feel >> they have more important fish to fry, and that's frustrating. >> >> This might lessen the load on the ADs, but still has the disadvantage >> that one gets feedback *very* late in the process....just a little bit >> earlier than during IESG processing. >> >> Thought #3: >> I thought it's worth calling out, that either of the above are not really >> related to RTG documents: I should think that RTG WG Chairs are plenty able >> to do the necessary during WG processing, and as an author in the RTG Area, >> I do usually know how to grab someone competent from the same area for >> advice, as needed. While doing something like this intra-area can be a good >> thing, the real boast that I, as document author, have felt has been >> through getting cross-area feedback. Just as (being forced to be) reviewing >> document outside of the RTG area has been hugely educational and. >> >> Cheers, >> >> Thomas >> >> >> On 21 Mar 2014, at 19:31, Adrian Farrel wrote: >> >> > Hello Directorate and WG chairs, >> > >> > Alia and I have been discussing the Routing Area, its work, its output, >> and its >> > working groups. >> > >> > We have reached a conclusion (which perhaps we should have come to >> sooner) that >> > we need your help and input. >> > >> > The crunch question for us is "What makes it hard to get work done in >> the >> > Routing Area?" What gets in the way of your work? What is making life >> hard for >> > document authors? How could working groups be doing better? We are open >> to all >> > and every type of answer. We are happy to have quick, one-line answers >> or >> > deeply-considered essays. >> > >> > What do you think? >> > >> > Thanks for all your input, >> > Adrian and Alia >> > >> > PS Please respond to both aliases because not everyone is on both >> lists. Sorry >> > that that means some of you will get duplicates. >> > >> >> > > --20cf303a2d61cf4a9a04f5735a06 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Thomas,

On Tue, Mar 25, 2014 at 11:21 AM, Thomas Clausen <tho= mas@thomasclausen.org> wrote:
Hello ADs, Direct= orate and Chairs,

Oh, and one more thing.....I know, I live a sad life wh= en I realise that I socialise with IETFers over the weekend, and this email= became the topic of conversation....but, hey...

Not that sad... or maybe this just sounds familiar...
=A0
This mail thread started out with = some folks making proposals on closing, merging, and moving WGs, which I br= iefly mentioned as a discussion-point during the aforementioned conversatio= n - thought I'd bring the resulting discussion out here.

The exchange (sanitised for public consumption by= removing swear-words) went roughly like this:

Me: So the RTG ADs asked for a "health check" of = the RTG Area, to the RTG-WG chairs and RTG-DIR, what=A0
could be done to better = the area, make it more efficient, etc.

Me: = Someone suggested that the best was to close <list-of-wg's>= ; and merge <other-list-of-wg's>, and perhaps

IETFer #1 = (who has been in the IETF for 5-6 years) interrupted:
That's =A0the F***ING problem with t= he IETF, all discussions happen behind closed doors, and we
do not have a say in thi= ngs.

*sigh* =A0A director= ate is "just" a group of people whose opinion is trusted by the A= Ds and who have agreed to do work to help the area, such as requested revie= ws. =A0As you (of course) well know, anyone can do the reviews.

There are multiple steps to developing a plan. =A0The W= G chairs and rtg-dir have valuable and diverse perspectives into
= the routing area. =A0 Other participants do too - but it can be harder to h= ave a completely unstructured and yet productive
discussion. =A0 I certainly intend to discuss and ask for feedback and= advice from the area, but at the end of the day, it=A0
is advice= . =A0 If your friend has opinions that she/he would like to share, I'm = happy to listen.

=A0
IETFer #2 (who's= been having an on-again-off-again relationship with the IETF for a decade = or so):
That= 9;s the same with all those secret directorates, whose reviews we now have = to contend with, where
did they suddenly come f= rom, secret committees.
=A0
In= terestingly, they've been around for at least the last 12+ years. =A0 = =A0And, just like the IETF, IAB, and IESG being "secret" cabals, = just because one doesn't know about them doesn't make them secret. = =A0 There is, of course, the Routing Area wiki (http://wiki.tools.ietf.org/area/rtg/trac/wik= i) =A0and the Routing Directorate is linked to there as:=A0

=A0
<rant went on for a bit, then we veered into much more c= onsensual subjects, like the=A0
=A0=A0the existence of extraterrestrials, if mint-jelly rea= lly belongs in a hot meal, if=A0
=A0=A0vegemite qualifies = as food,and who should win this years premier league in football>
<= /div>

I am not sure that this is RTG-area specific, but = it is not the first time that I have heard someone do a double-take when pr= esented with a GEN-ART, SEC-DIR, or other such review, or heard of discussi= ons within such groups, or the existence of such groups.=A0

Perhaps a root cause of this is, that these groups are = seen (like the IESG) as "roadblocks, not facilitators" because...= getting a huge critical review during an IETF LC is just that...a roadblock= . And, perhaps, getting the directorates more involved much earlier would a= lso solve such "image problems" of the IETF being an "old-fo= lks-club"?

I think the double-take is because, = for a document author, each document and the process is lovingly hand-craft= ed. =A0From the AD perspective, these reviews are a well known part of the = process and we'e trying to figure out how to churn out better docs with= less back-loading.

As for an "old-folks-club", is that over 25, = 30, 40, 50? =A0The IETF does tend to be reputation-based, but it is possibl= e to come in and do lots of very good work quickly and gain that reputation= . =A0 Any group with people forms networks of trust and they all look like = insider clubs to those not involved. =A0 I'm not sure how to fix that..= .

Regards,
Alia

=A0
Thomas


<= div>
On 25 Mar 2014, at 15:58, Alia Atlas <akatlas@gmail.com> w= rote:

Thomas,

Thanks very much for your thoughts. =A0On the b= eing underutilized and on cross-area review, what do you and others in the = Routing Directorate think about being asked to follow a single additional w= orking group that is not in RTG and may have routing related issues?

For the time speedup of ADs, I'm told that it'd= be really really useful to have more active document shepherds - who can f= acilitate getting comments and having them addressed. =A0I'm not sure h= ow to put that into place really. =A0As a WG chair, I felt like I was proce= ssing and pushing few enough drafts that I could do the shepherd job also -= but I know that there are some WGs where there is higher throughput. =A0It= 's also a good way of growing a person, to let them see the whole proce= ss and deal with the discussions.

For the drafts, I'd love to see earlier reviews. = =A0I'm not sure if at WG adoption is quite the right time, but it is a = good approximation of "early in the process". =A0 We could ask WG= chairs to request a reviewer at that point for drafts that may need it and= see what the load looks like. =A0For a start-up, having interested WG chai= rs identify WG drafts that could benefit from review would be helpful/inter= esting in terms of seeing the workload.

Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM,= Thomas Clausen <thomas@thomasclausen.org> wrote:
Hello ADs, Directorate, Chairs,

Interesting questions, thanks for caring and asking.

I am probably going to cut my answer into separate independent mails, as th= ere are vastly different topics in this question.

First, as a member of the RTG Directorate, I actually feel a little "u= nder-utilized". An occasional review of an I-D at an extremely late st= ate of its process, and a very rare more global question like this. As has = been discussed widely lately, ADs are overworked and have too little time, = so perhaps they do not call on the directorate enough - and, also, delegati= on of tasks that the ADs have to do is probably perceived as rather hard.
I've been dumbfounded by some of the reviews I have seen from ADs, eith= er during AD Evaluation or IESG Reviews: one particular case came to mind w= here Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker = during IESG Evaluation. It doesn't matter what document or WG it was, w= hat matters is that (i) it doesn't scale IETF-wide, (ii) it's poor = use of Adrian's time, (iii) there wasn't really something in the DI= SCUSS/COMMENTs that required the wizardry of a yellow dot (just some routin= g background), and -- most importantly -- (iv) getting a 10-page DISCUSS/CO= MMENT during IESG Evaluation really isn't helpful to the document autho= rs...its late, design decisions have been made, which are being questioned,= etc....it tires people out, pisses off authors, and frustrates everybody i= nvolved.

So, I've been playing around with a couple of ideas on the sideline, un= officially, and with only unwitting assistance from others involved....

Thought #1:
I-Ds - when called for adoption as WG documents, or when published as draft= -ietf-...-00's, gets someone from the directorate assigned, to provide = an initial review and thoughts on "what directions would be good to ta= ke (or avoid) here". That same reviewer can, occasionally, be invoked = by the WG chairs or authors, in the "so, did we catch this right?"= ; -- and, of course, should be called in on the WGLC of the document. I thi= nk of it a little as the "area advisors" but to a document rather= than a WG as a whole.

I've been playing around with that a bit, as an author:

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 Since I know very little about security, I= 9;ve looped in somebody who did, when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 having published a -00, and again the same = person as needed later in the process.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I've gotten =A0hugely valuable feedback= - making the ultimate SEC-DIR and SEC-AD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 reviews a lot =A0less painful for me (and, = given how little I knew about security, presumably
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 less =A0frustrating/time-consuming for the = ADs, too, than if I had been just shooting blind).

=A0 =A0 =A0 =A0 o =A0 =A0 =A0 Since I know even less about OPS stuff, Adria= n looped an OPS guy in on an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 individual -01, who asked a lot of good que= stions to what we were doing, and why,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 and which is hugely helpful.

As an author in the RTG Area, the SEC and OPS ADs are often real "road= blocks". Reasonably so, of course, they represent important concerns. = And gosh, every time I encounter any AD, I have to explain the whole contex= t over once again since, even if they've already gotten the story once,= they have to follow sufficiently many documents and topics that something = is bound to be flushed from their cache.

Having someone, from the respective directorate, be more of a facilitator, = sparring-partner, and who - over time - follows the document (and, presumab= ly, follows much fewer documents concurrently) through the process with the= authors would be great, as an author. And possibly makes the ADs encounter= less poor documents.

I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) be = just as much of a roadblock as the SEC/OPS folks, and I have no reason to n= ot expect Alia to have the same high (or higher) standards....so I imagine = that a way the RTG-DIR could help "improve the image of the ADs" = and at the same time get the ADs time liberated from writing 10-page discus= ses, would be something like the above....

In short, what I envision is a structured way of getting:
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 very early-reviews
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 a semi-permanent attachment of a reviewer fro= m the directorateS to a document
=A0 =A0 =A0 =A0 o =A0 =A0 =A0 this, through the documents lifecycle.

Not sure if it scales, either, but as an author I've greatly enjoyed ha= ving such a "ongoing relationship" with people helping me avoid p= itfalls.

A final note: having been around for a while in the IETF, it is really easy= to ask around for help from among other IETFers that one knows -- then aga= in, having been around for a while, presumably one has more experience and = needs less help in avoiding pitfalls. For a new(ish) author, who knows few = people and who presumably might be likely to need more help in avoiding sai= d pitfalls, it's a lot harder to actually reach out and get the right p= eople's eyes on a document -- and, even to know what eyes are good to g= et on it.

This might, actually, therefore be also a good way of the IETF to be more w= elcoming and inclusive to new folks wanting to get involved.

Thought #2:
So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter vers= ion of thought #1 is to have a more structure directorate review cycle duri= ng IETF LC, or perhaps during "Publication Requested" and before = "AD Evaluation". I am thinking that these be of the form: an I-D = hits the AD, the responsible/sponsoring AD requests directorate reviews fro= m all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors an= d reviewer iterate until either (i) issues are squared off or (ii) either a= uthors or reviewer declare the other as "bat-crap-crazy" (or, com= plains that the other side is not responsive) and raise the issue to the AD= . AD moves the document forward to "AD Evaluation" only once happ= y with the outcome of directorate reviews. In short, hiving out a lot more = of the "problem fixing" that happens during these reviews off to = the directorates - and leaving ADs to process presumably "less broken&= quot; documents.

As an author, I have actually found it a LOT easier/faster to iterate with = a directorate reviewer (who has my document fresh in mind), than with an AD= who's preoccupied with a dozen or so documents at the same time, and o= ther emergencies. Now, mind you, some ADs are good at saying "Busy, wi= ll come back to you in n days" -- others, alas, do "play dead&quo= t; if they feel they have more important fish to fry, and that's frustr= ating.

This might lessen the load on the ADs, but still has the disadvantage that = one gets feedback *very* late in the process....just a little bit earlier t= han during IESG processing.

Thought #3:
I thought it's worth calling out, that either of the above are not real= ly related to RTG documents: I should think that RTG WG Chairs are plenty a= ble to do the necessary during WG processing, and as an author in the RTG A= rea, I do usually know how to grab someone competent from the same area for= advice, as needed. While doing something like this intra-area can be a goo= d thing, the real boast that I, as document author, have felt has been thro= ugh getting cross-area feedback. Just as (being forced to be) reviewing doc= ument outside of the RTG area has been hugely educational and.

Cheers,

Thomas


On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello Directorate and WG chairs,
>
> Alia and I have been discussing the Routing Area, its work, its output= , and its
> working groups.
>
> We have reached a conclusion (which perhaps we should have come to soo= ner) that
> we need your help and input.
>
> The crunch question for us is "What makes it hard to get work don= e in the
> Routing Area?" What gets in the way of your work? What is making = life hard for
> document authors? How could working groups be doing better? We are ope= n to all
> and every type of answer. We are happy to have quick, one-line answers= or
> deeply-considered essays.
>
> What do you think?
>
> Thanks for all your input,
> Adrian and Alia
>
> PS Please respond to both aliases because not everyone is on both list= s. Sorry
> that that means some of you will get duplicates.
>




 --20cf303a2d61cf4a9a04f5735a06-- From nobody Tue Mar 25 12:34:12 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456B21A01E1; Tue, 25 Mar 2014 12:34:00 -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 HyC8z7U5T35k; Tue, 25 Mar 2014 12:33:56 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 449C51A01DD; Tue, 25 Mar 2014 12:33:56 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so1029900yhn.14 for ; Tue, 25 Mar 2014 12:33:55 -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=y4amK2zhxUAp6m1GhVvJ+GQPEl1QNgLKgysve/a3EDc=; b=RNd83C4RxrrC8aNsvnyMNMYNErjOLT5ejNUR8ol4wseZv80/6Ujndr+f3kdm0t0mGC fzKtS8/rQBqp2BSop6iCgKsLy8t+h2u6K3VmvUfCtuB9qK/f3cyoAOdi5r0ApDUiiOQW pCnM5i5yR6v9q89XqaAfIKZHwxZDZI8cpvU2HcRb3uEYXvMBuqcmAN1Ms/TkZJijvRfV wApu3Tf2TP0tlByrTmB/W0RPKYGB2I1SyHyrvs25EtM0gcqOY6co/m08SuZ8PAJ3OEx6 NOyS5kKbz1+7MdwSHBCmMCZQwZvt3WimFfxZQ2aCL9KsuiIsuCmTUWwbW23n60Phf8Jg wkwA== MIME-Version: 1.0 X-Received: by 10.236.150.205 with SMTP id z53mr76415383yhj.75.1395776034875; Tue, 25 Mar 2014 12:33:54 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Tue, 25 Mar 2014 12:33:54 -0700 (PDT) In-Reply-To: <5331C0FA.3040008@joelhalpern.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331C0FA.3040008@joelhalpern.com> Date: Tue, 25 Mar 2014 15:33:54 -0400 Message-ID: From: Alia Atlas To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=20cf303a2d61beb3bb04f5736e8b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/-vyW-sX6RQa24Z03E_X9ZBHCeGs Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "rtg-chairs@ietf.org" , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:34:00 -0000 --20cf303a2d61beb3bb04f5736e8b Content-Type: text/plain; charset=ISO-8859-1 Hi Joel, As you well know, we've tried doing reviews at IETF last call - and it is too late to change significantly much. My thought is by having someone listen in casually on a non-routing WG, concerns are likely to be identified much sooner. On Tue, Mar 25, 2014 at 1:46 PM, Joel M. Halpern wrote: > I am a little concerned that assigned directorate members to working > groups will produce negative effects: > 1) It will lead to more scheduling conflict. > The request isn't to go to the WG, but to listen to the mailing list. Both would be good, but scheduling is already hard. > 2) It will lead to an assumption that this one person will review all the > output of a given WG. I think we are actually better off if that task > sometimes moves, as it ensures that fresh eyes are looking, for example to > detect that assumptions are actually stated rather than merely in the minds > of the WG. > Ah - goal is to flag drafts that could use an early review and to determine when routing clue might be usefully injected. The one person would not be responsible for reviewing all the output of a given WG. We have a newly forming WG ( https://datatracker.ietf.org/doc/charter-ietf-dart/) for which such a person would be very useful. Regards, Alia > > Yours, > Joel > > > On 3/25/14, 10:58 AM, Alia Atlas wrote: > >> Thomas, >> >> Thanks very much for your thoughts. On the being underutilized and on >> cross-area review, what do you and others in the Routing Directorate >> think about being asked to follow a single additional working group that >> is not in RTG and may have routing related issues? >> >> For the time speedup of ADs, I'm told that it'd be really really useful >> to have more active document shepherds - who can facilitate getting >> comments and having them addressed. I'm not sure how to put that into >> place really. As a WG chair, I felt like I was processing and pushing >> few enough drafts that I could do the shepherd job also - but I know >> that there are some WGs where there is higher throughput. It's also a >> good way of growing a person, to let them see the whole process and deal >> with the discussions. >> >> For the drafts, I'd love to see earlier reviews. I'm not sure if at WG >> adoption is quite the right time, but it is a good approximation of >> "early in the process". We could ask WG chairs to request a reviewer >> at that point for drafts that may need it and see what the load looks >> like. For a start-up, having interested WG chairs identify WG drafts >> that could benefit from review would be helpful/interesting in terms of >> seeing the workload. >> >> Regards, >> Alia >> >> >> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen >> > wrote: >> >> Hello ADs, Directorate, Chairs, >> >> Interesting questions, thanks for caring and asking. >> >> I am probably going to cut my answer into separate independent >> mails, as there are vastly different topics in this question. >> >> First, as a member of the RTG Directorate, I actually feel a little >> "under-utilized". An occasional review of an I-D at an extremely >> late state of its process, and a very rare more global question like >> this. As has been discussed widely lately, ADs are overworked and >> have too little time, so perhaps they do not call on the directorate >> enough - and, also, delegation of tasks that the ADs have to do is >> probably perceived as rather hard. >> >> I've been dumbfounded by some of the reviews I have seen from ADs, >> either during AD Evaluation or IESG Reviews: one particular case >> came to mind where Adrian sent what looked like a 10-page >> DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't >> matter what document or WG it was, what matters is that (i) it >> doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) >> there wasn't really something in the DISCUSS/COMMENTs that required >> the wizardry of a yellow dot (just some routing background), and -- >> most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during >> IESG Evaluation really isn't helpful to the document authors...its >> late, design decisions have been made, which are being questioned, >> etc....it tires people out, pisses off authors, and frustrates >> everybody involved. >> >> So, I've been playing around with a couple of ideas on the sideline, >> unofficially, and with only unwitting assistance from others >> involved.... >> >> Thought #1: >> I-Ds - when called for adoption as WG documents, or when published >> as draft-ietf-...-00's, gets someone from the directorate assigned, >> to provide an initial review and thoughts on "what directions would >> be good to take (or avoid) here". That same reviewer can, >> occasionally, be invoked by the WG chairs or authors, in the "so, >> did we catch this right?" -- and, of course, should be called in on >> the WGLC of the document. I think of it a little as the "area >> advisors" but to a document rather than a WG as a whole. >> >> I've been playing around with that a bit, as an author: >> >> o Since I know very little about security, I've >> looped in somebody who did, when >> having published a -00, and again the same person >> as needed later in the process. >> I've gotten hugely valuable feedback - making the >> ultimate SEC-DIR and SEC-AD >> reviews a lot less painful for me (and, given how >> little I knew about security, presumably >> less frustrating/time-consuming for the ADs, too, >> than if I had been just shooting blind). >> >> o Since I know even less about OPS stuff, Adrian >> looped an OPS guy in on an >> individual -01, who asked a lot of good questions >> to what we were doing, and why, >> and which is hugely helpful. >> >> As an author in the RTG Area, the SEC and OPS ADs are often real >> "roadblocks". Reasonably so, of course, they represent important >> concerns. And gosh, every time I encounter any AD, I have to explain >> the whole context over once again since, even if they've already >> gotten the story once, they have to follow sufficiently many >> documents and topics that something is bound to be flushed from >> their cache. >> >> Having someone, from the respective directorate, be more of a >> facilitator, sparring-partner, and who - over time - follows the >> document (and, presumably, follows much fewer documents >> concurrently) through the process with the authors would be great, >> as an author. And possibly makes the ADs encounter less poor >> documents. >> >> I know that Adrian can (cf. the aforementioned 10-page >> DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS >> folks, and I have no reason to not expect Alia to have the same high >> (or higher) standards....so I imagine that a way the RTG-DIR could >> help "improve the image of the ADs" and at the same time get the ADs >> time liberated from writing 10-page discusses, would be something >> like the above.... >> >> In short, what I envision is a structured way of getting: >> o very early-reviews >> o a semi-permanent attachment of a reviewer from the >> directorateS to a document >> o this, through the documents lifecycle. >> >> Not sure if it scales, either, but as an author I've greatly enjoyed >> having such a "ongoing relationship" with people helping me avoid >> pitfalls. >> >> A final note: having been around for a while in the IETF, it is >> really easy to ask around for help from among other IETFers that one >> knows -- then again, having been around for a while, presumably one >> has more experience and needs less help in avoiding pitfalls. For a >> new(ish) author, who knows few people and who presumably might be >> likely to need more help in avoiding said pitfalls, it's a lot >> harder to actually reach out and get the right people's eyes on a >> document -- and, even to know what eyes are good to get on it. >> >> This might, actually, therefore be also a good way of the IETF to be >> more welcoming and inclusive to new folks wanting to get involved. >> >> Thought #2: >> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter >> version of thought #1 is to have a more structure directorate review >> cycle during IETF LC, or perhaps during "Publication Requested" and >> before "AD Evaluation". I am thinking that these be of the form: an >> I-D hits the AD, the responsible/sponsoring AD requests directorate >> reviews from all the concerned directorates (GEN, SEC, OPS, RTG, >> TSP, ...). Authors and reviewer iterate until either (i) issues are >> squared off or (ii) either authors or reviewer declare the other as >> "bat-crap-crazy" (or, complains that the other side is not >> responsive) and raise the issue to the AD. AD moves the document >> forward to "AD Evaluation" only once happy with the outcome of >> directorate reviews. In short, hiving out a lot more of the "problem >> fixing" that happens during these reviews off to the directorates - >> and leaving ADs to process presumably "less broken" documents. >> >> As an author, I have actually found it a LOT easier/faster to >> iterate with a directorate reviewer (who has my document fresh in >> mind), than with an AD who's preoccupied with a dozen or so >> documents at the same time, and other emergencies. Now, mind you, >> some ADs are good at saying "Busy, will come back to you in n days" >> -- others, alas, do "play dead" if they feel they have more >> important fish to fry, and that's frustrating. >> >> This might lessen the load on the ADs, but still has the >> disadvantage that one gets feedback *very* late in the >> process....just a little bit earlier than during IESG processing. >> >> Thought #3: >> I thought it's worth calling out, that either of the above are not >> really related to RTG documents: I should think that RTG WG Chairs >> are plenty able to do the necessary during WG processing, and as an >> author in the RTG Area, I do usually know how to grab someone >> competent from the same area for advice, as needed. While doing >> something like this intra-area can be a good thing, the real boast >> that I, as document author, have felt has been through getting >> cross-area feedback. Just as (being forced to be) reviewing document >> outside of the RTG area has been hugely educational and. >> >> Cheers, >> >> Thomas >> >> >> On 21 Mar 2014, at 19:31, Adrian Farrel > > wrote: >> >> > Hello Directorate and WG chairs, >> > >> > Alia and I have been discussing the Routing Area, its work, its >> output, and its >> > working groups. >> > >> > We have reached a conclusion (which perhaps we should have come >> to sooner) that >> > we need your help and input. >> > >> > The crunch question for us is "What makes it hard to get work >> done in the >> > Routing Area?" What gets in the way of your work? What is making >> life hard for >> > document authors? How could working groups be doing better? We >> are open to all >> > and every type of answer. We are happy to have quick, one-line >> answers or >> > deeply-considered essays. >> > >> > What do you think? >> > >> > Thanks for all your input, >> > Adrian and Alia >> > >> > PS Please respond to both aliases because not everyone is on both >> lists. Sorry >> > that that means some of you will get duplicates. >> > >> >> >> --20cf303a2d61beb3bb04f5736e8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joel,

As you well know, we've tr= ied doing reviews at IETF last call - and it is too late to change signific= antly much.
My thought is by having someone l= isten in casually on a non-routing WG, concerns are likely to be identified=
much sooner.
On Tue, Mar 25, 2014 at 1:46 PM, Joel M. Halper= n <jmh@joelhalpern.com> wrote:
I am a little concerned that assigned directorate members = to working groups will produce negative effects:
1) It will lead to more scheduling conflict.

The request isn't to go to the WG, but to listen to the mailing l= ist. =A0Both would be good, but scheduling is already hard.
=A0
2) It will lead to an assumption that this one person will review all the o= utput of a given WG. =A0I think we are actually better off if that task som= etimes moves, as it ensures that fresh eyes are looking, for example to det= ect that assumptions are actually stated rather than merely in the minds of= the WG.

Ah - goal is to flag drafts that could use= an early review and to determine when routing clue might be usefully injec= ted.
The one person would not be responsible for reviewing all th= e output of a given WG.

We have a newly forming WG (https://datatracker.ietf.org/doc/chart= er-ietf-dart/) for which such a person would be very useful.

Regards,
Alia
=A0

Yours,
Joel


On 3/25/14, 10:58 AM, Alia Atlas wrote:
Thomas,

Thanks very much for your thoughts. =A0On the being underutilized and on cross-area review, what do you and others in the Routing Directorate
think about being asked to follow a single additional working group that is not in RTG and may have routing related issues?

For the time speedup of ADs, I'm told that it'd be really really us= eful
to have more active document shepherds - who can facilitate getting
comments and having them addressed. =A0I'm not sure how to put that int= o
place really. =A0As a WG chair, I felt like I was processing and pushing few enough drafts that I could do the shepherd job also - but I know
that there are some WGs where there is higher throughput. =A0It's also = a
good way of growing a person, to let them see the whole process and deal with the discussions.

For the drafts, I'd love to see earlier reviews. =A0I'm not sure if= at WG
adoption is quite the right time, but it is a good approximation of
"early in the process". =A0 We could ask WG chairs to request a r= eviewer
at that point for drafts that may need it and see what the load looks
like. =A0For a start-up, having interested WG chairs identify WG drafts
that could benefit from review would be helpful/interesting in terms of
seeing the workload.

Regards,
Alia


On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen
<thomas@th= omasclausen.org <mailto:thomas@thomasclausen.org>> wrote:

=A0 =A0 Hello ADs, Directorate, Chairs,

=A0 =A0 Interesting questions, thanks for caring and asking.

=A0 =A0 I am probably going to cut my answer into separate independent
=A0 =A0 mails, as there are vastly different topics in this question.

=A0 =A0 First, as a member of the RTG Directorate, I actually feel a little=
=A0 =A0 "under-utilized". An occasional review of an I-D at an ex= tremely
=A0 =A0 late state of its process, and a very rare more global question lik= e
=A0 =A0 this. As has been discussed widely lately, ADs are overworked and =A0 =A0 have too little time, so perhaps they do not call on the directorat= e
=A0 =A0 enough - and, also, delegation of tasks that the ADs have to do is<= br> =A0 =A0 probably perceived as rather hard.

=A0 =A0 I've been dumbfounded by some of the reviews I have seen from A= Ds,
=A0 =A0 either during AD Evaluation or IESG Reviews: one particular case =A0 =A0 came to mind where Adrian sent what looked like a 10-page
=A0 =A0 DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn'= ;t
=A0 =A0 matter what document or WG it was, what matters is that (i) it
=A0 =A0 doesn't scale IETF-wide, (ii) it's poor use of Adrian's= time, (iii)
=A0 =A0 there wasn't really something in the DISCUSS/COMMENTs that requ= ired
=A0 =A0 the wizardry of a yellow dot (just some routing background), and --=
=A0 =A0 most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during =A0 =A0 IESG Evaluation really isn't helpful to the document authors...= its
=A0 =A0 late, design decisions have been made, which are being questioned,<= br> =A0 =A0 etc....it tires people out, pisses off authors, and frustrates
=A0 =A0 everybody involved.

=A0 =A0 So, I've been playing around with a couple of ideas on the side= line,
=A0 =A0 unofficially, and with only unwitting assistance from others
=A0 =A0 involved....

=A0 =A0 Thought #1:
=A0 =A0 I-Ds - when called for adoption as WG documents, or when published<= br> =A0 =A0 as draft-ietf-...-00's, gets someone from the directorate assig= ned,
=A0 =A0 to provide an initial review and thoughts on "what directions = would
=A0 =A0 be good to take (or avoid) here". That same reviewer can,
=A0 =A0 occasionally, be invoked by the WG chairs or authors, in the "= so,
=A0 =A0 did we catch this right?" -- and, of course, should be called = in on
=A0 =A0 the WGLC of the document. I think of it a little as the "area<= br> =A0 =A0 advisors" but to a document rather than a WG as a whole.

=A0 =A0 I've been playing around with that a bit, as an author:

=A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 Since I know very little about sec= urity, I've
=A0 =A0 looped in somebody who did, when
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0having published a -00, and agai= n the same person
=A0 =A0 as needed later in the process.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I've gotten =A0hugely valuab= le feedback - making the
=A0 =A0 ultimate SEC-DIR and SEC-AD
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reviews a lot =A0less painful fo= r me (and, given how
=A0 =A0 little I knew about security, presumably
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0less =A0frustrating/time-consumi= ng for the ADs, too,
=A0 =A0 than if I had been just shooting blind).

=A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 Since I know even less about OPS s= tuff, Adrian
=A0 =A0 looped an OPS guy in on an
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0individual -01, who asked a lot = of good questions
=A0 =A0 to what we were doing, and why,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and which is hugely helpful.

=A0 =A0 As an author in the RTG Area, the SEC and OPS ADs are often real =A0 =A0 "roadblocks". Reasonably so, of course, they represent im= portant
=A0 =A0 concerns. And gosh, every time I encounter any AD, I have to explai= n
=A0 =A0 the whole context over once again since, even if they've alread= y
=A0 =A0 gotten the story once, they have to follow sufficiently many
=A0 =A0 documents and topics that something is bound to be flushed from
=A0 =A0 their cache.

=A0 =A0 Having someone, from the respective directorate, be more of a
=A0 =A0 facilitator, sparring-partner, and who - over time - follows the =A0 =A0 document (and, presumably, follows much fewer documents
=A0 =A0 concurrently) through the process with the authors would be great,<= br> =A0 =A0 as an author. And possibly makes the ADs encounter less poor docume= nts.

=A0 =A0 I know that Adrian can (cf. the aforementioned 10-page
=A0 =A0 DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS
=A0 =A0 folks, and I have no reason to not expect Alia to have the same hig= h
=A0 =A0 (or higher) standards....so I imagine that a way the RTG-DIR could<= br> =A0 =A0 help "improve the image of the ADs" and at the same time = get the ADs
=A0 =A0 time liberated from writing 10-page discusses, would be something =A0 =A0 like the above....

=A0 =A0 In short, what I envision is a structured way of getting:
=A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 very early-reviews
=A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 a semi-permanent attachment of a r= eviewer from the
=A0 =A0 directorateS to a document
=A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 this, through the documents lifecy= cle.

=A0 =A0 Not sure if it scales, either, but as an author I've greatly en= joyed
=A0 =A0 having such a "ongoing relationship" with people helping = me avoid
=A0 =A0 pitfalls.

=A0 =A0 A final note: having been around for a while in the IETF, it is
=A0 =A0 really easy to ask around for help from among other IETFers that on= e
=A0 =A0 knows -- then again, having been around for a while, presumably one=
=A0 =A0 has more experience and needs less help in avoiding pitfalls. For a=
=A0 =A0 new(ish) author, who knows few people and who presumably might be =A0 =A0 likely to need more help in avoiding said pitfalls, it's a lot<= br> =A0 =A0 harder to actually reach out and get the right people's eyes on= a
=A0 =A0 document -- and, even to know what eyes are good to get on it.

=A0 =A0 This might, actually, therefore be also a good way of the IETF to b= e
=A0 =A0 more welcoming and inclusive to new folks wanting to get involved.<= br>
=A0 =A0 Thought #2:
=A0 =A0 So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, ligh= ter
=A0 =A0 version of thought #1 is to have a more structure directorate revie= w
=A0 =A0 cycle during IETF LC, or perhaps during "Publication Requested= " and
=A0 =A0 before "AD Evaluation". I am thinking that these be of th= e form: an
=A0 =A0 I-D hits the AD, the responsible/sponsoring AD requests directorate=
=A0 =A0 reviews from all the concerned directorates (GEN, SEC, OPS, RTG, =A0 =A0 TSP, ...). Authors and reviewer iterate until either (i) issues are=
=A0 =A0 squared off or (ii) either authors or reviewer declare the other as=
=A0 =A0 "bat-crap-crazy" (or, complains that the other side is no= t
=A0 =A0 responsive) and raise the issue to the AD. AD moves the document =A0 =A0 forward to "AD Evaluation" only once happy with the outco= me of
=A0 =A0 directorate reviews. In short, hiving out a lot more of the "p= roblem
=A0 =A0 fixing" that happens during these reviews off to the directora= tes -
=A0 =A0 and leaving ADs to process presumably "less broken" docum= ents.

=A0 =A0 As an author, I have actually found it a LOT easier/faster to
=A0 =A0 iterate with a directorate reviewer (who has my document fresh in =A0 =A0 mind), than with an AD who's preoccupied with a dozen or so
=A0 =A0 documents at the same time, and other emergencies. Now, mind you, =A0 =A0 some ADs are good at saying "Busy, will come back to you in n = days"
=A0 =A0 -- others, alas, do "play dead" if they feel they have mo= re
=A0 =A0 important fish to fry, and that's frustrating.

=A0 =A0 This might lessen the load on the ADs, but still has the
=A0 =A0 disadvantage that one gets feedback *very* late in the
=A0 =A0 process....just a little bit earlier than during IESG processing.
=A0 =A0 Thought #3:
=A0 =A0 I thought it's worth calling out, that either of the above are = not
=A0 =A0 really related to RTG documents: I should think that RTG WG Chairs<= br> =A0 =A0 are plenty able to do the necessary during WG processing, and as an=
=A0 =A0 author in the RTG Area, I do usually know how to grab someone
=A0 =A0 competent from the same area for advice, as needed. While doing
=A0 =A0 something like this intra-area can be a good thing, the real boast<= br> =A0 =A0 that I, as document author, have felt has been through getting
=A0 =A0 cross-area feedback. Just as (being forced to be) reviewing documen= t
=A0 =A0 outside of the RTG area has been hugely educational and.

=A0 =A0 Cheers,

=A0 =A0 Thomas


=A0 =A0 On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk
=A0 =A0 <mailto:adrian@olddog.co.uk>> wrote:

=A0 =A0 =A0> Hello Directorate and WG chairs,
=A0 =A0 =A0>
=A0 =A0 =A0> Alia and I have been discussing the Routing Area, its work,= its
=A0 =A0 output, and its
=A0 =A0 =A0> working groups.
=A0 =A0 =A0>
=A0 =A0 =A0> We have reached a conclusion (which perhaps we should have = come
=A0 =A0 to sooner) that
=A0 =A0 =A0> we need your help and input.
=A0 =A0 =A0>
=A0 =A0 =A0> The crunch question for us is "What makes it hard to g= et work
=A0 =A0 done in the
=A0 =A0 =A0> Routing Area?" What gets in the way of your work? What= is making
=A0 =A0 life hard for
=A0 =A0 =A0> document authors? How could working groups be doing better?= We
=A0 =A0 are open to all
=A0 =A0 =A0> and every type of answer. We are happy to have quick, one-l= ine
=A0 =A0 answers or
=A0 =A0 =A0> deeply-considered essays.
=A0 =A0 =A0>
=A0 =A0 =A0> What do you think?
=A0 =A0 =A0>
=A0 =A0 =A0> Thanks for all your input,
=A0 =A0 =A0> Adrian and Alia
=A0 =A0 =A0>
=A0 =A0 =A0> PS Please respond to both aliases because not everyone is o= n both
=A0 =A0 lists. Sorry
=A0 =A0 =A0> that that means some of you will get duplicates.
=A0 =A0 =A0>



--20cf303a2d61beb3bb04f5736e8b-- From nobody Tue Mar 25 12:38:05 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789931A01E3; Tue, 25 Mar 2014 12:37:44 -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 bGI1_p9Xpe00; Tue, 25 Mar 2014 12:37:42 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E7DD81A01F4; Tue, 25 Mar 2014 12:37:41 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id b6so1036043yha.5 for ; Tue, 25 Mar 2014 12:37:40 -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=rNOsOVzjWNmuped5Lzg1+jdGCwE2hjNSdvlPoTSOBWA=; b=n0svnj18s4vlTAHxKOg8RXhfKwBsA9E3By+Jn6JiLHcF7RhohluduE4BdMWih+0D5j cKBPE4SFiv7IUqHBGqCWXR9EApR0lqVbmlzIZ6GcdpeyflDZXLLIIfX2i4AmBI5KJFjc CXy23J6AaVngQtjbwyrjMyxVW1C63Adl0FWZVKVzwq9SKWLIXEvLuOzy6GYXVTHjsI9E lp2poxGNDnA3XrymmM8AUFd9xfxooE302SBUXpOUU9NWJZ/W8ieEaXZcjdaw6l1OWQD/ 01aW+YkNYpWr9K3ifgqFzx3qd/B0pPL+wYnkL62EddaFNRFnOdNkRwxXvjT0Ms2i18t1 DjTQ== MIME-Version: 1.0 X-Received: by 10.236.199.78 with SMTP id w54mr3627998yhn.139.1395776260682; Tue, 25 Mar 2014 12:37:40 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Tue, 25 Mar 2014 12:37:40 -0700 (PDT) In-Reply-To: <5331D785.5030800@labn.net> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331D785.5030800@labn.net> Date: Tue, 25 Mar 2014 15:37:40 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=089e0158c41c34529c04f5737c5d Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/cdMtU-HIlgo5Ml_cMscQk6qzc58 Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:37:44 -0000 --089e0158c41c34529c04f5737c5d Content-Type: text/plain; charset=ISO-8859-1 Lou, I hear loud and clear that a language review would be helpful. I agree that on WG adoption and when the authors have prepared the draft for LC are good times for it. The question is whether the language reviewers are volunteering for a particular WG or whether we should develop a set of language reviewers for the whole area. Alia On Tue, Mar 25, 2014 at 3:22 PM, Lou Berger wrote: > > On 3/25/2014 3:12 PM, Alia Atlas wrote: > > As far as English language mentoring, it sounds like George, Loa, and > > Ross have a trial run going in MPLS. > > We can discuss having common organization for volunteers on each WG's > > wiki or on the routing-area wiki. > > > > Thoughts? > > > > I think language review would be *hugely* helpful. Personally I'd like > it to occur right *after* WG adoption and once again after the authors > declare a document ready for LC (from the technical perspective). > > Lou > > > --089e0158c41c34529c04f5737c5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Lou,

I hear loud and clear that a langu= age review would be helpful. =A0I agree that on
WG adoption and w= hen the authors have prepared the draft for LC are good times
for= it.

The question is whether the language reviewers are volu= nteering for a particular
WG or whether we should develop a set o= f language reviewers for the whole area.

Alia


On Tue,= Mar 25, 2014 at 3:22 PM, Lou Berger <lberger@labn.net> wrote= :

On 3/25/2014 3:12 PM, Alia Atlas wrote:
> As far as English language mentoring, it sounds like George, Loa, and<= br> > Ross have a trial run going in MPLS.
> We can discuss having common organization for volunteers on each WG= 9;s
> wiki or on the routing-area wiki.
>
> Thoughts?
>

I think language review would be *hugely* helpful. =A0Personally I= 9;d like
it to occur right *after* WG adoption and once again after the authors
declare a document ready for LC (from the technical perspective).

Lou



--089e0158c41c34529c04f5737c5d-- From nobody Tue Mar 25 12:58:07 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37F71A01E3 for ; Tue, 25 Mar 2014 12:57:48 -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 ZCIfHePPXlfL for ; Tue, 25 Mar 2014 12:57:48 -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 EE1EC1A0144 for ; Tue, 25 Mar 2014 12:57:47 -0700 (PDT) Received: (qmail 20074 invoked by uid 0); 25 Mar 2014 19:56:44 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 25 Mar 2014 19:56:44 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id i2wg1n00Q2SSUrH012wjBG; Tue, 25 Mar 2014 20:56:43 -0600 X-Authority-Analysis: v=2.1 cv=L+eOHYj8 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=Tvs_GUuyyx4A:10 a=WspU9PCzxMAA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=LghhH8ftJBihuJLNPPMA:9 a=wPNLvfGTeEIA:10 a=33rK67OTR_gA: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=jct2aepmvYR/L7vMW7pHuxM/TMetNlGBP3AUbEFJp/M=; b=bb/8hSbokpFYYNt0Rg/JBnbvL0KNRrkOpWEDA0N78E8OG8XYFINYwUNlhahZj04am3HsgtsLPUWuM9RdPqOiBZxGoUMVH6qFM62J0pD0hrt7KxK1gFjkPPfLOOMj7axM; Received: from box313.bluehost.com ([69.89.31.113]:48674 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WSXSj-0001Kg-I3; Tue, 25 Mar 2014 13:56:41 -0600 Message-ID: <5331DF75.7070205@labn.net> Date: Tue, 25 Mar 2014 15:56:37 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alia Atlas References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331D785.5030800@labn.net> 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/rtg-dir/V9T0HxNMgp2sRuv5X_W0nW4_Gko Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "rtg-chairs@ietf.org" , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:57:49 -0000 Sorry, I thought the answer here was implied in the discussion, i.e. that we leverage what the MPLS WG (chairs) have started across the whole area... So to revise my position for utmost clarity: I think a language review process/team for the RTG area, at the very least, would be *hugely* helpful. Lou On 3/25/2014 3:37 PM, Alia Atlas wrote: > Lou, > > I hear loud and clear that a language review would be helpful. I > agree that on > WG adoption and when the authors have prepared the draft for LC are > good times > for it. > > The question is whether the language reviewers are volunteering for a > particular > WG or whether we should develop a set of language reviewers for the > whole area. > > Alia > > > On Tue, Mar 25, 2014 at 3:22 PM, Lou Berger > wrote: > > > On 3/25/2014 3:12 PM, Alia Atlas wrote: > > As far as English language mentoring, it sounds like George, > Loa, and > > Ross have a trial run going in MPLS. > > We can discuss having common organization for volunteers on each > WG's > > wiki or on the routing-area wiki. > > > > Thoughts? > > > > I think language review would be *hugely* helpful. Personally I'd > like > it to occur right *after* WG adoption and once again after the authors > declare a document ready for LC (from the technical perspective). > > Lou > > > From nobody Tue Mar 25 13:06:19 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD851A00E6; Tue, 25 Mar 2014 13:05:57 -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 9Ft1x9gBmpIF; Tue, 25 Mar 2014 13:05:55 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 286AB1A00BE; Tue, 25 Mar 2014 13:05:55 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id c41so1076695yho.39 for ; Tue, 25 Mar 2014 13:05: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:date:message-id:subject:from:to :cc:content-type; bh=Z1tPl8VuhXykbwKEgVm5RJVPD5Gb+Pvva5ase7mOeaM=; b=UUlvlF0AyNUG7E7K0gUL3gmXS056eDS8S6RNm3xi8xb0v8+8juorLNp3E/8Thg3u1H hRTXne4H00Dp1sJLZeSdvOEgj/ndgKL4qfZmRUlyHkENlVo3GmDATDqIVhDHUmUAA0MD J93buDSljMkhLjMBLSpW/hWDAQHDhM0vk8V4yWK/uu3j+DX8+9tvDWM40LFMEGmyd1Mz pdHBbRE43DiOChNlXjd6gJlJp0jOJS7DdGVjA9nlki83tWFKVGOQVXkdUTnNIzXx6qlv 7nP2NFTg0eUOpiwq36NckbDB7VnzqrHeCsHA1ktyHGJSmjNuKzDpbsLQ29VE8fCYC7y5 cqPQ== MIME-Version: 1.0 X-Received: by 10.236.18.227 with SMTP id l63mr7503510yhl.101.1395777953954; Tue, 25 Mar 2014 13:05:53 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Tue, 25 Mar 2014 13:05:53 -0700 (PDT) In-Reply-To: <5331DF75.7070205@labn.net> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331D785.5030800@labn.net> <5331DF75.7070205@labn.net> Date: Tue, 25 Mar 2014 16:05:53 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=089e0122a64a21821004f573e1ef Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/bi02I7DIemtqZBch5ebgy5q8rJ0 Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "rtg-chairs@ietf.org" , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 20:05:57 -0000 --089e0122a64a21821004f573e1ef Content-Type: text/plain; charset=ISO-8859-1 Got it. Let me get the Document Mentor idea written up first. The language review process/team would be completely new. If someone else writes up a strawman first pass of it, that'd be very useful input ;-) Alia On Tue, Mar 25, 2014 at 3:56 PM, Lou Berger wrote: > Sorry, I thought the answer here was implied in the discussion, i.e. > that we leverage what the MPLS WG (chairs) have started across the > whole area... > > So to revise my position for utmost clarity: > > I think a language review process/team for the RTG area, at the very > least, would be *hugely* helpful. > > Lou > > On 3/25/2014 3:37 PM, Alia Atlas wrote: > > Lou, > > > > I hear loud and clear that a language review would be helpful. I > > agree that on > > WG adoption and when the authors have prepared the draft for LC are > > good times > > for it. > > > > The question is whether the language reviewers are volunteering for a > > particular > > WG or whether we should develop a set of language reviewers for the > > whole area. > > > > Alia > > > > > > On Tue, Mar 25, 2014 at 3:22 PM, Lou Berger > > wrote: > > > > > > On 3/25/2014 3:12 PM, Alia Atlas wrote: > > > As far as English language mentoring, it sounds like George, > > Loa, and > > > Ross have a trial run going in MPLS. > > > We can discuss having common organization for volunteers on each > > WG's > > > wiki or on the routing-area wiki. > > > > > > Thoughts? > > > > > > > I think language review would be *hugely* helpful. Personally I'd > > like > > it to occur right *after* WG adoption and once again after the > authors > > declare a document ready for LC (from the technical perspective). > > > > Lou > > > > > > > > --089e0122a64a21821004f573e1ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Got it. =A0Let me get the Document Mentor idea written up = first.
The language review process/team would be completely new.
<= div>If someone else writes up a strawman first pass of it, that'd be
very useful input ;-)

Alia


On Tue, Mar 25, = 2014 at 3:56 PM, Lou Berger <lberger@labn.net> wrote:
Sorry, I thought the answer here was implied= in the discussion, i.e.
that we leverage what the MPLS WG (chairs) have started across the
whole =A0area...

So to revise my position for utmost clarity:

I think a language review process/team for the RTG area, at the very
least, would be *hugely* helpful.

Lou

On 3/25/2014 3:37 PM, Alia Atlas wrote:
> Lou,
>
> I hear loud and clear that a language review would be helpful. =A0I > agree that on
> WG adoption and when the authors have prepared the draft for LC are > good times
> for it.
>
> The question is whether the language reviewers are volunteering for a<= br> > particular
> WG or whether we should develop a set of language reviewers for the > whole area.
>
> Alia
>
>
> On Tue, Mar 25, 2014 at 3:22 PM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
>
> =A0 =A0 On 3/25/2014 3:12 PM, Alia Atlas wrote:
> =A0 =A0 > As far as English language mentoring, it sounds like Geor= ge,
> =A0 =A0 Loa, and
> =A0 =A0 > Ross have a trial run going in MPLS.
> =A0 =A0 > We can discuss having common organization for volunteers = on each
> =A0 =A0 WG's
> =A0 =A0 > wiki or on the routing-area wiki.
> =A0 =A0 >
> =A0 =A0 > Thoughts?
> =A0 =A0 >
>
> =A0 =A0 I think language review would be *hugely* helpful. =A0Personal= ly I'd
> =A0 =A0 like
> =A0 =A0 it to occur right *after* WG adoption and once again after the= authors
> =A0 =A0 declare a document ready for LC (from the technical perspectiv= e).
>
> =A0 =A0 Lou
>
>
>


--089e0122a64a21821004f573e1ef-- From nobody Tue Mar 25 14:13:43 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7342B1A0225; Tue, 25 Mar 2014 14:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 p9nx4qPQkoZ5; Tue, 25 Mar 2014 14:13:24 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id CD0A21A0212; Tue, 25 Mar 2014 14:13:22 -0700 (PDT) Received: from mail167-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Mar 2014 21:13:21 +0000 Received: from mail167-tx2 (localhost [127.0.0.1]) by mail167-tx2-R.bigfish.com (Postfix) with ESMTP id 5749938021F; Tue, 25 Mar 2014 21:13:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail167-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(377454003)(51704005)(189002)(199002)(479174003)(24454002)(51444003)(80022001)(97186001)(4396001)(65816001)(97336001)(76786001)(81686001)(87266001)(19580395003)(47736001)(50986001)(90146001)(83072002)(49866001)(85852003)(66066001)(85306002)(76796001)(46102001)(53806001)(54356001)(76482001)(54316002)(51856001)(56776001)(76576001)(47976001)(74366001)(33646001)(74316001)(81342001)(31966008)(19580405001)(74502001)(74662001)(74706001)(79102001)(74876001)(80976001)(47446002)(81816001)(94946001)(95416001)(59766001)(98676001)(92566001)(56816005)(94316002)(87936001)(81542001)(2656002)(83322001)(93136001)(93516002)(77982001)(86362001)(63696002)(20776003)(95666003)(69226001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB196; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:B856C10D.1E0BB7D9.41CB7FA7.56F9C07D.2026D; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail167-tx2 (localhost.localdomain [127.0.0.1]) by mail167-tx2 (MessageSwitch) id 139578199996037_24991; Tue, 25 Mar 2014 21:13:19 +0000 (UTC) Received: from TX2EHSMHS011.bigfish.com (unknown [10.9.14.243]) by mail167-tx2.bigfish.com (Postfix) with ESMTP id E770A320112; Tue, 25 Mar 2014 21:13:18 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS011.bigfish.com (10.9.99.111) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Mar 2014 21:13:13 +0000 Received: from BL2PR05MB196.namprd05.prod.outlook.com (10.242.198.155) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 25 Mar 2014 21:13:12 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BL2PR05MB196.namprd05.prod.outlook.com (10.242.198.155) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 25 Mar 2014 21:13:12 +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.0898.005; Tue, 25 Mar 2014 21:13:10 +0000 From: Ross Callon To: Lou Berger , Alia Atlas Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgDBC8uAAACyXgAAAGNkgAAIfe8AAABYqYAAA79MYA== Date: Tue, 25 Mar 2014 21:13:09 +0000 Message-ID: <83cbebfa8fd443fd94c5bf009bec6dc9@CO2PR05MB636.namprd05.prod.outlook.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331D785.5030800@labn.net> In-Reply-To: <5331D785.5030800@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 01613DFDC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/GqGVOXU3YbGNB2VgVMM6LCrpXfg Cc: Adrian Farrel , Thomas Clausen , Alia Atlas , "rtg-chairs@ietf.org" , "" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 21:13:28 -0000 I think that these are the right times.=20 We could instead schedule the first review just before the call for WG adop= tion. This might allow the call for WG adoption to be based on a document w= hich is relatively more readable. However, it would need to be purely volun= tary since prior to WG adoption the document is "owned" by the authors, and= not by the WG. Chairs could optionally for document which seem to particul= arly need English language review ask the authors whether or not they would= like to move the first review to be before rather than after the call for = adoption.=20 Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, March 25, 2014 3:23 PM To: Alia Atlas Cc: Adrian Farrel; Thomas Clausen; Alia Atlas; ; rtg-chai= rs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check On 3/25/2014 3:12 PM, Alia Atlas wrote: > As far as English language mentoring, it sounds like George, Loa, and > Ross have a trial run going in MPLS. > We can discuss having common organization for volunteers on each WG's > wiki or on the routing-area wiki. > > Thoughts? > I think language review would be *hugely* helpful. Personally I'd like it to occur right *after* WG adoption and once again after the authors declare a document ready for LC (from the technical perspective).=20 Lou From nobody Tue Mar 25 14:27:09 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 394FE1A0230; Tue, 25 Mar 2014 14:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tnfiPevKXGQO; Tue, 25 Mar 2014 14:27:03 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 88F5F1A0207; Tue, 25 Mar 2014 14:27:03 -0700 (PDT) Received: from mail221-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Mar 2014 21:27:02 +0000 Received: from mail221-ch1 (localhost [127.0.0.1]) by mail221-ch1-R.bigfish.com (Postfix) with ESMTP id E6D42320298; Tue, 25 Mar 2014 21:27:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I1b0aL148cI542I1dbaI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail221-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(13464003)(479174003)(51704005)(24454002)(377454003)(85852003)(83072002)(77982001)(74316001)(4396001)(63696002)(20776003)(81542001)(97336001)(19580405001)(33646001)(66066001)(19580395003)(54316002)(56776001)(81342001)(97186001)(87266001)(59766001)(74706001)(79102001)(76796001)(69226001)(76786001)(76576001)(95416001)(98676001)(80976001)(80022001)(87936001)(65816001)(47976001)(50986001)(47736001)(49866001)(74876001)(94946001)(74502001)(54356001)(81686001)(47446002)(74662001)(93136001)(31966008)(2656002)(56816005)(95666003)(93516002)(74366001)(94316002)(86362001)(83322001)(46102001)(76482001)(92566001)(51856001)(90146001)(85306002)(53806001)(81816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB208; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:EE9BF265.83F293E1.B8DF7DBB.4AEA6370.20874; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail221-ch1 (localhost.localdomain [127.0.0.1]) by mail221-ch1 (MessageSwitch) id 139578282066121_17312; Tue, 25 Mar 2014 21:27:00 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.251]) by mail221-ch1.bigfish.com (Postfix) with ESMTP id BC6E72A00D5; Tue, 25 Mar 2014 21:26:47 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Mar 2014 21:26:47 +0000 Received: from BY2PR05MB208.namprd05.prod.outlook.com (10.242.41.142) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 25 Mar 2014 21:26:46 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BY2PR05MB208.namprd05.prod.outlook.com (10.242.41.142) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 25 Mar 2014 21:26: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.0898.005; Tue, 25 Mar 2014 21:26:44 +0000 From: Ross Callon To: "Joel M. Halpern" , Alia Atlas , Thomas Clausen Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgDBC8uAAACyXgAABd4KAAAHlSjA Date: Tue, 25 Mar 2014 21:26:43 +0000 Message-ID: <6d4791ca7767452ba7938334e5382246@CO2PR05MB636.namprd05.prod.outlook.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331C0FA.3040008@joelhalpern.com> In-Reply-To: <5331C0FA.3040008@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 01613DFDC8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/y14fkKMF-6gv6AsKUreBxJFELPI Cc: Adrian Farrel , Alia Atlas , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 21:27:07 -0000 How does this differ from the "routing area advisors" who have occasionally= been assigned to WGs in the past? In some cases these routing area advisor= s were ADs, but in some cases not. In my experience the routing area adviso= rs rarely did much (if anything).=20 It has also been unclear (at least to me) what if any authority went with b= eing the routing area advisor to a WG from another area.=20 Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. Halper= n Sent: Tuesday, March 25, 2014 1:47 PM To: Alia Atlas; Thomas Clausen Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; Subject: Re: [RTG-DIR] Routing Area Health Check I am a little concerned that assigned directorate members to working=20 groups will produce negative effects: 1) It will lead to more scheduling conflict. 2) It will lead to an assumption that this one person will review all=20 the output of a given WG. I think we are actually better off if that=20 task sometimes moves, as it ensures that fresh eyes are looking, for=20 example to detect that assumptions are actually stated rather than=20 merely in the minds of the WG. Yours, Joel On 3/25/14, 10:58 AM, Alia Atlas wrote: > Thomas, > > Thanks very much for your thoughts. On the being underutilized and on > cross-area review, what do you and others in the Routing Directorate > think about being asked to follow a single additional working group that > is not in RTG and may have routing related issues? > > For the time speedup of ADs, I'm told that it'd be really really useful > to have more active document shepherds - who can facilitate getting > comments and having them addressed. I'm not sure how to put that into > place really. As a WG chair, I felt like I was processing and pushing > few enough drafts that I could do the shepherd job also - but I know > that there are some WGs where there is higher throughput. It's also a > good way of growing a person, to let them see the whole process and deal > with the discussions. > > For the drafts, I'd love to see earlier reviews. I'm not sure if at WG > adoption is quite the right time, but it is a good approximation of > "early in the process". We could ask WG chairs to request a reviewer > at that point for drafts that may need it and see what the load looks > like. For a start-up, having interested WG chairs identify WG drafts > that could benefit from review would be helpful/interesting in terms of > seeing the workload. > > Regards, > Alia > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > > wrote: > > Hello ADs, Directorate, Chairs, > > Interesting questions, thanks for caring and asking. > > I am probably going to cut my answer into separate independent > mails, as there are vastly different topics in this question. > > First, as a member of the RTG Directorate, I actually feel a little > "under-utilized". An occasional review of an I-D at an extremely > late state of its process, and a very rare more global question like > this. As has been discussed widely lately, ADs are overworked and > have too little time, so perhaps they do not call on the directorate > enough - and, also, delegation of tasks that the ADs have to do is > probably perceived as rather hard. > > I've been dumbfounded by some of the reviews I have seen from ADs, > either during AD Evaluation or IESG Reviews: one particular case > came to mind where Adrian sent what looked like a 10-page > DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't > matter what document or WG it was, what matters is that (i) it > doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) > there wasn't really something in the DISCUSS/COMMENTs that required > the wizardry of a yellow dot (just some routing background), and -- > most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during > IESG Evaluation really isn't helpful to the document authors...its > late, design decisions have been made, which are being questioned, > etc....it tires people out, pisses off authors, and frustrates > everybody involved. > > So, I've been playing around with a couple of ideas on the sideline, > unofficially, and with only unwitting assistance from others > involved.... > > Thought #1: > I-Ds - when called for adoption as WG documents, or when published > as draft-ietf-...-00's, gets someone from the directorate assigned, > to provide an initial review and thoughts on "what directions would > be good to take (or avoid) here". That same reviewer can, > occasionally, be invoked by the WG chairs or authors, in the "so, > did we catch this right?" -- and, of course, should be called in on > the WGLC of the document. I think of it a little as the "area > advisors" but to a document rather than a WG as a whole. > > I've been playing around with that a bit, as an author: > > o Since I know very little about security, I've > looped in somebody who did, when > having published a -00, and again the same person > as needed later in the process. > I've gotten hugely valuable feedback - making the > ultimate SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how > little I knew about security, presumably > less frustrating/time-consuming for the ADs, too, > than if I had been just shooting blind). > > o Since I know even less about OPS stuff, Adrian > looped an OPS guy in on an > individual -01, who asked a lot of good questions > to what we were doing, and why, > and which is hugely helpful. > > As an author in the RTG Area, the SEC and OPS ADs are often real > "roadblocks". Reasonably so, of course, they represent important > concerns. And gosh, every time I encounter any AD, I have to explain > the whole context over once again since, even if they've already > gotten the story once, they have to follow sufficiently many > documents and topics that something is bound to be flushed from > their cache. > > Having someone, from the respective directorate, be more of a > facilitator, sparring-partner, and who - over time - follows the > document (and, presumably, follows much fewer documents > concurrently) through the process with the authors would be great, > as an author. And possibly makes the ADs encounter less poor document= s. > > I know that Adrian can (cf. the aforementioned 10-page > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS > folks, and I have no reason to not expect Alia to have the same high > (or higher) standards....so I imagine that a way the RTG-DIR could > help "improve the image of the ADs" and at the same time get the ADs > time liberated from writing 10-page discusses, would be something > like the above.... > > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the > directorateS to a document > o this, through the documents lifecycle. > > Not sure if it scales, either, but as an author I've greatly enjoyed > having such a "ongoing relationship" with people helping me avoid > pitfalls. > > A final note: having been around for a while in the IETF, it is > really easy to ask around for help from among other IETFers that one > knows -- then again, having been around for a while, presumably one > has more experience and needs less help in avoiding pitfalls. For a > new(ish) author, who knows few people and who presumably might be > likely to need more help in avoiding said pitfalls, it's a lot > harder to actually reach out and get the right people's eyes on a > document -- and, even to know what eyes are good to get on it. > > This might, actually, therefore be also a good way of the IETF to be > more welcoming and inclusive to new folks wanting to get involved. > > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > version of thought #1 is to have a more structure directorate review > cycle during IETF LC, or perhaps during "Publication Requested" and > before "AD Evaluation". I am thinking that these be of the form: an > I-D hits the AD, the responsible/sponsoring AD requests directorate > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, > TSP, ...). Authors and reviewer iterate until either (i) issues are > squared off or (ii) either authors or reviewer declare the other as > "bat-crap-crazy" (or, complains that the other side is not > responsive) and raise the issue to the AD. AD moves the document > forward to "AD Evaluation" only once happy with the outcome of > directorate reviews. In short, hiving out a lot more of the "problem > fixing" that happens during these reviews off to the directorates - > and leaving ADs to process presumably "less broken" documents. > > As an author, I have actually found it a LOT easier/faster to > iterate with a directorate reviewer (who has my document fresh in > mind), than with an AD who's preoccupied with a dozen or so > documents at the same time, and other emergencies. Now, mind you, > some ADs are good at saying "Busy, will come back to you in n days" > -- others, alas, do "play dead" if they feel they have more > important fish to fry, and that's frustrating. > > This might lessen the load on the ADs, but still has the > disadvantage that one gets feedback *very* late in the > process....just a little bit earlier than during IESG processing. > > Thought #3: > I thought it's worth calling out, that either of the above are not > really related to RTG documents: I should think that RTG WG Chairs > are plenty able to do the necessary during WG processing, and as an > author in the RTG Area, I do usually know how to grab someone > competent from the same area for advice, as needed. While doing > something like this intra-area can be a good thing, the real boast > that I, as document author, have felt has been through getting > cross-area feedback. Just as (being forced to be) reviewing document > outside of the RTG area has been hugely educational and. > > Cheers, > > Thomas > > > On 21 Mar 2014, at 19:31, Adrian Farrel > wrote: > > > Hello Directorate and WG chairs, > > > > Alia and I have been discussing the Routing Area, its work, its > output, and its > > working groups. > > > > We have reached a conclusion (which perhaps we should have come > to sooner) that > > we need your help and input. > > > > The crunch question for us is "What makes it hard to get work > done in the > > Routing Area?" What gets in the way of your work? What is making > life hard for > > document authors? How could working groups be doing better? We > are open to all > > and every type of answer. We are happy to have quick, one-line > answers or > > deeply-considered essays. > > > > What do you think? > > > > Thanks for all your input, > > Adrian and Alia > > > > PS Please respond to both aliases because not everyone is on both > lists. Sorry > > that that means some of you will get duplicates. > > > > From nobody Tue Mar 25 20:52:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65E1A00A7; Tue, 25 Mar 2014 20:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6kz5laWFPgGS; Tue, 25 Mar 2014 20:52:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5DA1A0083; Tue, 25 Mar 2014 20:52:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEY28360; Wed, 26 Mar 2014 03:52:11 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 03:51:45 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 03:52:09 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 11:52:05 +0800 From: Mach Chen To: "Joel M. Halpern" , Alia Atlas , Thomas Clausen Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgCwSEOAAACyXgAABd4JAAAljK2w Date: Wed, 26 Mar 2014 03:52:03 +0000 Message-ID: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331C0FA.3040008@joelhalpern.com> In-Reply-To: <5331C0FA.3040008@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] 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/rtg-dir/IahHAsPX3IdH7-gtwMISJeT0hIU Cc: Adrian Farrel , Alia Atlas , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 03:52:18 -0000 Hi all, IMHO, to make the directorate members to do more reviews in early stage is = great idea, maybe we do not need to "officially" assign directorate members= to working groups, but just encourage the directorate members to do the re= view when received the request from RTG WGs. Best regards, Mach > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. Halp= ern > Sent: Wednesday, March 26, 2014 1:47 AM > To: Alia Atlas; Thomas Clausen > Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; > Subject: Re: [RTG-DIR] Routing Area Health Check >=20 > I am a little concerned that assigned directorate members to working grou= ps will > produce negative effects: > 1) It will lead to more scheduling conflict. > 2) It will lead to an assumption that this one person will review all the= output of a > given WG. I think we are actually better off if that task sometimes move= s, as it > ensures that fresh eyes are looking, for example to detect that assumptio= ns are > actually stated rather than merely in the minds of the WG. >=20 > Yours, > Joel >=20 > On 3/25/14, 10:58 AM, Alia Atlas wrote: > > Thomas, > > > > Thanks very much for your thoughts. On the being underutilized and on > > cross-area review, what do you and others in the Routing Directorate > > think about being asked to follow a single additional working group > > that is not in RTG and may have routing related issues? > > > > For the time speedup of ADs, I'm told that it'd be really really > > useful to have more active document shepherds - who can facilitate > > getting comments and having them addressed. I'm not sure how to put > > that into place really. As a WG chair, I felt like I was processing > > and pushing few enough drafts that I could do the shepherd job also - > > but I know that there are some WGs where there is higher throughput. > > It's also a good way of growing a person, to let them see the whole > > process and deal with the discussions. > > > > For the drafts, I'd love to see earlier reviews. I'm not sure if at > > WG adoption is quite the right time, but it is a good approximation of > > "early in the process". We could ask WG chairs to request a reviewer > > at that point for drafts that may need it and see what the load looks > > like. For a start-up, having interested WG chairs identify WG drafts > > that could benefit from review would be helpful/interesting in terms > > of seeing the workload. > > > > Regards, > > Alia > > > > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > > > wrote: > > > > Hello ADs, Directorate, Chairs, > > > > Interesting questions, thanks for caring and asking. > > > > I am probably going to cut my answer into separate independent > > mails, as there are vastly different topics in this question. > > > > First, as a member of the RTG Directorate, I actually feel a little > > "under-utilized". An occasional review of an I-D at an extremely > > late state of its process, and a very rare more global question lik= e > > this. As has been discussed widely lately, ADs are overworked and > > have too little time, so perhaps they do not call on the directorat= e > > enough - and, also, delegation of tasks that the ADs have to do is > > probably perceived as rather hard. > > > > I've been dumbfounded by some of the reviews I have seen from ADs, > > either during AD Evaluation or IESG Reviews: one particular case > > came to mind where Adrian sent what looked like a 10-page > > DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't > > matter what document or WG it was, what matters is that (i) it > > doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) > > there wasn't really something in the DISCUSS/COMMENTs that required > > the wizardry of a yellow dot (just some routing background), and -- > > most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during > > IESG Evaluation really isn't helpful to the document authors...its > > late, design decisions have been made, which are being questioned, > > etc....it tires people out, pisses off authors, and frustrates > > everybody involved. > > > > So, I've been playing around with a couple of ideas on the sideline= , > > unofficially, and with only unwitting assistance from others > > involved.... > > > > Thought #1: > > I-Ds - when called for adoption as WG documents, or when published > > as draft-ietf-...-00's, gets someone from the directorate assigned, > > to provide an initial review and thoughts on "what directions would > > be good to take (or avoid) here". That same reviewer can, > > occasionally, be invoked by the WG chairs or authors, in the "so, > > did we catch this right?" -- and, of course, should be called in on > > the WGLC of the document. I think of it a little as the "area > > advisors" but to a document rather than a WG as a whole. > > > > I've been playing around with that a bit, as an author: > > > > o Since I know very little about security, I've > > looped in somebody who did, when > > having published a -00, and again the same person > > as needed later in the process. > > I've gotten hugely valuable feedback - making the > > ultimate SEC-DIR and SEC-AD > > reviews a lot less painful for me (and, given how > > little I knew about security, presumably > > less frustrating/time-consuming for the ADs, too, > > than if I had been just shooting blind). > > > > o Since I know even less about OPS stuff, Adrian > > looped an OPS guy in on an > > individual -01, who asked a lot of good questions > > to what we were doing, and why, > > and which is hugely helpful. > > > > As an author in the RTG Area, the SEC and OPS ADs are often real > > "roadblocks". Reasonably so, of course, they represent important > > concerns. And gosh, every time I encounter any AD, I have to explai= n > > the whole context over once again since, even if they've already > > gotten the story once, they have to follow sufficiently many > > documents and topics that something is bound to be flushed from > > their cache. > > > > Having someone, from the respective directorate, be more of a > > facilitator, sparring-partner, and who - over time - follows the > > document (and, presumably, follows much fewer documents > > concurrently) through the process with the authors would be great, > > as an author. And possibly makes the ADs encounter less poor docume= nts. > > > > I know that Adrian can (cf. the aforementioned 10-page > > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS > > folks, and I have no reason to not expect Alia to have the same hig= h > > (or higher) standards....so I imagine that a way the RTG-DIR could > > help "improve the image of the ADs" and at the same time get the AD= s > > time liberated from writing 10-page discusses, would be something > > like the above.... > > > > In short, what I envision is a structured way of getting: > > o very early-reviews > > o a semi-permanent attachment of a reviewer from the > > directorateS to a document > > o this, through the documents lifecycle. > > > > Not sure if it scales, either, but as an author I've greatly enjoye= d > > having such a "ongoing relationship" with people helping me avoid > > pitfalls. > > > > A final note: having been around for a while in the IETF, it is > > really easy to ask around for help from among other IETFers that on= e > > knows -- then again, having been around for a while, presumably one > > has more experience and needs less help in avoiding pitfalls. For a > > new(ish) author, who knows few people and who presumably might be > > likely to need more help in avoiding said pitfalls, it's a lot > > harder to actually reach out and get the right people's eyes on a > > document -- and, even to know what eyes are good to get on it. > > > > This might, actually, therefore be also a good way of the IETF to b= e > > more welcoming and inclusive to new folks wanting to get involved. > > > > Thought #2: > > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > > version of thought #1 is to have a more structure directorate revie= w > > cycle during IETF LC, or perhaps during "Publication Requested" and > > before "AD Evaluation". I am thinking that these be of the form: an > > I-D hits the AD, the responsible/sponsoring AD requests directorate > > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, > > TSP, ...). Authors and reviewer iterate until either (i) issues are > > squared off or (ii) either authors or reviewer declare the other as > > "bat-crap-crazy" (or, complains that the other side is not > > responsive) and raise the issue to the AD. AD moves the document > > forward to "AD Evaluation" only once happy with the outcome of > > directorate reviews. In short, hiving out a lot more of the "proble= m > > fixing" that happens during these reviews off to the directorates - > > and leaving ADs to process presumably "less broken" documents. > > > > As an author, I have actually found it a LOT easier/faster to > > iterate with a directorate reviewer (who has my document fresh in > > mind), than with an AD who's preoccupied with a dozen or so > > documents at the same time, and other emergencies. Now, mind you, > > some ADs are good at saying "Busy, will come back to you in n days" > > -- others, alas, do "play dead" if they feel they have more > > important fish to fry, and that's frustrating. > > > > This might lessen the load on the ADs, but still has the > > disadvantage that one gets feedback *very* late in the > > process....just a little bit earlier than during IESG processing. > > > > Thought #3: > > I thought it's worth calling out, that either of the above are not > > really related to RTG documents: I should think that RTG WG Chairs > > are plenty able to do the necessary during WG processing, and as an > > author in the RTG Area, I do usually know how to grab someone > > competent from the same area for advice, as needed. While doing > > something like this intra-area can be a good thing, the real boast > > that I, as document author, have felt has been through getting > > cross-area feedback. Just as (being forced to be) reviewing documen= t > > outside of the RTG area has been hugely educational and. > > > > Cheers, > > > > Thomas > > > > > > On 21 Mar 2014, at 19:31, Adrian Farrel > > wrote: > > > > > Hello Directorate and WG chairs, > > > > > > Alia and I have been discussing the Routing Area, its work, its > > output, and its > > > working groups. > > > > > > We have reached a conclusion (which perhaps we should have come > > to sooner) that > > > we need your help and input. > > > > > > The crunch question for us is "What makes it hard to get work > > done in the > > > Routing Area?" What gets in the way of your work? What is making > > life hard for > > > document authors? How could working groups be doing better? We > > are open to all > > > and every type of answer. We are happy to have quick, one-line > > answers or > > > deeply-considered essays. > > > > > > What do you think? > > > > > > Thanks for all your input, > > > Adrian and Alia > > > > > > PS Please respond to both aliases because not everyone is on bot= h > > lists. Sorry > > > that that means some of you will get duplicates. > > > > > > > From nobody Wed Mar 26 05:47:39 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC841A0089; Wed, 26 Mar 2014 05:47:38 -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 ont_Nfen_NpN; Wed, 26 Mar 2014 05:47:34 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DABB91A00DC; Wed, 26 Mar 2014 05:47:33 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so2002906yho.29 for ; Wed, 26 Mar 2014 05:47: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=26WoDaK/dw36grjP35jr6LWjmKC9dN2k7WC2Oye4K4s=; b=ednjZScBkgFsSwyK52iHV6bQzo+XRTjfyXfXS8eEhAj+wTHwV788tjoQ4lt7zdxalg B2vHa7qJASC2XnJUOUsHom66lTIstEHvSh2tBEbSyhix1YzujnXKX9Xf9VhQUw0r+css pK0L6lKcfYz9VVUXFFamP2aQMSd/CDTURNvWbZFOT4RMjmlSbK8i1mqWg/9bCQGoNlyN AdlKe43R1gYkGttWrjhfRHJzMTBOnbKIIlo6YrjGvq3j1dXr8Iuk51HtNVFixsW0KVnp 5BxoQAFgCwBocUSVasgTilJ2x9CyS6JCH/PjiaEq0Mi46iqbNnl4QeIB6fICaG1YGkD0 FabQ== MIME-Version: 1.0 X-Received: by 10.236.18.227 with SMTP id l63mr12860948yhl.101.1395838052299; Wed, 26 Mar 2014 05:47:32 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Wed, 26 Mar 2014 05:47:32 -0700 (PDT) In-Reply-To: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331C0FA.3040008@joelhalpern.com> Date: Wed, 26 Mar 2014 08:47:32 -0400 Message-ID: From: Alia Atlas To: Mach Chen Content-Type: multipart/alternative; boundary=089e0122a64a45785a04f581dfb4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/1I7zGyCoMQvv44kehTqqD5e3hdM Cc: "" , Thomas Clausen , Alia Atlas , "rtg-chairs@ietf.org" , Adrian Farrel , "Joel M. Halpern" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:47:38 -0000 --089e0122a64a45785a04f581dfb4 Content-Type: text/plain; charset=ISO-8859-1 Mach, The discussion of asking a directorate member to pay attention to a WG list is for WGs outside the area and doesn't imply reviewing that WGs drafts - just giving a heads-up. Alia On Tue, Mar 25, 2014 at 11:52 PM, Mach Chen wrote: > Hi all, > > IMHO, to make the directorate members to do more reviews in early stage is > great idea, maybe we do not need to "officially" assign directorate members > to working groups, but just encourage the directorate members to do the > review when received the request from RTG WGs. > > Best regards, > Mach > > > -----Original Message----- > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. > Halpern > > Sent: Wednesday, March 26, 2014 1:47 AM > > To: Alia Atlas; Thomas Clausen > > Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; > > Subject: Re: [RTG-DIR] Routing Area Health Check > > > > I am a little concerned that assigned directorate members to working > groups will > > produce negative effects: > > 1) It will lead to more scheduling conflict. > > 2) It will lead to an assumption that this one person will review all > the output of a > > given WG. I think we are actually better off if that task sometimes > moves, as it > > ensures that fresh eyes are looking, for example to detect that > assumptions are > > actually stated rather than merely in the minds of the WG. > > > > Yours, > > Joel > > > > On 3/25/14, 10:58 AM, Alia Atlas wrote: > > > Thomas, > > > > > > Thanks very much for your thoughts. On the being underutilized and on > > > cross-area review, what do you and others in the Routing Directorate > > > think about being asked to follow a single additional working group > > > that is not in RTG and may have routing related issues? > > > > > > For the time speedup of ADs, I'm told that it'd be really really > > > useful to have more active document shepherds - who can facilitate > > > getting comments and having them addressed. I'm not sure how to put > > > that into place really. As a WG chair, I felt like I was processing > > > and pushing few enough drafts that I could do the shepherd job also - > > > but I know that there are some WGs where there is higher throughput. > > > It's also a good way of growing a person, to let them see the whole > > > process and deal with the discussions. > > > > > > For the drafts, I'd love to see earlier reviews. I'm not sure if at > > > WG adoption is quite the right time, but it is a good approximation of > > > "early in the process". We could ask WG chairs to request a reviewer > > > at that point for drafts that may need it and see what the load looks > > > like. For a start-up, having interested WG chairs identify WG drafts > > > that could benefit from review would be helpful/interesting in terms > > > of seeing the workload. > > > > > > Regards, > > > Alia > > > > > > > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > > > > wrote: > > > > > > Hello ADs, Directorate, Chairs, > > > > > > Interesting questions, thanks for caring and asking. > > > > > > I am probably going to cut my answer into separate independent > > > mails, as there are vastly different topics in this question. > > > > > > First, as a member of the RTG Directorate, I actually feel a little > > > "under-utilized". An occasional review of an I-D at an extremely > > > late state of its process, and a very rare more global question > like > > > this. As has been discussed widely lately, ADs are overworked and > > > have too little time, so perhaps they do not call on the > directorate > > > enough - and, also, delegation of tasks that the ADs have to do is > > > probably perceived as rather hard. > > > > > > I've been dumbfounded by some of the reviews I have seen from ADs, > > > either during AD Evaluation or IESG Reviews: one particular case > > > came to mind where Adrian sent what looked like a 10-page > > > DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't > > > matter what document or WG it was, what matters is that (i) it > > > doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) > > > there wasn't really something in the DISCUSS/COMMENTs that required > > > the wizardry of a yellow dot (just some routing background), and -- > > > most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during > > > IESG Evaluation really isn't helpful to the document authors...its > > > late, design decisions have been made, which are being questioned, > > > etc....it tires people out, pisses off authors, and frustrates > > > everybody involved. > > > > > > So, I've been playing around with a couple of ideas on the > sideline, > > > unofficially, and with only unwitting assistance from others > > > involved.... > > > > > > Thought #1: > > > I-Ds - when called for adoption as WG documents, or when published > > > as draft-ietf-...-00's, gets someone from the directorate assigned, > > > to provide an initial review and thoughts on "what directions would > > > be good to take (or avoid) here". That same reviewer can, > > > occasionally, be invoked by the WG chairs or authors, in the "so, > > > did we catch this right?" -- and, of course, should be called in on > > > the WGLC of the document. I think of it a little as the "area > > > advisors" but to a document rather than a WG as a whole. > > > > > > I've been playing around with that a bit, as an author: > > > > > > o Since I know very little about security, I've > > > looped in somebody who did, when > > > having published a -00, and again the same person > > > as needed later in the process. > > > I've gotten hugely valuable feedback - making the > > > ultimate SEC-DIR and SEC-AD > > > reviews a lot less painful for me (and, given how > > > little I knew about security, presumably > > > less frustrating/time-consuming for the ADs, too, > > > than if I had been just shooting blind). > > > > > > o Since I know even less about OPS stuff, Adrian > > > looped an OPS guy in on an > > > individual -01, who asked a lot of good questions > > > to what we were doing, and why, > > > and which is hugely helpful. > > > > > > As an author in the RTG Area, the SEC and OPS ADs are often real > > > "roadblocks". Reasonably so, of course, they represent important > > > concerns. And gosh, every time I encounter any AD, I have to > explain > > > the whole context over once again since, even if they've already > > > gotten the story once, they have to follow sufficiently many > > > documents and topics that something is bound to be flushed from > > > their cache. > > > > > > Having someone, from the respective directorate, be more of a > > > facilitator, sparring-partner, and who - over time - follows the > > > document (and, presumably, follows much fewer documents > > > concurrently) through the process with the authors would be great, > > > as an author. And possibly makes the ADs encounter less poor > documents. > > > > > > I know that Adrian can (cf. the aforementioned 10-page > > > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS > > > folks, and I have no reason to not expect Alia to have the same > high > > > (or higher) standards....so I imagine that a way the RTG-DIR could > > > help "improve the image of the ADs" and at the same time get the > ADs > > > time liberated from writing 10-page discusses, would be something > > > like the above.... > > > > > > In short, what I envision is a structured way of getting: > > > o very early-reviews > > > o a semi-permanent attachment of a reviewer from the > > > directorateS to a document > > > o this, through the documents lifecycle. > > > > > > Not sure if it scales, either, but as an author I've greatly > enjoyed > > > having such a "ongoing relationship" with people helping me avoid > > > pitfalls. > > > > > > A final note: having been around for a while in the IETF, it is > > > really easy to ask around for help from among other IETFers that > one > > > knows -- then again, having been around for a while, presumably one > > > has more experience and needs less help in avoiding pitfalls. For a > > > new(ish) author, who knows few people and who presumably might be > > > likely to need more help in avoiding said pitfalls, it's a lot > > > harder to actually reach out and get the right people's eyes on a > > > document -- and, even to know what eyes are good to get on it. > > > > > > This might, actually, therefore be also a good way of the IETF to > be > > > more welcoming and inclusive to new folks wanting to get involved. > > > > > > Thought #2: > > > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > > > version of thought #1 is to have a more structure directorate > review > > > cycle during IETF LC, or perhaps during "Publication Requested" and > > > before "AD Evaluation". I am thinking that these be of the form: an > > > I-D hits the AD, the responsible/sponsoring AD requests directorate > > > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, > > > TSP, ...). Authors and reviewer iterate until either (i) issues are > > > squared off or (ii) either authors or reviewer declare the other as > > > "bat-crap-crazy" (or, complains that the other side is not > > > responsive) and raise the issue to the AD. AD moves the document > > > forward to "AD Evaluation" only once happy with the outcome of > > > directorate reviews. In short, hiving out a lot more of the > "problem > > > fixing" that happens during these reviews off to the directorates - > > > and leaving ADs to process presumably "less broken" documents. > > > > > > As an author, I have actually found it a LOT easier/faster to > > > iterate with a directorate reviewer (who has my document fresh in > > > mind), than with an AD who's preoccupied with a dozen or so > > > documents at the same time, and other emergencies. Now, mind you, > > > some ADs are good at saying "Busy, will come back to you in n days" > > > -- others, alas, do "play dead" if they feel they have more > > > important fish to fry, and that's frustrating. > > > > > > This might lessen the load on the ADs, but still has the > > > disadvantage that one gets feedback *very* late in the > > > process....just a little bit earlier than during IESG processing. > > > > > > Thought #3: > > > I thought it's worth calling out, that either of the above are not > > > really related to RTG documents: I should think that RTG WG Chairs > > > are plenty able to do the necessary during WG processing, and as an > > > author in the RTG Area, I do usually know how to grab someone > > > competent from the same area for advice, as needed. While doing > > > something like this intra-area can be a good thing, the real boast > > > that I, as document author, have felt has been through getting > > > cross-area feedback. Just as (being forced to be) reviewing > document > > > outside of the RTG area has been hugely educational and. > > > > > > Cheers, > > > > > > Thomas > > > > > > > > > On 21 Mar 2014, at 19:31, Adrian Farrel > > > wrote: > > > > > > > Hello Directorate and WG chairs, > > > > > > > > Alia and I have been discussing the Routing Area, its work, its > > > output, and its > > > > working groups. > > > > > > > > We have reached a conclusion (which perhaps we should have come > > > to sooner) that > > > > we need your help and input. > > > > > > > > The crunch question for us is "What makes it hard to get work > > > done in the > > > > Routing Area?" What gets in the way of your work? What is making > > > life hard for > > > > document authors? How could working groups be doing better? We > > > are open to all > > > > and every type of answer. We are happy to have quick, one-line > > > answers or > > > > deeply-considered essays. > > > > > > > > What do you think? > > > > > > > > Thanks for all your input, > > > > Adrian and Alia > > > > > > > > PS Please respond to both aliases because not everyone is on > both > > > lists. Sorry > > > > that that means some of you will get duplicates. > > > > > > > > > > > > --089e0122a64a45785a04f581dfb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mach,

The discussion of asking a direct= orate member to pay attention to a WG list is for WGs outside the area and = doesn't
imply reviewing that WGs drafts - just giving a heads= -up.

Alia


On Tue, Mar 25, 2014 at 11:52 PM, Mach Chen <mac= h.chen@huawei.com> wrote:
Hi all,

IMHO, to make the directorate members to do more reviews in early stage is = great idea, maybe we do not need to "officially" assign directora= te members to working groups, but just encourage the directorate members to= do the review when received the request from RTG WGs.

Best regards,
Mach

> -----Original Message-----
> From: rtg-dir [mailto:rtg-= dir-bounces@ietf.org] On Behalf Of Joel M. Halpern
> Sent: Wednesday, March 26, 2014 1:47 AM=
> To: Alia Atlas; Thomas Clausen
> Cc: Adrian Farrel; rtg-chairs@i= etf.org; Alia Atlas; <rtg-dir@ie= tf.org>
> Subject: Re: [RTG-DIR] Routing Area Health Check
>
> I am a little concerned = that assigned directorate members to working groups will
> produce negative effects:
> 1) It will lead to more scheduling conflict.
> 2) It will lead to an assumption that this one person will review all = the output of a
> given WG. =A0I think we are actually better off if that task sometimes= moves, as it
> ensures that fresh eyes are looking, for example to detect that assump= tions are
> actually stated rather than merely in the minds of the WG.
>
> Yours,
> Joel
>
> On 3/25/14, 10:58 AM, Alia Atlas wrote:
> > Thomas,
> >
> > Thanks very much for your thoughts. =A0On the being underutilized= and on
> > cross-area review, what do you and others in the Routing Director= ate
> > think about being asked to follow a single additional working gro= up
> > that is not in RTG and may have routing related issues?
> >
> > For the time speedup of ADs, I'm told that it'd be really= really
> > useful to have more active document shepherds - who can facilitat= e
> > getting comments and having them addressed. =A0I'm not sure h= ow to put
> > that into place really. =A0As a WG chair, I felt like I was proce= ssing
> > and pushing few enough drafts that I could do the shepherd job al= so -
> > but I know that there are some WGs where there is higher throughp= ut.
> > It's also a good way of growing a person, to let them see the= whole
> > process and deal with the discussions.
> >
> > For the drafts, I'd love to see earlier reviews. =A0I'm n= ot sure if at
> > WG adoption is quite the right time, but it is a good approximati= on of
> > "early in the process". =A0 We could ask WG chairs to r= equest a reviewer
> > at that point for drafts that may need it and see what the load l= ooks
> > like. =A0For a start-up, having interested WG chairs identify WG = drafts
> > that could benefit from review would be helpful/interesting in te= rms
> > of seeing the workload.
> >
> > Regards,
> > Alia
> >
> >
> > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen
> > <thomas@thomasclau= sen.org <mailto:thomas@t= homasclausen.org>> wrote:
> >
> > =A0 =A0 Hello ADs, Directorate, Chairs,
> >
> > =A0 =A0 Interesting questions, thanks for caring and asking.
> >
> > =A0 =A0 I am probably going to cut my answer into separate indepe= ndent
> > =A0 =A0 mails, as there are vastly different topics in this quest= ion.
> >
> > =A0 =A0 First, as a member of the RTG Directorate, I actually fee= l a little
> > =A0 =A0 "under-utilized". An occasional review of an I-= D at an extremely
> > =A0 =A0 late state of its process, and a very rare more global qu= estion like
> > =A0 =A0 this. As has been discussed widely lately, ADs are overwo= rked and
> > =A0 =A0 have too little time, so perhaps they do not call on the = directorate
> > =A0 =A0 enough - and, also, delegation of tasks that the ADs have= to do is
> > =A0 =A0 probably perceived as rather hard.
> >
> > =A0 =A0 I've been dumbfounded by some of the reviews I have s= een from ADs,
> > =A0 =A0 either during AD Evaluation or IESG Reviews: one particul= ar case
> > =A0 =A0 came to mind where Adrian sent what looked like a 10-page=
> > =A0 =A0 DISCUSS/COMMENT to the tracker during IESG Evaluation. It= doesn't
> > =A0 =A0 matter what document or WG it was, what matters is that (= i) it
> > =A0 =A0 doesn't scale IETF-wide, (ii) it's poor use of Ad= rian's time, (iii)
> > =A0 =A0 there wasn't really something in the DISCUSS/COMMENTs= that required
> > =A0 =A0 the wizardry of a yellow dot (just some routing backgroun= d), and --
> > =A0 =A0 most importantly -- (iv) getting a 10-page DISCUSS/COMMEN= T during
> > =A0 =A0 IESG Evaluation really isn't helpful to the document = authors...its
> > =A0 =A0 late, design decisions have been made, which are being qu= estioned,
> > =A0 =A0 etc....it tires people out, pisses off authors, and frust= rates
> > =A0 =A0 everybody involved.
> >
> > =A0 =A0 So, I've been playing around with a couple of ideas o= n the sideline,
> > =A0 =A0 unofficially, and with only unwitting assistance from oth= ers
> > =A0 =A0 involved....
> >
> > =A0 =A0 Thought #1:
> > =A0 =A0 I-Ds - when called for adoption as WG documents, or when = published
> > =A0 =A0 as draft-ietf-...-00's, gets someone from the directo= rate assigned,
> > =A0 =A0 to provide an initial review and thoughts on "what d= irections would
> > =A0 =A0 be good to take (or avoid) here". That same reviewer= can,
> > =A0 =A0 occasionally, be invoked by the WG chairs or authors, in = the "so,
> > =A0 =A0 did we catch this right?" -- and, of course, should = be called in on
> > =A0 =A0 the WGLC of the document. I think of it a little as the &= quot;area
> > =A0 =A0 advisors" but to a document rather than a WG as a wh= ole.
> >
> > =A0 =A0 I've been playing around with that a bit, as an autho= r:
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 Since I know very little= about security, I've
> > =A0 =A0 looped in somebody who did, when
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0having published a -00= , and again the same person
> > =A0 =A0 as needed later in the process.
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I've gotten =A0hug= ely valuable feedback - making the
> > =A0 =A0 ultimate SEC-DIR and SEC-AD
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0reviews a lot =A0less = painful for me (and, given how
> > =A0 =A0 little I knew about security, presumably
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0less =A0frustrating/ti= me-consuming for the ADs, too,
> > =A0 =A0 than if I had been just shooting blind).
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 Since I know even less a= bout OPS stuff, Adrian
> > =A0 =A0 looped an OPS guy in on an
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0individual -01, who as= ked a lot of good questions
> > =A0 =A0 to what we were doing, and why,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and which is hugely he= lpful.
> >
> > =A0 =A0 As an author in the RTG Area, the SEC and OPS ADs are oft= en real
> > =A0 =A0 "roadblocks". Reasonably so, of course, they re= present important
> > =A0 =A0 concerns. And gosh, every time I encounter any AD, I have= to explain
> > =A0 =A0 the whole context over once again since, even if they'= ;ve already
> > =A0 =A0 gotten the story once, they have to follow sufficiently m= any
> > =A0 =A0 documents and topics that something is bound to be flushe= d from
> > =A0 =A0 their cache.
> >
> > =A0 =A0 Having someone, from the respective directorate, be more = of a
> > =A0 =A0 facilitator, sparring-partner, and who - over time - foll= ows the
> > =A0 =A0 document (and, presumably, follows much fewer documents > > =A0 =A0 concurrently) through the process with the authors would = be great,
> > =A0 =A0 as an author. And possibly makes the ADs encounter less p= oor documents.
> >
> > =A0 =A0 I know that Adrian can (cf. the aforementioned 10-page > > =A0 =A0 DISCUSS/COMMENT) be just as much of a roadblock as the SE= C/OPS
> > =A0 =A0 folks, and I have no reason to not expect Alia to have th= e same high
> > =A0 =A0 (or higher) standards....so I imagine that a way the RTG-= DIR could
> > =A0 =A0 help "improve the image of the ADs" and at the = same time get the ADs
> > =A0 =A0 time liberated from writing 10-page discusses, would be s= omething
> > =A0 =A0 like the above....
> >
> > =A0 =A0 In short, what I envision is a structured way of getting:=
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 very early-reviews
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 a semi-permanent attachm= ent of a reviewer from the
> > =A0 =A0 directorateS to a document
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0o =A0 =A0 =A0 this, through the docume= nts lifecycle.
> >
> > =A0 =A0 Not sure if it scales, either, but as an author I've = greatly enjoyed
> > =A0 =A0 having such a "ongoing relationship" with peopl= e helping me avoid
> > =A0 =A0 pitfalls.
> >
> > =A0 =A0 A final note: having been around for a while in the IETF,= it is
> > =A0 =A0 really easy to ask around for help from among other IETFe= rs that one
> > =A0 =A0 knows -- then again, having been around for a while, pres= umably one
> > =A0 =A0 has more experience and needs less help in avoiding pitfa= lls. For a
> > =A0 =A0 new(ish) author, who knows few people and who presumably = might be
> > =A0 =A0 likely to need more help in avoiding said pitfalls, it= 9;s a lot
> > =A0 =A0 harder to actually reach out and get the right people'= ;s eyes on a
> > =A0 =A0 document -- and, even to know what eyes are good to get o= n it.
> >
> > =A0 =A0 This might, actually, therefore be also a good way of the= IETF to be
> > =A0 =A0 more welcoming and inclusive to new folks wanting to get = involved.
> >
> > =A0 =A0 Thought #2:
> > =A0 =A0 So back to Adrian's 10-page DISCUSS/COMMENT....a, per= haps, lighter
> > =A0 =A0 version of thought #1 is to have a more structure directo= rate review
> > =A0 =A0 cycle during IETF LC, or perhaps during "Publication= Requested" and
> > =A0 =A0 before "AD Evaluation". I am thinking that thes= e be of the form: an
> > =A0 =A0 I-D hits the AD, the responsible/sponsoring AD requests d= irectorate
> > =A0 =A0 reviews from all the concerned directorates (GEN, SEC, OP= S, RTG,
> > =A0 =A0 TSP, ...). Authors and reviewer iterate until either (i) = issues are
> > =A0 =A0 squared off or (ii) either authors or reviewer declare th= e other as
> > =A0 =A0 "bat-crap-crazy" (or, complains that the other = side is not
> > =A0 =A0 responsive) and raise the issue to the AD. AD moves the d= ocument
> > =A0 =A0 forward to "AD Evaluation" only once happy with= the outcome of
> > =A0 =A0 directorate reviews. In short, hiving out a lot more of t= he "problem
> > =A0 =A0 fixing" that happens during these reviews off to the= directorates -
> > =A0 =A0 and leaving ADs to process presumably "less broken&q= uot; documents.
> >
> > =A0 =A0 As an author, I have actually found it a LOT easier/faste= r to
> > =A0 =A0 iterate with a directorate reviewer (who has my document = fresh in
> > =A0 =A0 mind), than with an AD who's preoccupied with a dozen= or so
> > =A0 =A0 documents at the same time, and other emergencies. Now, m= ind you,
> > =A0 =A0 some ADs are good at saying "Busy, will come back to= you in n days"
> > =A0 =A0 -- others, alas, do "play dead" if they feel th= ey have more
> > =A0 =A0 important fish to fry, and that's frustrating.
> >
> > =A0 =A0 This might lessen the load on the ADs, but still has the<= br> > > =A0 =A0 disadvantage that one gets feedback *very* late in the > > =A0 =A0 process....just a little bit earlier than during IESG pro= cessing.
> >
> > =A0 =A0 Thought #3:
> > =A0 =A0 I thought it's worth calling out, that either of the = above are not
> > =A0 =A0 really related to RTG documents: I should think that RTG = WG Chairs
> > =A0 =A0 are plenty able to do the necessary during WG processing,= and as an
> > =A0 =A0 author in the RTG Area, I do usually know how to grab som= eone
> > =A0 =A0 competent from the same area for advice, as needed. While= doing
> > =A0 =A0 something like this intra-area can be a good thing, the r= eal boast
> > =A0 =A0 that I, as document author, have felt has been through ge= tting
> > =A0 =A0 cross-area feedback. Just as (being forced to be) reviewi= ng document
> > =A0 =A0 outside of the RTG area has been hugely educational and.<= br> > >
> > =A0 =A0 Cheers,
> >
> > =A0 =A0 Thomas
> >
> >
> > =A0 =A0 On 21 Mar 2014, at 19:31, Adrian Farrel <adrian@olddog.co.uk
> > =A0 =A0 <mailto:adrian@= olddog.co.uk>> wrote:
> >
> > =A0 =A0 =A0> Hello Directorate and WG chairs,
> > =A0 =A0 =A0>
> > =A0 =A0 =A0> Alia and I have been discussing the Routing Area,= its work, its
> > =A0 =A0 output, and its
> > =A0 =A0 =A0> working groups.
> > =A0 =A0 =A0>
> > =A0 =A0 =A0> We have reached a conclusion (which perhaps we sh= ould have come
> > =A0 =A0 to sooner) that
> > =A0 =A0 =A0> we need your help and input.
> > =A0 =A0 =A0>
> > =A0 =A0 =A0> The crunch question for us is "What makes it= hard to get work
> > =A0 =A0 done in the
> > =A0 =A0 =A0> Routing Area?" What gets in the way of your = work? What is making
> > =A0 =A0 life hard for
> > =A0 =A0 =A0> document authors? How could working groups be doi= ng better? We
> > =A0 =A0 are open to all
> > =A0 =A0 =A0> and every type of answer. We are happy to have qu= ick, one-line
> > =A0 =A0 answers or
> > =A0 =A0 =A0> deeply-considered essays.
> > =A0 =A0 =A0>
> > =A0 =A0 =A0> What do you think?
> > =A0 =A0 =A0>
> > =A0 =A0 =A0> Thanks for all your input,
> > =A0 =A0 =A0> Adrian and Alia
> > =A0 =A0 =A0>
> > =A0 =A0 =A0> PS Please respond to both aliases because not eve= ryone is on both
> > =A0 =A0 lists. Sorry
> > =A0 =A0 =A0> that that means some of you will get duplicates.<= br> > > =A0 =A0 =A0>
> >
> >


--089e0122a64a45785a04f581dfb4-- From nobody Wed Mar 26 19:17:42 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CC11A0040; Wed, 26 Mar 2014 19:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 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, MIME_CHARSET_FARAWAY=2.45, 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 HVM_wDt9C4J3; Wed, 26 Mar 2014 19:17:36 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id DCAFE1A0280; Wed, 26 Mar 2014 19:17:35 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so2784676pbb.39 for ; Wed, 26 Mar 2014 19:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=ePeaYEHczE2hmEnzsvWmUtpVX888Ikyc55goeKTH+dw=; b=0FUBjLC2TdNmO+dgyJ4KVV0sG5h5ziUGiybcrKGA9oj2kJcl/8n3NoTT35tOJbsNhC 4wIKuBGlDZF32sjLxbkU5Ef8Q0EbjLqD6TlgOuRL8vbQ7oLhpGzn1bYp1dXpP8O89rgx OJAfaaNOEeJMPPz7W41rmcRwzBEcFSkcEo2xrz8toGlYdMLlq4peiFeQNje74JekoALB FucOYPQB/N8SZWUf99P+M8t7Y9KD5r3ia1usxLXlcblWYPg6eqajoQuAtWnvsrjpqBcT CJVy76K+cgIyMRb8O2YVOqEykotvyf7NlVDiZgxALEn7k0rQu5TNJCldpPForvdDNGbS dk3w== X-Received: by 10.68.198.97 with SMTP id jb1mr88273739pbc.104.1395886654318; Wed, 26 Mar 2014 19:17:34 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id yx3sm1660116pbb.6.2014.03.26.19.17.29 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Mar 2014 19:17:33 -0700 (PDT) From: "Lizhong Jin" To: "'Alia Atlas'" , "'Thomas Clausen'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: Date: Thu, 27 Mar 2014 10:17:25 +0800 Message-ID: <032601cf4962$b5785aa0$20690fe0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0327_01CF49A5.C3A0A3B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wF5D2kGAgX2wc8C6135DwLAQ7lLmRSowJA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/lad-qRBMlB9n1hr7o7rtUXCw08o Cc: 'Adrian Farrel' , 'Alia Atlas' , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 02:17:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0327_01CF49A5.C3A0A3B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Adrian, Alia, As a non-English speaker, I am very happy to see the language review. Regarding the question "What makes it hard to get work done in the = Routing Area?", one of my concern is the relax of WG document adoption. >From my feeling of IETF 8-10 years ago, every IETF draft will be only adopted when the solution is concrete, complete and feasible, and got various support from many vendors. But now it seems the draft could be adopted if some necessary technical part is missing, or it gets support = from only one company. Many draft authors pay much attention before WG = adoption, but will focus less after adopted. I am not sure if others have the same feeling with me. Please correct me = if I have some inaccurate understanding of IETF process. =20 Regards Lizhong =20 =20 From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia Atlas Sent: 2014=C4=EA3=D4=C226=C8=D5 3:13 To: Thomas Clausen Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; Subject: Re: [RTG-DIR] Routing Area Health Check =20 Adrian and I have discussed the need for good early review and follow through of drafts starting with WG adoption. We have also heard that the Routing Directorate could be = used more (though the situation may vary by individual). =20 We are writing up the idea of a "Document Mentor". More details to = follow (plan for next week) once Adrian and I have agreement on paper for the idea. =20 As far as English language mentoring, it sounds like George, Loa, and = Ross have a trial run going in MPLS. We can discuss having common organization for volunteers on each WG's = wiki or on the routing-area wiki. =20 Thoughts? =20 Alia =20 On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen = wrote: Alia, =20 On 25 Mar 2014, at 15:58, Alia Atlas wrote: Thomas, =20 Thanks very much for your thoughts. On the being underutilized and on cross-area review, what do you and others in the Routing Directorate = think about being asked to follow a single additional working group that is = not in RTG and may have routing related issues? =20 Can't speak for the others, but I'd be glad to, personally. =20 For the time speedup of ADs, I'm told that it'd be really really useful = to have more active document shepherds - who can facilitate getting = comments and having them addressed. I'm not sure how to put that into place = really. As a WG chair, I felt like I was processing and pushing few enough = drafts that I could do the shepherd job also - but I know that there are some = WGs where there is higher throughput. It's also a good way of growing a = person, to let them see the whole process and deal with the discussions. =20 That is a good point. Honestly, I do not know, and am really torn on = this issue. =20 On one hand, sometimes having a shepherd as "go-between" to whip lazy = ADs ;) or reviewers to come back with "So, did this address your concerns?" = could perhaps be helpful. Oftentimes, however - and this is the "have been in = this for long enough to have many of the ADs on Jabber by now" - the shepherd = is just-another-go-in-the-way: popping an IM to Adrian (or whoever), = getting a resolution, moving on, is a faster way of waking him up from hibernation than waiting for a third-party to do the same. Same for an AD holding a discuss, adding an extra intermediary to go through ....not sold on the idea. =20 So, I really do not know what to think about this. In the rare cases = where I have needed some whipping that I couldn't do myself, it has been an AD = so non-responsive that I doubt that a shepherd would do (was a long time = ago) and it required several other ADs ganging up....or (more recently) where there was an issue with IANA requiring resolution (Adrian helped out = there, but possibly somebody else could have, too). For the drafts, I'd love to see earlier reviews. I'm not sure if at WG adoption is quite the right time, but it is a good approximation of = "early in the process". =20 =20 I agree. It was just the least-arbitrary version number I could come up = with on short notice ;) We could ask WG chairs to request a reviewer at that point for drafts = that may need it and see what the load looks like. For a start-up, having interested WG chairs identify WG drafts that could benefit from review = would be helpful/interesting in terms of seeing the workload. =20 Can't disagree on this. =20 Thomas =20 =20 Regards, Alia =20 On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen = wrote: Hello ADs, Directorate, Chairs, Interesting questions, thanks for caring and asking. I am probably going to cut my answer into separate independent mails, as there are vastly different topics in this question. First, as a member of the RTG Directorate, I actually feel a little "under-utilized". An occasional review of an I-D at an extremely late = state of its process, and a very rare more global question like this. As has = been discussed widely lately, ADs are overworked and have too little time, so perhaps they do not call on the directorate enough - and, also, = delegation of tasks that the ADs have to do is probably perceived as rather hard. I've been dumbfounded by some of the reviews I have seen from ADs, = either during AD Evaluation or IESG Reviews: one particular case came to mind = where Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker = during IESG Evaluation. It doesn't matter what document or WG it was, what = matters is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's = time, (iii) there wasn't really something in the DISCUSS/COMMENTs that = required the wizardry of a yellow dot (just some routing background), and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG = Evaluation really isn't helpful to the document authors...its late, design = decisions have been made, which are being questioned, etc....it tires people out, pisses off authors, and frustrates everybody involved. So, I've been playing around with a couple of ideas on the sideline, unofficially, and with only unwitting assistance from others = involved.... Thought #1: I-Ds - when called for adoption as WG documents, or when published as draft-ietf-...-00's, gets someone from the directorate assigned, to = provide an initial review and thoughts on "what directions would be good to take = (or avoid) here". That same reviewer can, occasionally, be invoked by the WG chairs or authors, in the "so, did we catch this right?" -- and, of = course, should be called in on the WGLC of the document. I think of it a little = as the "area advisors" but to a document rather than a WG as a whole. I've been playing around with that a bit, as an author: o Since I know very little about security, I've looped in somebody who did, when having published a -00, and again the same person as = needed later in the process. I've gotten hugely valuable feedback - making the = ultimate SEC-DIR and SEC-AD reviews a lot less painful for me (and, given how = little I knew about security, presumably less frustrating/time-consuming for the ADs, too, than = if I had been just shooting blind). o Since I know even less about OPS stuff, Adrian looped an = OPS guy in on an individual -01, who asked a lot of good questions to = what we were doing, and why, and which is hugely helpful. As an author in the RTG Area, the SEC and OPS ADs are often real "roadblocks". Reasonably so, of course, they represent important = concerns. And gosh, every time I encounter any AD, I have to explain the whole = context over once again since, even if they've already gotten the story once, = they have to follow sufficiently many documents and topics that something is bound to be flushed from their cache. Having someone, from the respective directorate, be more of a = facilitator, sparring-partner, and who - over time - follows the document (and, presumably, follows much fewer documents concurrently) through the = process with the authors would be great, as an author. And possibly makes the = ADs encounter less poor documents. I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) = be just as much of a roadblock as the SEC/OPS folks, and I have no reason = to not expect Alia to have the same high (or higher) standards....so I = imagine that a way the RTG-DIR could help "improve the image of the ADs" and at = the same time get the ADs time liberated from writing 10-page discusses, = would be something like the above.... In short, what I envision is a structured way of getting: o very early-reviews o a semi-permanent attachment of a reviewer from the directorateS to a document o this, through the documents lifecycle. Not sure if it scales, either, but as an author I've greatly enjoyed = having such a "ongoing relationship" with people helping me avoid pitfalls. A final note: having been around for a while in the IETF, it is really = easy to ask around for help from among other IETFers that one knows -- then again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) author, who = knows few people and who presumably might be likely to need more help in = avoiding said pitfalls, it's a lot harder to actually reach out and get the right people's eyes on a document -- and, even to know what eyes are good to = get on it. This might, actually, therefore be also a good way of the IETF to be = more welcoming and inclusive to new folks wanting to get involved. Thought #2: So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter = version of thought #1 is to have a more structure directorate review cycle = during IETF LC, or perhaps during "Publication Requested" and before "AD Evaluation". I am thinking that these be of the form: an I-D hits the = AD, the responsible/sponsoring AD requests directorate reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and = reviewer iterate until either (i) issues are squared off or (ii) either authors = or reviewer declare the other as "bat-crap-crazy" (or, complains that the = other side is not responsive) and raise the issue to the AD. AD moves the = document forward to "AD Evaluation" only once happy with the outcome of = directorate reviews. In short, hiving out a lot more of the "problem fixing" that happens during these reviews off to the directorates - and leaving ADs = to process presumably "less broken" documents. As an author, I have actually found it a LOT easier/faster to iterate = with a directorate reviewer (who has my document fresh in mind), than with an = AD who's preoccupied with a dozen or so documents at the same time, and = other emergencies. Now, mind you, some ADs are good at saying "Busy, will come back to you in n days" -- others, alas, do "play dead" if they feel they have more important fish to fry, and that's frustrating. This might lessen the load on the ADs, but still has the disadvantage = that one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing. Thought #3: I thought it's worth calling out, that either of the above are not = really related to RTG documents: I should think that RTG WG Chairs are plenty = able to do the necessary during WG processing, and as an author in the RTG = Area, I do usually know how to grab someone competent from the same area for advice, as needed. While doing something like this intra-area can be a = good thing, the real boast that I, as document author, have felt has been = through getting cross-area feedback. Just as (being forced to be) reviewing = document outside of the RTG area has been hugely educational and. Cheers, Thomas On 21 Mar 2014, at 19:31, Adrian Farrel wrote: > Hello Directorate and WG chairs, > > Alia and I have been discussing the Routing Area, its work, its = output, and its > working groups. > > We have reached a conclusion (which perhaps we should have come to = sooner) that > we need your help and input. > > The crunch question for us is "What makes it hard to get work done in = the > Routing Area?" What gets in the way of your work? What is making life = hard for > document authors? How could working groups be doing better? We are = open to all > and every type of answer. We are happy to have quick, one-line answers = or > deeply-considered essays. > > What do you think? > > Thanks for all your input, > Adrian and Alia > > PS Please respond to both aliases because not everyone is on both = lists. Sorry > that that means some of you will get duplicates. > =20 =20 =20 ------=_NextPart_000_0327_01CF49A5.C3A0A3B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Adrian, Alia,

As a non-English speaker, I am very happy to see the language = review.

Regarding the question "What makes it hard to get work done in = the Routing Area?", one of my concern is the relax of WG document = adoption.

From my feeling of IETF 8-10 years ago, every IETF draft will be only = adopted when the solution is concrete, complete and feasible, and got = various support from many vendors. But now it seems the draft could be = adopted if some necessary technical part is missing, or it gets support = from only one company. Many draft authors pay much attention before WG = adoption, but will focus less after adopted.

I am not sure if others have the same feeling with me. Please correct = me if I have some inaccurate understanding of IETF = process.

 

Regards

Lizhong

 

 

From:= = rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia = Atlas
Sent: 2014=C4=EA3=D4=C226=C8=D5 = 3:13
To: Thomas Clausen
Cc: Adrian Farrel; = rtg-chairs@ietf.org; Alia Atlas; = <rtg-dir@ietf.org>
Subject: Re: [RTG-DIR] Routing Area = Health Check

 

Adrian = and I have discussed the need for good early review and follow through = of drafts starting with

WG = adoption.  We have also heard that the Routing Directorate could be = used more (though the situation may

vary by individual).

 

We are writing up the idea of a "Document = Mentor".   More details to follow (plan for next week) once = Adrian

and I have = agreement on paper for the idea.

 

As far as English language mentoring, it sounds like = George, Loa, and Ross have a trial run going in = MPLS.

We can discuss = having common organization for volunteers on each WG's wiki or on the = routing-area wiki.

 

Thoughts?

 

Alia

 

On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen = <thomas@thomasclausen.org> = wrote:

Alia,

 

On 25 Mar 2014, at 15:58, Alia Atlas <akatlas@gmail.com> = wrote:



Thomas,

 

Thanks very much for your thoughts.  On the being = underutilized and on cross-area review, what do you and others in the = Routing Directorate think about being asked to follow a single = additional working group that is not in RTG and may have routing related = issues?

 

Can't speak for the others, but I'd be glad to, = personally.



 

For the time speedup of ADs, I'm told that it'd be = really really useful to have more active document shepherds - who can = facilitate getting comments and having them addressed.  I'm not = sure how to put that into place really.  As a WG chair, I felt like = I was processing and pushing few enough drafts that I could do the = shepherd job also - but I know that there are some WGs where there is = higher throughput.  It's also a good way of growing a person, to = let them see the whole process and deal with the = discussions.

 

That is a good point. Honestly, I do not know, and am = really torn on this issue.

 

On one hand, sometimes having a shepherd as = "go-between" to whip lazy ADs ;) or reviewers to come back = with "So, did this address your concerns?" could perhaps be = helpful. Oftentimes, however - and this is the "have been in this = for long enough to have many of the ADs on Jabber by now" - the = shepherd is just-another-go-in-the-way: popping an IM to Adrian (or = whoever), getting a resolution, moving on, is a faster way of waking him = up from hibernation than waiting for a third-party to do the same. Same = for an AD holding a discuss, adding an extra intermediary to go through = ....not sold on the idea.

 

So, I really do not know what to think about this. In = the rare cases where I have needed some whipping that I couldn't do = myself, it has been an AD so non-responsive that I doubt that a shepherd = would do (was a long time ago) and it required several other ADs ganging = up....or (more recently) where there was an issue with IANA requiring = resolution (Adrian helped out there, but possibly somebody else could = have, too).



For the drafts, I'd love to see earlier reviews. =  I'm not sure if at WG adoption is quite the right time, but it is = a good approximation of "early in the process". =  

 

I agree. It was just the least-arbitrary version = number I could come up with on short notice = ;)



We could ask WG chairs to request a reviewer at that = point for drafts that may need it and see what the load looks like. =  For a start-up, having interested WG chairs identify WG drafts = that could benefit from review would be helpful/interesting in terms of = seeing the workload.

 

Can't disagree on this.

 

Thomas

=

 

 

Regards,

Alia

 

On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen = <thomas@thomasclausen.org> = wrote:

Hello ADs, Directorate, = Chairs,

Interesting questions, thanks for caring and = asking.

I am probably going to cut my answer into separate = independent mails, as there are vastly different topics in this = question.

First, as a member of the RTG Directorate, I actually = feel a little "under-utilized". An occasional review of an I-D = at an extremely late state of its process, and a very rare more global = question like this. As has been discussed widely lately, ADs are = overworked and have too little time, so perhaps they do not call on the = directorate enough - and, also, delegation of tasks that the ADs have to = do is probably perceived as rather hard.

I've been dumbfounded by = some of the reviews I have seen from ADs, either during AD Evaluation or = IESG Reviews: one particular case came to mind where Adrian sent what = looked like a 10-page DISCUSS/COMMENT to the tracker during IESG = Evaluation. It doesn't matter what document or WG it was, what matters = is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's = time, (iii) there wasn't really something in the DISCUSS/COMMENTs that = required the wizardry of a yellow dot (just some routing background), = and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during = IESG Evaluation really isn't helpful to the document authors...its late, = design decisions have been made, which are being questioned, etc....it = tires people out, pisses off authors, and frustrates everybody = involved.

So, I've been playing around with a couple of ideas on = the sideline, unofficially, and with only unwitting assistance from = others involved....

Thought #1:
I-Ds - when called for = adoption as WG documents, or when published as draft-ietf-...-00's, gets = someone from the directorate assigned, to provide an initial review and = thoughts on "what directions would be good to take (or avoid) = here". That same reviewer can, occasionally, be invoked by the WG = chairs or authors, in the "so, did we catch this right?" -- = and, of course, should be called in on the WGLC of the document. I think = of it a little as the "area advisors" but to a document rather = than a WG as a whole.

I've been playing around with that a bit, = as an author:

        o       = Since I know very little about security, I've looped in somebody who = did, when
                = having published a -00, and again the same person as needed later in the = process.
                I've = gotten  hugely valuable feedback - making the ultimate SEC-DIR and = SEC-AD
                = reviews a lot  less painful for me (and, given how little I knew = about security, presumably
            =     less  frustrating/time-consuming for the ADs, too, = than if I had been just shooting blind).

      =   o       Since I know even less about OPS stuff, = Adrian looped an OPS guy in on an
          =       individual -01, who asked a lot of good questions = to what we were doing, and why,
          =       and which is hugely helpful.

As an author in = the RTG Area, the SEC and OPS ADs are often real "roadblocks". = Reasonably so, of course, they represent important concerns. And gosh, = every time I encounter any AD, I have to explain the whole context over = once again since, even if they've already gotten the story once, they = have to follow sufficiently many documents and topics that something is = bound to be flushed from their cache.

Having someone, from the = respective directorate, be more of a facilitator, sparring-partner, and = who - over time - follows the document (and, presumably, follows much = fewer documents concurrently) through the process with the authors would = be great, as an author. And possibly makes the ADs encounter less poor = documents.

I know that Adrian can (cf. the aforementioned 10-page = DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, = and I have no reason to not expect Alia to have the same high (or = higher) standards....so I imagine that a way the RTG-DIR could help = "improve the image of the ADs" and at the same time get the = ADs time liberated from writing 10-page discusses, would be something = like the above....

In short, what I envision is a structured way = of getting:
        o       very = early-reviews
        o       a = semi-permanent attachment of a reviewer from the directorateS to a = document
        o       this, = through the documents lifecycle.

Not sure if it scales, either, = but as an author I've greatly enjoyed having such a "ongoing = relationship" with people helping me avoid pitfalls.

A final = note: having been around for a while in the IETF, it is really easy to = ask around for help from among other IETFers that one knows -- then = again, having been around for a while, presumably one has more = experience and needs less help in avoiding pitfalls. For a new(ish) = author, who knows few people and who presumably might be likely to need = more help in avoiding said pitfalls, it's a lot harder to actually reach = out and get the right people's eyes on a document -- and, even to know = what eyes are good to get on it.

This might, actually, therefore = be also a good way of the IETF to be more welcoming and inclusive to new = folks wanting to get involved.

Thought #2:
So back to Adrian's = 10-page DISCUSS/COMMENT....a, perhaps, lighter version of thought #1 is = to have a more structure directorate review cycle during IETF LC, or = perhaps during "Publication Requested" and before "AD = Evaluation". I am thinking that these be of the form: an I-D hits = the AD, the responsible/sponsoring AD requests directorate reviews from = all the concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors = and reviewer iterate until either (i) issues are squared off or (ii) = either authors or reviewer declare the other as = "bat-crap-crazy" (or, complains that the other side is not = responsive) and raise the issue to the AD. AD moves the document forward = to "AD Evaluation" only once happy with the outcome of = directorate reviews. In short, hiving out a lot more of the = "problem fixing" that happens during these reviews off to the = directorates - and leaving ADs to process presumably "less = broken" documents.

As an author, I have actually found it a = LOT easier/faster to iterate with a directorate reviewer (who has my = document fresh in mind), than with an AD who's preoccupied with a dozen = or so documents at the same time, and other emergencies. Now, mind you, = some ADs are good at saying "Busy, will come back to you in n = days" -- others, alas, do "play dead" if they feel they = have more important fish to fry, and that's frustrating.

This = might lessen the load on the ADs, but still has the disadvantage that = one gets feedback *very* late in the process....just a little bit = earlier than during IESG processing.

Thought #3:
I thought = it's worth calling out, that either of the above are not really related = to RTG documents: I should think that RTG WG Chairs are plenty able to = do the necessary during WG processing, and as an author in the RTG Area, = I do usually know how to grab someone competent from the same area for = advice, as needed. While doing something like this intra-area can be a = good thing, the real boast that I, as document author, have felt has = been through getting cross-area feedback. Just as (being forced to be) = reviewing document outside of the RTG area has been hugely educational = and.

Cheers,

Thomas



On 21 Mar 2014, = at 19:31, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello = Directorate and WG chairs,
>
> Alia and I have been = discussing the Routing Area, its work, its output, and its
> = working groups.
>
> We have reached a conclusion (which = perhaps we should have come to sooner) that
> we need your help = and input.
>
> The crunch question for us is "What = makes it hard to get work done in the
> Routing Area?" What = gets in the way of your work? What is making life hard for
> = document authors? How could working groups be doing better? We are open = to all
> and every type of answer. We are happy to have quick, = one-line answers or
> deeply-considered essays.
>
> = What do you think?
>
> Thanks for all your input,
> = Adrian and Alia
>
> PS Please respond to both aliases = because not everyone is on both lists. Sorry
> that that means = some of you will get = duplicates.
>

 

 

 

------=_NextPart_000_0327_01CF49A5.C3A0A3B0-- From nobody Thu Mar 27 00:42:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940381A0478; Thu, 27 Mar 2014 00:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 KELG4I_vPK0W; Thu, 27 Mar 2014 00:42:09 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7A61A00FF; Thu, 27 Mar 2014 00:42:09 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hm4so5524714wib.4 for ; Thu, 27 Mar 2014 00:42:07 -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:content-transfer-encoding; bh=45pzavj64WmV1tmuvJCbSyiPKjUtqQFW3UR5BpUngj4=; b=j54Xwlk9hD7E5x+nh2meTpDbGokhyqhwioz57a53dsUKZz+YkvblG4picgFug0SLfK J3TCsyj5UtN8GX/EvDmhEapoqsGiWCR8ccYIR2ovNoBelzT/Hmgo4mEH9/OXAauzfS2n DEZ9eJFg/JnDq7ebtfF4pEu7p/1kb9bMwetg1dpWRXSk0e0Pdk4MyKhAFaPvhKs4ntBO CQlNtms8eHcMJWiX2zH6dlD+W0tYZPIjVTOhkNWztK8rJUYvax1/ugK3iflajlgfNbVy 1AjJjkAPZpy3MdA8yxX7u0Zgl/4u8wPoRwUl1yq5b5ldA/kHMQyDaKJLCCPXFa05rFJy mcuw== X-Received: by 10.180.188.229 with SMTP id gd5mr37444289wic.54.1395906127126; Thu, 27 Mar 2014 00:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Thu, 27 Mar 2014 00:41:46 -0700 (PDT) In-Reply-To: <032601cf4962$b5785aa0$20690fe0$@gmail.com> References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <032601cf4962$b5785aa0$20690fe0$@gmail.com> From: "Andrew G. Malis" Date: Thu, 27 Mar 2014 08:41:46 +0100 Message-ID: To: Lizhong Jin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/QV3b76CASxLrUDun7uCwjAOv9fU Cc: rtg-dir@ietf.org, Alia Atlas , Thomas Clausen , Alia Atlas , rtg-chairs@ietf.org, Adrian Farrel Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:42:13 -0000 Lizhong, I don't know if I quite agree with your generalization. Like children, every working group is different, and every draft is different, and as a result there are varying qualifications to WG adoption. Certainly at the very least there needs to be some amount of interest in the WG and a rough consensus to adopt a draft, but it's more complicated than that. Sometimes there are drafts that are a part of a set of drafts contributing to a coordinated overall effort. In those cases, the barrier to WG adoption is lower because each draft is a necessary part of the whole. In the case of a single-author stand-alone draft, the barrier may be a bit higher to show the value of the draft, but there have been many excellent single-author drafts and resulting RFCs.A draft's IPR status can also affect a WG's judgement on whether to adopt it. But of course, in your own judgement, if you see a WG adoption poll and you really don't think the WG should be spending its time on it, respond to the poll! That's really all of our responsibilities. Cheers, Andy On Thu, Mar 27, 2014 at 3:17 AM, Lizhong Jin wrote: > Hi Adrian, Alia, > > As a non-English speaker, I am very happy to see the language review. > > Regarding the question "What makes it hard to get work done in the Routin= g > Area?", one of my concern is the relax of WG document adoption. > > From my feeling of IETF 8-10 years ago, every IETF draft will be only > adopted when the solution is concrete, complete and feasible, and got > various support from many vendors. But now it seems the draft could be > adopted if some necessary technical part is missing, or it gets support f= rom > only one company. Many draft authors pay much attention before WG adoptio= n, > but will focus less after adopted. > > I am not sure if others have the same feeling with me. Please correct me = if > I have some inaccurate understanding of IETF process. > > > > Regards > > Lizhong > > > > > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia Atlas > Sent: 2014=E5=B9=B43=E6=9C=8826=E6=97=A5 3:13 > To: Thomas Clausen > > > Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; > Subject: Re: [RTG-DIR] Routing Area Health Check > > > > Adrian and I have discussed the need for good early review and follow > through of drafts starting with > > WG adoption. We have also heard that the Routing Directorate could be us= ed > more (though the situation may > > vary by individual). > > > > We are writing up the idea of a "Document Mentor". More details to foll= ow > (plan for next week) once Adrian > > and I have agreement on paper for the idea. > > > > As far as English language mentoring, it sounds like George, Loa, and Ros= s > have a trial run going in MPLS. > > We can discuss having common organization for volunteers on each WG's wik= i > or on the routing-area wiki. > > > > Thoughts? > > > > Alia > > > > On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen > wrote: > > Alia, > > > > On 25 Mar 2014, at 15:58, Alia Atlas wrote: > > > > Thomas, > > > > Thanks very much for your thoughts. On the being underutilized and on > cross-area review, what do you and others in the Routing Directorate thin= k > about being asked to follow a single additional working group that is not= in > RTG and may have routing related issues? > > > > Can't speak for the others, but I'd be glad to, personally. > > > > > > For the time speedup of ADs, I'm told that it'd be really really useful t= o > have more active document shepherds - who can facilitate getting comments > and having them addressed. I'm not sure how to put that into place reall= y. > As a WG chair, I felt like I was processing and pushing few enough drafts > that I could do the shepherd job also - but I know that there are some WG= s > where there is higher throughput. It's also a good way of growing a pers= on, > to let them see the whole process and deal with the discussions. > > > > That is a good point. Honestly, I do not know, and am really torn on this > issue. > > > > On one hand, sometimes having a shepherd as "go-between" to whip lazy ADs= ;) > or reviewers to come back with "So, did this address your concerns?" coul= d > perhaps be helpful. Oftentimes, however - and this is the "have been in t= his > for long enough to have many of the ADs on Jabber by now" - the shepherd = is > just-another-go-in-the-way: popping an IM to Adrian (or whoever), getting= a > resolution, moving on, is a faster way of waking him up from hibernation > than waiting for a third-party to do the same. Same for an AD holding a > discuss, adding an extra intermediary to go through ....not sold on the > idea. > > > > So, I really do not know what to think about this. In the rare cases wher= e I > have needed some whipping that I couldn't do myself, it has been an AD so > non-responsive that I doubt that a shepherd would do (was a long time ago= ) > and it required several other ADs ganging up....or (more recently) where > there was an issue with IANA requiring resolution (Adrian helped out ther= e, > but possibly somebody else could have, too). > > > > For the drafts, I'd love to see earlier reviews. I'm not sure if at WG > adoption is quite the right time, but it is a good approximation of "earl= y > in the process". > > > > I agree. It was just the least-arbitrary version number I could come up w= ith > on short notice ;) > > > > We could ask WG chairs to request a reviewer at that point for drafts tha= t > may need it and see what the load looks like. For a start-up, having > interested WG chairs identify WG drafts that could benefit from review wo= uld > be helpful/interesting in terms of seeing the workload. > > > > Can't disagree on this. > > > > Thomas > > > > > > Regards, > > Alia > > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > wrote: > > Hello ADs, Directorate, Chairs, > > Interesting questions, thanks for caring and asking. > > I am probably going to cut my answer into separate independent mails, as > there are vastly different topics in this question. > > First, as a member of the RTG Directorate, I actually feel a little > "under-utilized". An occasional review of an I-D at an extremely late sta= te > of its process, and a very rare more global question like this. As has be= en > discussed widely lately, ADs are overworked and have too little time, so > perhaps they do not call on the directorate enough - and, also, delegatio= n > of tasks that the ADs have to do is probably perceived as rather hard. > > I've been dumbfounded by some of the reviews I have seen from ADs, either > during AD Evaluation or IESG Reviews: one particular case came to mind wh= ere > Adrian sent what looked like a 10-page DISCUSS/COMMENT to the tracker dur= ing > IESG Evaluation. It doesn't matter what document or WG it was, what matte= rs > is that (i) it doesn't scale IETF-wide, (ii) it's poor use of Adrian's ti= me, > (iii) there wasn't really something in the DISCUSS/COMMENTs that required > the wizardry of a yellow dot (just some routing background), and -- most > importantly -- (iv) getting a 10-page DISCUSS/COMMENT during IESG Evaluat= ion > really isn't helpful to the document authors...its late, design decisions > have been made, which are being questioned, etc....it tires people out, > pisses off authors, and frustrates everybody involved. > > So, I've been playing around with a couple of ideas on the sideline, > unofficially, and with only unwitting assistance from others involved.... > > Thought #1: > I-Ds - when called for adoption as WG documents, or when published as > draft-ietf-...-00's, gets someone from the directorate assigned, to provi= de > an initial review and thoughts on "what directions would be good to take = (or > avoid) here". That same reviewer can, occasionally, be invoked by the WG > chairs or authors, in the "so, did we catch this right?" -- and, of cours= e, > should be called in on the WGLC of the document. I think of it a little a= s > the "area advisors" but to a document rather than a WG as a whole. > > I've been playing around with that a bit, as an author: > > o Since I know very little about security, I've looped in > somebody who did, when > having published a -00, and again the same person as need= ed > later in the process. > I've gotten hugely valuable feedback - making the ultima= te > SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how little= I > knew about security, presumably > less frustrating/time-consuming for the ADs, too, than i= f I > had been just shooting blind). > > o Since I know even less about OPS stuff, Adrian looped an = OPS > guy in on an > individual -01, who asked a lot of good questions to what= we > were doing, and why, > and which is hugely helpful. > > As an author in the RTG Area, the SEC and OPS ADs are often real > "roadblocks". Reasonably so, of course, they represent important concerns= . > And gosh, every time I encounter any AD, I have to explain the whole cont= ext > over once again since, even if they've already gotten the story once, the= y > have to follow sufficiently many documents and topics that something is > bound to be flushed from their cache. > > Having someone, from the respective directorate, be more of a facilitator= , > sparring-partner, and who - over time - follows the document (and, > presumably, follows much fewer documents concurrently) through the proces= s > with the authors would be great, as an author. And possibly makes the ADs > encounter less poor documents. > > I know that Adrian can (cf. the aforementioned 10-page DISCUSS/COMMENT) b= e > just as much of a roadblock as the SEC/OPS folks, and I have no reason to > not expect Alia to have the same high (or higher) standards....so I imagi= ne > that a way the RTG-DIR could help "improve the image of the ADs" and at t= he > same time get the ADs time liberated from writing 10-page discusses, woul= d > be something like the above.... > > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the > directorateS to a document > o this, through the documents lifecycle. > > Not sure if it scales, either, but as an author I've greatly enjoyed havi= ng > such a "ongoing relationship" with people helping me avoid pitfalls. > > A final note: having been around for a while in the IETF, it is really ea= sy > to ask around for help from among other IETFers that one knows -- then > again, having been around for a while, presumably one has more experience > and needs less help in avoiding pitfalls. For a new(ish) author, who know= s > few people and who presumably might be likely to need more help in avoidi= ng > said pitfalls, it's a lot harder to actually reach out and get the right > people's eyes on a document -- and, even to know what eyes are good to ge= t > on it. > > This might, actually, therefore be also a good way of the IETF to be more > welcoming and inclusive to new folks wanting to get involved. > > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter versio= n > of thought #1 is to have a more structure directorate review cycle during > IETF LC, or perhaps during "Publication Requested" and before "AD > Evaluation". I am thinking that these be of the form: an I-D hits the AD, > the responsible/sponsoring AD requests directorate reviews from all the > concerned directorates (GEN, SEC, OPS, RTG, TSP, ...). Authors and review= er > iterate until either (i) issues are squared off or (ii) either authors or > reviewer declare the other as "bat-crap-crazy" (or, complains that the ot= her > side is not responsive) and raise the issue to the AD. AD moves the docum= ent > forward to "AD Evaluation" only once happy with the outcome of directorat= e > reviews. In short, hiving out a lot more of the "problem fixing" that > happens during these reviews off to the directorates - and leaving ADs to > process presumably "less broken" documents. > > As an author, I have actually found it a LOT easier/faster to iterate wit= h a > directorate reviewer (who has my document fresh in mind), than with an AD > who's preoccupied with a dozen or so documents at the same time, and othe= r > emergencies. Now, mind you, some ADs are good at saying "Busy, will come > back to you in n days" -- others, alas, do "play dead" if they feel they > have more important fish to fry, and that's frustrating. > > This might lessen the load on the ADs, but still has the disadvantage tha= t > one gets feedback *very* late in the process....just a little bit earlier > than during IESG processing. > > Thought #3: > I thought it's worth calling out, that either of the above are not really > related to RTG documents: I should think that RTG WG Chairs are plenty ab= le > to do the necessary during WG processing, and as an author in the RTG Are= a, > I do usually know how to grab someone competent from the same area for > advice, as needed. While doing something like this intra-area can be a go= od > thing, the real boast that I, as document author, have felt has been thro= ugh > getting cross-area feedback. Just as (being forced to be) reviewing docum= ent > outside of the RTG area has been hugely educational and. > > Cheers, > > Thomas > > > > On 21 Mar 2014, at 19:31, Adrian Farrel wrote: > >> Hello Directorate and WG chairs, >> >> Alia and I have been discussing the Routing Area, its work, its output, >> and its >> working groups. >> >> We have reached a conclusion (which perhaps we should have come to soone= r) >> that >> we need your help and input. >> >> The crunch question for us is "What makes it hard to get work done in th= e >> Routing Area?" What gets in the way of your work? What is making life ha= rd >> for >> document authors? How could working groups be doing better? We are open = to >> all >> and every type of answer. We are happy to have quick, one-line answers o= r >> deeply-considered essays. >> >> What do you think? >> >> Thanks for all your input, >> Adrian and Alia >> >> PS Please respond to both aliases because not everyone is on both lists. >> Sorry >> that that means some of you will get duplicates. >> > > > > > > From nobody Thu Mar 27 01:21:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9031B1A0478; Thu, 27 Mar 2014 01:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 4YtUFO7wS3Rd; Thu, 27 Mar 2014 01:21:24 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id A1DEE1A02DA; Thu, 27 Mar 2014 01:21:24 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kq14so3160033pab.10 for ; Thu, 27 Mar 2014 01:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=jPCZ+oO3fPk2+6tFNnyqwKNWNBP06RM8YjvJGfz7Qdo=; b=JWsbdXF3UQQRrNKLQFlm8wyTewmsE1keVVlIwErxHcz4NqFDx7hppRRMpynwcI7o5u FQYXI5uF+IPvO5gadyUX+rTXsUzVJ3mXQJ72HEY8d6OVlQ3xbuaj6eGDfuJLbqPGVO48 cXDPbTxi6o4F88N8hiQobA5+gVjlHtG3dZCzg4ZaN1c7qXwTsbPDxX6xtORH+DITxfgX ME5MnCuRfBBELaQZZXDU6Fp2D5X2c8o2MRLSSQ48hKBQdA9IfQApD24tm/EfTUhjx1jT TBbTjmM9kzXAbTg78csPZhM6dp3uLFSttjXaWcCOTWZptMuyNy8jYUEVvmjg7j+yE+fW rUHw== X-Received: by 10.66.137.109 with SMTP id qh13mr405195pab.39.1395908483009; Thu, 27 Mar 2014 01:21:23 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id it4sm5522932pbd.48.2014.03.27.01.21.17 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Mar 2014 01:21:22 -0700 (PDT) From: "Lizhong Jin" To: "'Andrew G. Malis'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <032601cf4962$b5785aa0$20690fe0$@gmail.com> In-Reply-To: Date: Thu, 27 Mar 2014 16:21:14 +0800 Message-ID: <034901cf4995$8875ccd0$99616670$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wF5D2kGAgX2wc8C6135DwLAQ7lLArB2Aw4Baf5JQZj0N3ZA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/FdS4erAhdeX6YUNJljlYeoKOong Cc: rtg-dir@ietf.org, 'Alia Atlas' , 'Thomas Clausen' , 'Alia Atlas' , rtg-chairs@ietf.org, 'Adrian Farrel' Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 08:21:28 -0000 Andy,=20 Thank you for the explanation. I fully agree that it is not an easy job = to set the barrier for each draft. Setting a bit higher barrier for WG = adoption will improve the document quality. An excellent single-author = draft will not be killed by the barrier if it indeed values much.=20 Regards Lizhong > -----Original Message----- > From: Andrew G. Malis [mailto:agmalis@gmail.com] > Sent: 2014=E5=B9=B43=E6=9C=8827=E6=97=A5 15:42 > To: Lizhong Jin > Cc: Alia Atlas; Thomas Clausen; Adrian Farrel; Alia Atlas; = rtg-dir@ietf.org; rtg- > chairs@ietf.org > Subject: Re: [RTG-DIR] Routing Area Health Check >=20 > Lizhong, >=20 > I don't know if I quite agree with your generalization. Like children, = every > working group is different, and every draft is different, and as a = result there > are varying qualifications to WG adoption. Certainly at the very least = there > needs to be some amount of interest in the WG and a rough consensus to > adopt a draft, but it's more complicated than that. Sometimes there = are > drafts that are a part of a set of drafts contributing to a = coordinated overall > effort. In those cases, the barrier to WG adoption is lower because = each draft > is a necessary part of the whole. In the case of a single-author = stand-alone > draft, the barrier may be a bit higher to show the value of the draft, = but > there have been many excellent single-author drafts and resulting = RFCs.A > draft's IPR status can also affect a WG's judgement on whether to = adopt it. >=20 > But of course, in your own judgement, if you see a WG adoption poll = and you > really don't think the WG should be spending its time on it, respond = to the > poll! That's really all of our responsibilities. >=20 > Cheers, > Andy >=20 >=20 > On Thu, Mar 27, 2014 at 3:17 AM, Lizhong Jin = wrote: > > Hi Adrian, Alia, > > > > As a non-English speaker, I am very happy to see the language = review. > > > > Regarding the question "What makes it hard to get work done in the > > Routing Area?", one of my concern is the relax of WG document = adoption. > > > > From my feeling of IETF 8-10 years ago, every IETF draft will be = only > > adopted when the solution is concrete, complete and feasible, and = got > > various support from many vendors. But now it seems the draft could = be > > adopted if some necessary technical part is missing, or it gets > > support from only one company. Many draft authors pay much attention > > before WG adoption, but will focus less after adopted. > > > > I am not sure if others have the same feeling with me. Please = correct > > me if I have some inaccurate understanding of IETF process. > > > > > > > > Regards > > > > Lizhong > > > > > > > > > > > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia > > Atlas > > Sent: 2014=E5=B9=B43=E6=9C=8826=E6=97=A5 3:13 > > To: Thomas Clausen > > > > > > Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; = > > Subject: Re: [RTG-DIR] Routing Area Health Check > > > > > > > > Adrian and I have discussed the need for good early review and = follow > > through of drafts starting with > > > > WG adoption. We have also heard that the Routing Directorate could = be > > used more (though the situation may > > > > vary by individual). > > > > > > > > We are writing up the idea of a "Document Mentor". More details to > follow > > (plan for next week) once Adrian > > > > and I have agreement on paper for the idea. > > > > > > > > As far as English language mentoring, it sounds like George, Loa, = and > > Ross have a trial run going in MPLS. > > > > We can discuss having common organization for volunteers on each = WG's > > wiki or on the routing-area wiki. > > > > > > > > Thoughts? > > > > > > > > Alia > > > > > > > > On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen > > > > wrote: > > > > Alia, > > > > > > > > On 25 Mar 2014, at 15:58, Alia Atlas wrote: > > > > > > > > Thomas, > > > > > > > > Thanks very much for your thoughts. On the being underutilized and = on > > cross-area review, what do you and others in the Routing Directorate > > think about being asked to follow a single additional working group > > that is not in RTG and may have routing related issues? > > > > > > > > Can't speak for the others, but I'd be glad to, personally. > > > > > > > > > > > > For the time speedup of ADs, I'm told that it'd be really really > > useful to have more active document shepherds - who can facilitate > > getting comments and having them addressed. I'm not sure how to put > that into place really. > > As a WG chair, I felt like I was processing and pushing few enough > > drafts that I could do the shepherd job also - but I know that there > > are some WGs where there is higher throughput. It's also a good way > > of growing a person, to let them see the whole process and deal with = the > discussions. > > > > > > > > That is a good point. Honestly, I do not know, and am really torn on > > this issue. > > > > > > > > On one hand, sometimes having a shepherd as "go-between" to whip = lazy > > ADs ;) or reviewers to come back with "So, did this address your > > concerns?" could perhaps be helpful. Oftentimes, however - and this = is > > the "have been in this for long enough to have many of the ADs on > > Jabber by now" - the shepherd is > > just-another-go-in-the-way: popping an IM to Adrian (or whoever), > > getting a resolution, moving on, is a faster way of waking him up = from > > hibernation than waiting for a third-party to do the same. Same for = an > > AD holding a discuss, adding an extra intermediary to go through > > ....not sold on the idea. > > > > > > > > So, I really do not know what to think about this. In the rare cases > > where I have needed some whipping that I couldn't do myself, it has > > been an AD so non-responsive that I doubt that a shepherd would do > > (was a long time ago) and it required several other ADs ganging > > up....or (more recently) where there was an issue with IANA = requiring > > resolution (Adrian helped out there, but possibly somebody else = could > have, too). > > > > > > > > For the drafts, I'd love to see earlier reviews. I'm not sure if at > > WG adoption is quite the right time, but it is a good approximation = of > > "early in the process". > > > > > > > > I agree. It was just the least-arbitrary version number I could come > > up with on short notice ;) > > > > > > > > We could ask WG chairs to request a reviewer at that point for = drafts > > that may need it and see what the load looks like. For a start-up, > > having interested WG chairs identify WG drafts that could benefit = from > > review would be helpful/interesting in terms of seeing the workload. > > > > > > > > Can't disagree on this. > > > > > > > > Thomas > > > > > > > > > > > > Regards, > > > > Alia > > > > > > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > > > > wrote: > > > > Hello ADs, Directorate, Chairs, > > > > Interesting questions, thanks for caring and asking. > > > > I am probably going to cut my answer into separate independent = mails, > > as there are vastly different topics in this question. > > > > First, as a member of the RTG Directorate, I actually feel a little > > "under-utilized". An occasional review of an I-D at an extremely = late > > state of its process, and a very rare more global question like = this. > > As has been discussed widely lately, ADs are overworked and have too > > little time, so perhaps they do not call on the directorate enough - > > and, also, delegation of tasks that the ADs have to do is probably = perceived > as rather hard. > > > > I've been dumbfounded by some of the reviews I have seen from ADs, > > either during AD Evaluation or IESG Reviews: one particular case = came > > to mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT > > to the tracker during IESG Evaluation. It doesn't matter what = document > > or WG it was, what matters is that (i) it doesn't scale IETF-wide, > > (ii) it's poor use of Adrian's time, > > (iii) there wasn't really something in the DISCUSS/COMMENTs that > > required the wizardry of a yellow dot (just some routing = background), > > and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT > > during IESG Evaluation really isn't helpful to the document > > authors...its late, design decisions have been made, which are being > > questioned, etc....it tires people out, pisses off authors, and = frustrates > everybody involved. > > > > So, I've been playing around with a couple of ideas on the sideline, > > unofficially, and with only unwitting assistance from others = involved.... > > > > Thought #1: > > I-Ds - when called for adoption as WG documents, or when published = as > > draft-ietf-...-00's, gets someone from the directorate assigned, to > > provide an initial review and thoughts on "what directions would be > > good to take (or > > avoid) here". That same reviewer can, occasionally, be invoked by = the > > WG chairs or authors, in the "so, did we catch this right?" -- and, = of > > course, should be called in on the WGLC of the document. I think of = it > > a little as the "area advisors" but to a document rather than a WG = as a > whole. > > > > I've been playing around with that a bit, as an author: > > > > o Since I know very little about security, I've looped = in > > somebody who did, when > > having published a -00, and again the same person as > > needed later in the process. > > I've gotten hugely valuable feedback - making the > > ultimate SEC-DIR and SEC-AD > > reviews a lot less painful for me (and, given how > > little I knew about security, presumably > > less frustrating/time-consuming for the ADs, too, > > than if I had been just shooting blind). > > > > o Since I know even less about OPS stuff, Adrian = looped an OPS > > guy in on an > > individual -01, who asked a lot of good questions to > > what we were doing, and why, > > and which is hugely helpful. > > > > As an author in the RTG Area, the SEC and OPS ADs are often real > > "roadblocks". Reasonably so, of course, they represent important = concerns. > > And gosh, every time I encounter any AD, I have to explain the whole > > context over once again since, even if they've already gotten the > > story once, they have to follow sufficiently many documents and = topics > > that something is bound to be flushed from their cache. > > > > Having someone, from the respective directorate, be more of a > > facilitator, sparring-partner, and who - over time - follows the > > document (and, presumably, follows much fewer documents = concurrently) > > through the process with the authors would be great, as an author. = And > > possibly makes the ADs encounter less poor documents. > > > > I know that Adrian can (cf. the aforementioned 10-page > > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS = folks, > > and I have no reason to not expect Alia to have the same high (or > > higher) standards....so I imagine that a way the RTG-DIR could help > > "improve the image of the ADs" and at the same time get the ADs time > > liberated from writing 10-page discusses, would be something like = the > above.... > > > > In short, what I envision is a structured way of getting: > > o very early-reviews > > o a semi-permanent attachment of a reviewer from the > > directorateS to a document > > o this, through the documents lifecycle. > > > > Not sure if it scales, either, but as an author I've greatly enjoyed > > having such a "ongoing relationship" with people helping me avoid = pitfalls. > > > > A final note: having been around for a while in the IETF, it is = really > > easy to ask around for help from among other IETFers that one knows = -- > > then again, having been around for a while, presumably one has more > > experience and needs less help in avoiding pitfalls. For a new(ish) > > author, who knows few people and who presumably might be likely to > > need more help in avoiding said pitfalls, it's a lot harder to > > actually reach out and get the right people's eyes on a document -- > > and, even to know what eyes are good to get on it. > > > > This might, actually, therefore be also a good way of the IETF to be > > more welcoming and inclusive to new folks wanting to get involved. > > > > Thought #2: > > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > > version of thought #1 is to have a more structure directorate review > > cycle during IETF LC, or perhaps during "Publication Requested" and > > before "AD Evaluation". I am thinking that these be of the form: an > > I-D hits the AD, the responsible/sponsoring AD requests directorate > > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, = TSP, > > ...). Authors and reviewer iterate until either (i) issues are = squared > > off or (ii) either authors or reviewer declare the other as > > "bat-crap-crazy" (or, complains that the other side is not = responsive) > > and raise the issue to the AD. AD moves the document forward to "AD > > Evaluation" only once happy with the outcome of directorate reviews. > > In short, hiving out a lot more of the "problem fixing" that happens > > during these reviews off to the directorates - and leaving ADs to = process > presumably "less broken" documents. > > > > As an author, I have actually found it a LOT easier/faster to = iterate > > with a directorate reviewer (who has my document fresh in mind), = than > > with an AD who's preoccupied with a dozen or so documents at the = same > > time, and other emergencies. Now, mind you, some ADs are good at > > saying "Busy, will come back to you in n days" -- others, alas, do > > "play dead" if they feel they have more important fish to fry, and = that's > frustrating. > > > > This might lessen the load on the ADs, but still has the = disadvantage > > that one gets feedback *very* late in the process....just a little = bit > > earlier than during IESG processing. > > > > Thought #3: > > I thought it's worth calling out, that either of the above are not > > really related to RTG documents: I should think that RTG WG Chairs = are > > plenty able to do the necessary during WG processing, and as an = author > > in the RTG Area, I do usually know how to grab someone competent = from > > the same area for advice, as needed. While doing something like this > > intra-area can be a good thing, the real boast that I, as document > > author, have felt has been through getting cross-area feedback. Just > > as (being forced to be) reviewing document outside of the RTG area = has > been hugely educational and. > > > > Cheers, > > > > Thomas > > > > > > > > On 21 Mar 2014, at 19:31, Adrian Farrel wrote: > > > >> Hello Directorate and WG chairs, > >> > >> Alia and I have been discussing the Routing Area, its work, its > >> output, and its working groups. > >> > >> We have reached a conclusion (which perhaps we should have come to > >> sooner) that we need your help and input. > >> > >> The crunch question for us is "What makes it hard to get work done = in > >> the Routing Area?" What gets in the way of your work? What is = making > >> life hard for document authors? How could working groups be doing > >> better? We are open to all and every type of answer. We are happy = to > >> have quick, one-line answers or deeply-considered essays. > >> > >> What do you think? > >> > >> Thanks for all your input, > >> Adrian and Alia > >> > >> PS Please respond to both aliases because not everyone is on both = lists. > >> Sorry > >> that that means some of you will get duplicates. > >> > > > > > > > > > > > > From nobody Thu Mar 27 02:49:19 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8619D1A04B4; Thu, 27 Mar 2014 02:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Ly8YhjehX2_0; Thu, 27 Mar 2014 02:49:12 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B57C61A010C; Thu, 27 Mar 2014 02:49:11 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 849F7180150F; Thu, 27 Mar 2014 10:49:08 +0100 (CET) Message-ID: <5333F413.1080302@pi.nu> Date: Thu, 27 Mar 2014 10:49:07 +0100 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Lizhong Jin References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <032601cf4962$b5785aa0$20690fe0$@gmail.com> <034901cf4995$8875ccd0$99616670$@gmail.com> In-Reply-To: <034901cf4995$8875ccd0$99616670$@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/EaSDK7XREewQXdnm5_bpPt2lkxw Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Adopting wg doc - Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 09:49:17 -0000 Lizhong, This is a bit odd - I've worrying a bit over the last year or two that we are putting a too high threshold on the documents to make them working group documents :) ! Well, we might both be right, I think we are looking at slightly different things. We started the MPLS review team about to years ago (for those of you that don't know - the MPLS RT is a group of people with experiences of mpls, that helps the working group chairs if it is time to start the process to make a draft a working group document). The instructions we give the the reviewers are: Reviews should comment on whether the document is - coherent - useful (ie, is it likely to be actually useful in operational networks), - technically sound Now if things are missing this might show up as that the document is not technically sound, but I think this depends quite a bit on "how" things are missing. If we know that that it is rather straightforward to add the missing parts, then I don't see any reason not to adopt it as a working group document. On the the other hand if we suspect that the missing part is a major ostacle then we should make sure that we have a path forward. There is a value in adopting documents as wg docs, the revision control is taken over by the wg group, and the the authors might be given directives (aligned with wg consensus) what to to with the document. Also if things drags out to long, the wg for example has the possibility to appoint an editor to drive the document. Individual documents are up to the authors only. The working group could also decide not to progress a working document further. /Loa On 2014-03-27 09:21, Lizhong Jin wrote: > Andy, > Thank you for the explanation. I fully agree that it is not an easy job to set the barrier for each draft. Setting a bit higher barrier for WG adoption will improve the document quality. An excellent single-author draft will not be killed by the barrier if it indeed values much. > > Regards > Lizhong > >> -----Original Message----- >> From: Andrew G. Malis [mailto:agmalis@gmail.com] >> Sent: 2014年3月27日 15:42 >> To: Lizhong Jin >> Cc: Alia Atlas; Thomas Clausen; Adrian Farrel; Alia Atlas; rtg-dir@ietf.org; rtg- >> chairs@ietf.org >> Subject: Re: [RTG-DIR] Routing Area Health Check >> >> Lizhong, >> >> I don't know if I quite agree with your generalization. Like children, every >> working group is different, and every draft is different, and as a result there >> are varying qualifications to WG adoption. Certainly at the very least there >> needs to be some amount of interest in the WG and a rough consensus to >> adopt a draft, but it's more complicated than that. Sometimes there are >> drafts that are a part of a set of drafts contributing to a coordinated overall >> effort. In those cases, the barrier to WG adoption is lower because each draft >> is a necessary part of the whole. In the case of a single-author stand-alone >> draft, the barrier may be a bit higher to show the value of the draft, but >> there have been many excellent single-author drafts and resulting RFCs.A >> draft's IPR status can also affect a WG's judgement on whether to adopt it. >> >> But of course, in your own judgement, if you see a WG adoption poll and you >> really don't think the WG should be spending its time on it, respond to the >> poll! That's really all of our responsibilities. >> >> Cheers, >> Andy >> >> >> On Thu, Mar 27, 2014 at 3:17 AM, Lizhong Jin wrote: >>> Hi Adrian, Alia, >>> >>> As a non-English speaker, I am very happy to see the language review. >>> >>> Regarding the question "What makes it hard to get work done in the >>> Routing Area?", one of my concern is the relax of WG document adoption. >>> >>> From my feeling of IETF 8-10 years ago, every IETF draft will be only >>> adopted when the solution is concrete, complete and feasible, and got >>> various support from many vendors. But now it seems the draft could be >>> adopted if some necessary technical part is missing, or it gets >>> support from only one company. Many draft authors pay much attention >>> before WG adoption, but will focus less after adopted. >>> >>> I am not sure if others have the same feeling with me. Please correct >>> me if I have some inaccurate understanding of IETF process. >>> >>> >>> >>> Regards >>> >>> Lizhong >>> >>> >>> >>> >>> >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia >>> Atlas >>> Sent: 2014年3月26日 3:13 >>> To: Thomas Clausen >>> >>> >>> Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; >>> Subject: Re: [RTG-DIR] Routing Area Health Check >>> >>> >>> >>> Adrian and I have discussed the need for good early review and follow >>> through of drafts starting with >>> >>> WG adoption. We have also heard that the Routing Directorate could be >>> used more (though the situation may >>> >>> vary by individual). >>> >>> >>> >>> We are writing up the idea of a "Document Mentor". More details to >> follow >>> (plan for next week) once Adrian >>> >>> and I have agreement on paper for the idea. >>> >>> >>> >>> As far as English language mentoring, it sounds like George, Loa, and >>> Ross have a trial run going in MPLS. >>> >>> We can discuss having common organization for volunteers on each WG's >>> wiki or on the routing-area wiki. >>> >>> >>> >>> Thoughts? >>> >>> >>> >>> Alia >>> >>> >>> >>> On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen >>> >>> wrote: >>> >>> Alia, >>> >>> >>> >>> On 25 Mar 2014, at 15:58, Alia Atlas wrote: >>> >>> >>> >>> Thomas, >>> >>> >>> >>> Thanks very much for your thoughts. On the being underutilized and on >>> cross-area review, what do you and others in the Routing Directorate >>> think about being asked to follow a single additional working group >>> that is not in RTG and may have routing related issues? >>> >>> >>> >>> Can't speak for the others, but I'd be glad to, personally. >>> >>> >>> >>> >>> >>> For the time speedup of ADs, I'm told that it'd be really really >>> useful to have more active document shepherds - who can facilitate >>> getting comments and having them addressed. I'm not sure how to put >> that into place really. >>> As a WG chair, I felt like I was processing and pushing few enough >>> drafts that I could do the shepherd job also - but I know that there >>> are some WGs where there is higher throughput. It's also a good way >>> of growing a person, to let them see the whole process and deal with the >> discussions. >>> >>> >>> >>> That is a good point. Honestly, I do not know, and am really torn on >>> this issue. >>> >>> >>> >>> On one hand, sometimes having a shepherd as "go-between" to whip lazy >>> ADs ;) or reviewers to come back with "So, did this address your >>> concerns?" could perhaps be helpful. Oftentimes, however - and this is >>> the "have been in this for long enough to have many of the ADs on >>> Jabber by now" - the shepherd is >>> just-another-go-in-the-way: popping an IM to Adrian (or whoever), >>> getting a resolution, moving on, is a faster way of waking him up from >>> hibernation than waiting for a third-party to do the same. Same for an >>> AD holding a discuss, adding an extra intermediary to go through >>> ....not sold on the idea. >>> >>> >>> >>> So, I really do not know what to think about this. In the rare cases >>> where I have needed some whipping that I couldn't do myself, it has >>> been an AD so non-responsive that I doubt that a shepherd would do >>> (was a long time ago) and it required several other ADs ganging >>> up....or (more recently) where there was an issue with IANA requiring >>> resolution (Adrian helped out there, but possibly somebody else could >> have, too). >>> >>> >>> >>> For the drafts, I'd love to see earlier reviews. I'm not sure if at >>> WG adoption is quite the right time, but it is a good approximation of >>> "early in the process". >>> >>> >>> >>> I agree. It was just the least-arbitrary version number I could come >>> up with on short notice ;) >>> >>> >>> >>> We could ask WG chairs to request a reviewer at that point for drafts >>> that may need it and see what the load looks like. For a start-up, >>> having interested WG chairs identify WG drafts that could benefit from >>> review would be helpful/interesting in terms of seeing the workload. >>> >>> >>> >>> Can't disagree on this. >>> >>> >>> >>> Thomas >>> >>> >>> >>> >>> >>> Regards, >>> >>> Alia >>> >>> >>> >>> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen >>> >>> wrote: >>> >>> Hello ADs, Directorate, Chairs, >>> >>> Interesting questions, thanks for caring and asking. >>> >>> I am probably going to cut my answer into separate independent mails, >>> as there are vastly different topics in this question. >>> >>> First, as a member of the RTG Directorate, I actually feel a little >>> "under-utilized". An occasional review of an I-D at an extremely late >>> state of its process, and a very rare more global question like this. >>> As has been discussed widely lately, ADs are overworked and have too >>> little time, so perhaps they do not call on the directorate enough - >>> and, also, delegation of tasks that the ADs have to do is probably perceived >> as rather hard. >>> >>> I've been dumbfounded by some of the reviews I have seen from ADs, >>> either during AD Evaluation or IESG Reviews: one particular case came >>> to mind where Adrian sent what looked like a 10-page DISCUSS/COMMENT >>> to the tracker during IESG Evaluation. It doesn't matter what document >>> or WG it was, what matters is that (i) it doesn't scale IETF-wide, >>> (ii) it's poor use of Adrian's time, >>> (iii) there wasn't really something in the DISCUSS/COMMENTs that >>> required the wizardry of a yellow dot (just some routing background), >>> and -- most importantly -- (iv) getting a 10-page DISCUSS/COMMENT >>> during IESG Evaluation really isn't helpful to the document >>> authors...its late, design decisions have been made, which are being >>> questioned, etc....it tires people out, pisses off authors, and frustrates >> everybody involved. >>> >>> So, I've been playing around with a couple of ideas on the sideline, >>> unofficially, and with only unwitting assistance from others involved.... >>> >>> Thought #1: >>> I-Ds - when called for adoption as WG documents, or when published as >>> draft-ietf-...-00's, gets someone from the directorate assigned, to >>> provide an initial review and thoughts on "what directions would be >>> good to take (or >>> avoid) here". That same reviewer can, occasionally, be invoked by the >>> WG chairs or authors, in the "so, did we catch this right?" -- and, of >>> course, should be called in on the WGLC of the document. I think of it >>> a little as the "area advisors" but to a document rather than a WG as a >> whole. >>> >>> I've been playing around with that a bit, as an author: >>> >>> o Since I know very little about security, I've looped in >>> somebody who did, when >>> having published a -00, and again the same person as >>> needed later in the process. >>> I've gotten hugely valuable feedback - making the >>> ultimate SEC-DIR and SEC-AD >>> reviews a lot less painful for me (and, given how >>> little I knew about security, presumably >>> less frustrating/time-consuming for the ADs, too, >>> than if I had been just shooting blind). >>> >>> o Since I know even less about OPS stuff, Adrian looped an OPS >>> guy in on an >>> individual -01, who asked a lot of good questions to >>> what we were doing, and why, >>> and which is hugely helpful. >>> >>> As an author in the RTG Area, the SEC and OPS ADs are often real >>> "roadblocks". Reasonably so, of course, they represent important concerns. >>> And gosh, every time I encounter any AD, I have to explain the whole >>> context over once again since, even if they've already gotten the >>> story once, they have to follow sufficiently many documents and topics >>> that something is bound to be flushed from their cache. >>> >>> Having someone, from the respective directorate, be more of a >>> facilitator, sparring-partner, and who - over time - follows the >>> document (and, presumably, follows much fewer documents concurrently) >>> through the process with the authors would be great, as an author. And >>> possibly makes the ADs encounter less poor documents. >>> >>> I know that Adrian can (cf. the aforementioned 10-page >>> DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS folks, >>> and I have no reason to not expect Alia to have the same high (or >>> higher) standards....so I imagine that a way the RTG-DIR could help >>> "improve the image of the ADs" and at the same time get the ADs time >>> liberated from writing 10-page discusses, would be something like the >> above.... >>> >>> In short, what I envision is a structured way of getting: >>> o very early-reviews >>> o a semi-permanent attachment of a reviewer from the >>> directorateS to a document >>> o this, through the documents lifecycle. >>> >>> Not sure if it scales, either, but as an author I've greatly enjoyed >>> having such a "ongoing relationship" with people helping me avoid pitfalls. >>> >>> A final note: having been around for a while in the IETF, it is really >>> easy to ask around for help from among other IETFers that one knows -- >>> then again, having been around for a while, presumably one has more >>> experience and needs less help in avoiding pitfalls. For a new(ish) >>> author, who knows few people and who presumably might be likely to >>> need more help in avoiding said pitfalls, it's a lot harder to >>> actually reach out and get the right people's eyes on a document -- >>> and, even to know what eyes are good to get on it. >>> >>> This might, actually, therefore be also a good way of the IETF to be >>> more welcoming and inclusive to new folks wanting to get involved. >>> >>> Thought #2: >>> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter >>> version of thought #1 is to have a more structure directorate review >>> cycle during IETF LC, or perhaps during "Publication Requested" and >>> before "AD Evaluation". I am thinking that these be of the form: an >>> I-D hits the AD, the responsible/sponsoring AD requests directorate >>> reviews from all the concerned directorates (GEN, SEC, OPS, RTG, TSP, >>> ...). Authors and reviewer iterate until either (i) issues are squared >>> off or (ii) either authors or reviewer declare the other as >>> "bat-crap-crazy" (or, complains that the other side is not responsive) >>> and raise the issue to the AD. AD moves the document forward to "AD >>> Evaluation" only once happy with the outcome of directorate reviews. >>> In short, hiving out a lot more of the "problem fixing" that happens >>> during these reviews off to the directorates - and leaving ADs to process >> presumably "less broken" documents. >>> >>> As an author, I have actually found it a LOT easier/faster to iterate >>> with a directorate reviewer (who has my document fresh in mind), than >>> with an AD who's preoccupied with a dozen or so documents at the same >>> time, and other emergencies. Now, mind you, some ADs are good at >>> saying "Busy, will come back to you in n days" -- others, alas, do >>> "play dead" if they feel they have more important fish to fry, and that's >> frustrating. >>> >>> This might lessen the load on the ADs, but still has the disadvantage >>> that one gets feedback *very* late in the process....just a little bit >>> earlier than during IESG processing. >>> >>> Thought #3: >>> I thought it's worth calling out, that either of the above are not >>> really related to RTG documents: I should think that RTG WG Chairs are >>> plenty able to do the necessary during WG processing, and as an author >>> in the RTG Area, I do usually know how to grab someone competent from >>> the same area for advice, as needed. While doing something like this >>> intra-area can be a good thing, the real boast that I, as document >>> author, have felt has been through getting cross-area feedback. Just >>> as (being forced to be) reviewing document outside of the RTG area has >> been hugely educational and. >>> >>> Cheers, >>> >>> Thomas >>> >>> >>> >>> On 21 Mar 2014, at 19:31, Adrian Farrel wrote: >>> >>>> Hello Directorate and WG chairs, >>>> >>>> Alia and I have been discussing the Routing Area, its work, its >>>> output, and its working groups. >>>> >>>> We have reached a conclusion (which perhaps we should have come to >>>> sooner) that we need your help and input. >>>> >>>> The crunch question for us is "What makes it hard to get work done in >>>> the Routing Area?" What gets in the way of your work? What is making >>>> life hard for document authors? How could working groups be doing >>>> better? We are open to all and every type of answer. We are happy to >>>> have quick, one-line answers or deeply-considered essays. >>>> >>>> What do you think? >>>> >>>> Thanks for all your input, >>>> Adrian and Alia >>>> >>>> PS Please respond to both aliases because not everyone is on both lists. >>>> Sorry >>>> that that means some of you will get duplicates. >>>> >>> >>> >>> >>> >>> >>> > -- 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 Mar 27 13:57:39 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E098A1A03D5; Thu, 27 Mar 2014 13:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jFL6vh0njdS5; Thu, 27 Mar 2014 13:57:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id 34B2F1A06A7; Thu, 27 Mar 2014 13:57:31 -0700 (PDT) Received: from mail203-tx2-R.bigfish.com (10.9.14.247) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Thu, 27 Mar 2014 20:57:29 +0000 Received: from mail203-tx2 (localhost [127.0.0.1]) by mail203-tx2-R.bigfish.com (Postfix) with ESMTP id 177439000BF; Thu, 27 Mar 2014 20:57:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I1b0aL148cI542I1dbaI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh268bh9a9j1155h) Received-SPF: pass (mail203-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=akatlas@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(13464003)(377454003)(479174003)(199002)(189002)(51704005)(52604005)(69224002)(74366001)(81342001)(33646001)(53806001)(76482001)(81686001)(54316002)(56776001)(97336001)(77096001)(47446002)(74502001)(51856001)(31966008)(74662001)(54356001)(98676001)(76576001)(74316001)(76796001)(76786001)(74876001)(74706001)(79102001)(56816005)(83072002)(65816001)(90146001)(86362001)(4396001)(81542001)(85852003)(69226001)(49866001)(2656002)(97186001)(87936001)(87266001)(80022001)(47736001)(20776003)(19580405001)(66066001)(92566001)(19580395003)(81816001)(93136001)(85306002)(83322001)(46102001)(63696002)(80976001)(77982001)(95666003)(93516002)(47976001)(50986001)(94316002)(95416001)(59766001)(94946001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB626; H:BL2PR05MB193.namprd05.prod.outlook.com; FPR:EE9BF265.8FFA93E1.B8D37DBB.4AEA6370.2089E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail203-tx2 (localhost.localdomain [127.0.0.1]) by mail203-tx2 (MessageSwitch) id 1395953847618195_25393; Thu, 27 Mar 2014 20:57:27 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.231]) by mail203-tx2.bigfish.com (Postfix) with ESMTP id 939102000BE; Thu, 27 Mar 2014 20:57:27 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 27 Mar 2014 20:57:20 +0000 Received: from BLUPR05MB626.namprd05.prod.outlook.com (10.141.204.143) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.435.0; Thu, 27 Mar 2014 20:57:17 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com (10.242.198.143) by BLUPR05MB626.namprd05.prod.outlook.com (10.141.204.143) with Microsoft SMTP Server (TLS) id 15.0.908.10; Thu, 27 Mar 2014 20:57:15 +0000 Received: from BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.244]) by BL2PR05MB193.namprd05.prod.outlook.com ([169.254.9.244]) with mapi id 15.00.0908.008; Thu, 27 Mar 2014 20:57:15 +0000 From: Alia Atlas To: Ross Callon Thread-Topic: [RTG-DIR] Routing Area Health Check Thread-Index: Ac9FM7jUfY2bVLKWR8OERB4dO9zkEgDBC8uAAACyXgAABd4KAAAHlSjAAGOUgEA= Date: Thu, 27 Mar 2014 20:57:14 +0000 Message-ID: References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <5331C0FA.3040008@joelhalpern.com> <6d4791ca7767452ba7938334e5382246@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <6d4791ca7767452ba7938334e5382246@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 01630974C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/StdPOmGAXWuo7h9RQ5GGjdgNoz0 Cc: Adrian Farrel , "" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 20:57:38 -0000 My understanding is that the "routing area advisors" are for WGs where it s= eems the WG has a substantial amount of work that overlaps into routing. T= he advisors are there primarily as a resource to the WG chairs (and WG). In this case, the goal is to have more ears paying attention and reporting = back if there are drafts that should be looked at before it's "too late". = Providing clue is also desirable, of course. -----Original Message----- From: Ross Callon=20 Sent: Tuesday, March 25, 2014 5:27 PM To: Joel M. Halpern; Alia Atlas; Thomas Clausen Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; Subject: RE: [RTG-DIR] Routing Area Health Check How does this differ from the "routing area advisors" who have occasionally= been assigned to WGs in the past? In some cases these routing area advisor= s were ADs, but in some cases not. In my experience the routing area adviso= rs rarely did much (if anything).=20 It has also been unclear (at least to me) what if any authority went with b= eing the routing area advisor to a WG from another area.=20 Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Joel M. Halper= n Sent: Tuesday, March 25, 2014 1:47 PM To: Alia Atlas; Thomas Clausen Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; Subject: Re: [RTG-DIR] Routing Area Health Check I am a little concerned that assigned directorate members to working groups= will produce negative effects: 1) It will lead to more scheduling conflict. 2) It will lead to an assumption that this one person will review all the o= utput of a given WG. I think we are actually better off if that task somet= imes moves, as it ensures that fresh eyes are looking, for example to detec= t that assumptions are actually stated rather than merely in the minds of t= he WG. Yours, Joel On 3/25/14, 10:58 AM, Alia Atlas wrote: > Thomas, > > Thanks very much for your thoughts. On the being underutilized and on=20 > cross-area review, what do you and others in the Routing Directorate=20 > think about being asked to follow a single additional working group=20 > that is not in RTG and may have routing related issues? > > For the time speedup of ADs, I'm told that it'd be really really=20 > useful to have more active document shepherds - who can facilitate=20 > getting comments and having them addressed. I'm not sure how to put=20 > that into place really. As a WG chair, I felt like I was processing=20 > and pushing few enough drafts that I could do the shepherd job also -=20 > but I know that there are some WGs where there is higher throughput. =20 > It's also a good way of growing a person, to let them see the whole=20 > process and deal with the discussions. > > For the drafts, I'd love to see earlier reviews. I'm not sure if at=20 > WG adoption is quite the right time, but it is a good approximation of > "early in the process". We could ask WG chairs to request a reviewer > at that point for drafts that may need it and see what the load looks=20 > like. For a start-up, having interested WG chairs identify WG drafts=20 > that could benefit from review would be helpful/interesting in terms=20 > of seeing the workload. > > Regards, > Alia > > > On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen=20 > > wrote: > > Hello ADs, Directorate, Chairs, > > Interesting questions, thanks for caring and asking. > > I am probably going to cut my answer into separate independent > mails, as there are vastly different topics in this question. > > First, as a member of the RTG Directorate, I actually feel a little > "under-utilized". An occasional review of an I-D at an extremely > late state of its process, and a very rare more global question like > this. As has been discussed widely lately, ADs are overworked and > have too little time, so perhaps they do not call on the directorate > enough - and, also, delegation of tasks that the ADs have to do is > probably perceived as rather hard. > > I've been dumbfounded by some of the reviews I have seen from ADs, > either during AD Evaluation or IESG Reviews: one particular case > came to mind where Adrian sent what looked like a 10-page > DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't > matter what document or WG it was, what matters is that (i) it > doesn't scale IETF-wide, (ii) it's poor use of Adrian's time, (iii) > there wasn't really something in the DISCUSS/COMMENTs that required > the wizardry of a yellow dot (just some routing background), and -- > most importantly -- (iv) getting a 10-page DISCUSS/COMMENT during > IESG Evaluation really isn't helpful to the document authors...its > late, design decisions have been made, which are being questioned, > etc....it tires people out, pisses off authors, and frustrates > everybody involved. > > So, I've been playing around with a couple of ideas on the sideline, > unofficially, and with only unwitting assistance from others > involved.... > > Thought #1: > I-Ds - when called for adoption as WG documents, or when published > as draft-ietf-...-00's, gets someone from the directorate assigned, > to provide an initial review and thoughts on "what directions would > be good to take (or avoid) here". That same reviewer can, > occasionally, be invoked by the WG chairs or authors, in the "so, > did we catch this right?" -- and, of course, should be called in on > the WGLC of the document. I think of it a little as the "area > advisors" but to a document rather than a WG as a whole. > > I've been playing around with that a bit, as an author: > > o Since I know very little about security, I've > looped in somebody who did, when > having published a -00, and again the same person > as needed later in the process. > I've gotten hugely valuable feedback - making the > ultimate SEC-DIR and SEC-AD > reviews a lot less painful for me (and, given how > little I knew about security, presumably > less frustrating/time-consuming for the ADs, too, > than if I had been just shooting blind). > > o Since I know even less about OPS stuff, Adrian > looped an OPS guy in on an > individual -01, who asked a lot of good questions > to what we were doing, and why, > and which is hugely helpful. > > As an author in the RTG Area, the SEC and OPS ADs are often real > "roadblocks". Reasonably so, of course, they represent important > concerns. And gosh, every time I encounter any AD, I have to explain > the whole context over once again since, even if they've already > gotten the story once, they have to follow sufficiently many > documents and topics that something is bound to be flushed from > their cache. > > Having someone, from the respective directorate, be more of a > facilitator, sparring-partner, and who - over time - follows the > document (and, presumably, follows much fewer documents > concurrently) through the process with the authors would be great, > as an author. And possibly makes the ADs encounter less poor document= s. > > I know that Adrian can (cf. the aforementioned 10-page > DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS > folks, and I have no reason to not expect Alia to have the same high > (or higher) standards....so I imagine that a way the RTG-DIR could > help "improve the image of the ADs" and at the same time get the ADs > time liberated from writing 10-page discusses, would be something > like the above.... > > In short, what I envision is a structured way of getting: > o very early-reviews > o a semi-permanent attachment of a reviewer from the > directorateS to a document > o this, through the documents lifecycle. > > Not sure if it scales, either, but as an author I've greatly enjoyed > having such a "ongoing relationship" with people helping me avoid > pitfalls. > > A final note: having been around for a while in the IETF, it is > really easy to ask around for help from among other IETFers that one > knows -- then again, having been around for a while, presumably one > has more experience and needs less help in avoiding pitfalls. For a > new(ish) author, who knows few people and who presumably might be > likely to need more help in avoiding said pitfalls, it's a lot > harder to actually reach out and get the right people's eyes on a > document -- and, even to know what eyes are good to get on it. > > This might, actually, therefore be also a good way of the IETF to be > more welcoming and inclusive to new folks wanting to get involved. > > Thought #2: > So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > version of thought #1 is to have a more structure directorate review > cycle during IETF LC, or perhaps during "Publication Requested" and > before "AD Evaluation". I am thinking that these be of the form: an > I-D hits the AD, the responsible/sponsoring AD requests directorate > reviews from all the concerned directorates (GEN, SEC, OPS, RTG, > TSP, ...). Authors and reviewer iterate until either (i) issues are > squared off or (ii) either authors or reviewer declare the other as > "bat-crap-crazy" (or, complains that the other side is not > responsive) and raise the issue to the AD. AD moves the document > forward to "AD Evaluation" only once happy with the outcome of > directorate reviews. In short, hiving out a lot more of the "problem > fixing" that happens during these reviews off to the directorates - > and leaving ADs to process presumably "less broken" documents. > > As an author, I have actually found it a LOT easier/faster to > iterate with a directorate reviewer (who has my document fresh in > mind), than with an AD who's preoccupied with a dozen or so > documents at the same time, and other emergencies. Now, mind you, > some ADs are good at saying "Busy, will come back to you in n days" > -- others, alas, do "play dead" if they feel they have more > important fish to fry, and that's frustrating. > > This might lessen the load on the ADs, but still has the > disadvantage that one gets feedback *very* late in the > process....just a little bit earlier than during IESG processing. > > Thought #3: > I thought it's worth calling out, that either of the above are not > really related to RTG documents: I should think that RTG WG Chairs > are plenty able to do the necessary during WG processing, and as an > author in the RTG Area, I do usually know how to grab someone > competent from the same area for advice, as needed. While doing > something like this intra-area can be a good thing, the real boast > that I, as document author, have felt has been through getting > cross-area feedback. Just as (being forced to be) reviewing document > outside of the RTG area has been hugely educational and. > > Cheers, > > Thomas > > > On 21 Mar 2014, at 19:31, Adrian Farrel > wrote: > > > Hello Directorate and WG chairs, > > > > Alia and I have been discussing the Routing Area, its work, its > output, and its > > working groups. > > > > We have reached a conclusion (which perhaps we should have come > to sooner) that > > we need your help and input. > > > > The crunch question for us is "What makes it hard to get work > done in the > > Routing Area?" What gets in the way of your work? What is making > life hard for > > document authors? How could working groups be doing better? We > are open to all > > and every type of answer. We are happy to have quick, one-line > answers or > > deeply-considered essays. > > > > What do you think? > > > > Thanks for all your input, > > Adrian and Alia > > > > PS Please respond to both aliases because not everyone is on both > lists. Sorry > > that that means some of you will get duplicates. > > > > From nobody Thu Mar 27 19:00:03 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF741A0422; Thu, 27 Mar 2014 19:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 RW_RYsgwX-xj; Thu, 27 Mar 2014 18:59:58 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6511A041F; Thu, 27 Mar 2014 18:59:57 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id v10so4177499pde.29 for ; Thu, 27 Mar 2014 18:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=P47krbW+wigBChZg71vKDoa6Ro8lYoct7QQf3HcsxVw=; b=Ky7Kg7KBx1klSZPulMSUrqQ3SpQ8CzkRbYO4CrCLNV/F+pwao9G4SzGX3mxtW1gfUW Y0FlZxa9TcNn6jrtKymo8rVrSp8Q4jG/kuvY/JywqkoXgrgirQatEN2edGcS8TxryFHD YA5bdyY/oE3oMRVWQ4HgLc3uJiKVU0/MD5WZ8gQK706VEx7qZ+qCi2BKFHRvssGHpGRH sz7320votTbGCQkARIpINotLbxYlcwPzOCkAAEFBewpMYJSZxK/iNDCOl6O/5NXVBipO KHqh1qWicpCVhsCH1k6/CMbgw9EJzQHdfAgfrolbkh1nO5PN7rInofc7yEA9QflWIqzN yDVw== X-Received: by 10.67.14.231 with SMTP id fj7mr5267749pad.115.1395971996134; Thu, 27 Mar 2014 18:59:56 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id h6sm15585051pbl.75.2014.03.27.18.59.52 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Mar 2014 18:59:55 -0700 (PDT) From: "Lizhong Jin" To: "'Loa Andersson'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <032601cf4962$b5785aa0$20690fe0$@gmail.com> <034901cf4995$8875ccd0$99616670$@gmail.com> <5333F413.1080302@pi.nu> In-Reply-To: <5333F413.1080302@pi.nu> Date: Fri, 28 Mar 2014 09:59:49 +0800 Message-ID: <034b01cf4a29$697e6780$3c7b3680$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wF5D2kGAgX2wc8C6135DwLAQ7lLArB2Aw4Baf5JQQE/VjaDAPNroGqY485hIA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/RcogC7zHg0y1SbNgXzWWvEveDdc Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Adopting wg doc - Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 02:00:01 -0000 Hi Loa, MPLS is doing great. And the language review team will definitely be = helpful. Since my feeling is not common, I think that is a good thing for the = health of routing area. :) Regards Lizhong > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 2014=E5=B9=B43=E6=9C=8827=E6=97=A5 17:49 > To: Lizhong Jin > Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: Re: [RTG-DIR] Adopting wg doc - Routing Area Health Check >=20 > Lizhong, >=20 > This is a bit odd - I've worrying a bit over the last year or two that = we are > putting a too high threshold on the documents to make them working = group > documents :) ! >=20 > Well, we might both be right, I think we are looking at slightly = different things. >=20 > We started the MPLS review team about to years ago (for those of you = that > don't know - the MPLS RT is a group of people with experiences of = mpls, that > helps the working group chairs if it is time to start the process to = make a draft > a working group document). >=20 > The instructions we give the the reviewers are: >=20 > Reviews should comment on whether the document is > - coherent > - useful (ie, is it likely to be actually useful in operational > networks), > - technically sound >=20 > Now if things are missing this might show up as that the document is = not > technically sound, but I think this depends quite a bit on "how" = things are > missing. If we know that that it is rather straightforward to add the = missing > parts, then I don't see any reason not to adopt it as a working group > document. On the the other hand if we suspect that the missing part is = a > major ostacle then we should make sure that we have a path forward. >=20 > There is a value in adopting documents as wg docs, the revision = control is > taken over by the wg group, and the the authors might be given = directives > (aligned with wg consensus) what to to with the document. > Also if things drags out to long, the wg for example has the = possibility to > appoint an editor to drive the document. > Individual documents are up to the authors only. >=20 > The working group could also decide not to progress a working document > further. >=20 > /Loa >=20 >=20 > On 2014-03-27 09:21, Lizhong Jin wrote: > > Andy, > > Thank you for the explanation. I fully agree that it is not an easy = job to set > the barrier for each draft. Setting a bit higher barrier for WG = adoption will > improve the document quality. An excellent single-author draft will = not be > killed by the barrier if it indeed values much. > > > > Regards > > Lizhong > > > >> -----Original Message----- > >> From: Andrew G. Malis [mailto:agmalis@gmail.com] > >> Sent: 2014=E5=B9=B43=E6=9C=8827=E6=97=A5 15:42 > >> To: Lizhong Jin > >> Cc: Alia Atlas; Thomas Clausen; Adrian Farrel; Alia Atlas; > >> rtg-dir@ietf.org; rtg- chairs@ietf.org > >> Subject: Re: [RTG-DIR] Routing Area Health Check > >> > >> Lizhong, > >> > >> I don't know if I quite agree with your generalization. Like > >> children, every working group is different, and every draft is > >> different, and as a result there are varying qualifications to WG > >> adoption. Certainly at the very least there needs to be some amount > >> of interest in the WG and a rough consensus to adopt a draft, but > >> it's more complicated than that. Sometimes there are drafts that = are > >> a part of a set of drafts contributing to a coordinated overall > >> effort. In those cases, the barrier to WG adoption is lower because > >> each draft is a necessary part of the whole. In the case of a > >> single-author stand-alone draft, the barrier may be a bit higher to > >> show the value of the draft, but there have been many excellent = single- > author drafts and resulting RFCs.A draft's IPR status can also affect = a WG's > judgement on whether to adopt it. > >> > >> But of course, in your own judgement, if you see a WG adoption poll > >> and you really don't think the WG should be spending its time on = it, > >> respond to the poll! That's really all of our responsibilities. > >> > >> Cheers, > >> Andy > >> > >> > >> On Thu, Mar 27, 2014 at 3:17 AM, Lizhong Jin = wrote: > >>> Hi Adrian, Alia, > >>> > >>> As a non-English speaker, I am very happy to see the language = review. > >>> > >>> Regarding the question "What makes it hard to get work done in the > >>> Routing Area?", one of my concern is the relax of WG document > adoption. > >>> > >>> From my feeling of IETF 8-10 years ago, every IETF draft will be > >>> only adopted when the solution is concrete, complete and feasible, > >>> and got various support from many vendors. But now it seems the > >>> draft could be adopted if some necessary technical part is = missing, > >>> or it gets support from only one company. Many draft authors pay > >>> much attention before WG adoption, but will focus less after = adopted. > >>> > >>> I am not sure if others have the same feeling with me. Please > >>> correct me if I have some inaccurate understanding of IETF = process. > >>> > >>> > >>> > >>> Regards > >>> > >>> Lizhong > >>> > >>> > >>> > >>> > >>> > >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia > >>> Atlas > >>> Sent: 2014=E5=B9=B43=E6=9C=8826=E6=97=A5 3:13 > >>> To: Thomas Clausen > >>> > >>> > >>> Cc: Adrian Farrel; rtg-chairs@ietf.org; Alia Atlas; > >>> > >>> Subject: Re: [RTG-DIR] Routing Area Health Check > >>> > >>> > >>> > >>> Adrian and I have discussed the need for good early review and > >>> follow through of drafts starting with > >>> > >>> WG adoption. We have also heard that the Routing Directorate = could > >>> be used more (though the situation may > >>> > >>> vary by individual). > >>> > >>> > >>> > >>> We are writing up the idea of a "Document Mentor". More details = to > >> follow > >>> (plan for next week) once Adrian > >>> > >>> and I have agreement on paper for the idea. > >>> > >>> > >>> > >>> As far as English language mentoring, it sounds like George, Loa, > >>> and Ross have a trial run going in MPLS. > >>> > >>> We can discuss having common organization for volunteers on each > >>> WG's wiki or on the routing-area wiki. > >>> > >>> > >>> > >>> Thoughts? > >>> > >>> > >>> > >>> Alia > >>> > >>> > >>> > >>> On Tue, Mar 25, 2014 at 11:09 AM, Thomas Clausen > >>> > >>> wrote: > >>> > >>> Alia, > >>> > >>> > >>> > >>> On 25 Mar 2014, at 15:58, Alia Atlas wrote: > >>> > >>> > >>> > >>> Thomas, > >>> > >>> > >>> > >>> Thanks very much for your thoughts. On the being underutilized = and > >>> on cross-area review, what do you and others in the Routing > >>> Directorate think about being asked to follow a single additional > >>> working group that is not in RTG and may have routing related = issues? > >>> > >>> > >>> > >>> Can't speak for the others, but I'd be glad to, personally. > >>> > >>> > >>> > >>> > >>> > >>> For the time speedup of ADs, I'm told that it'd be really really > >>> useful to have more active document shepherds - who can facilitate > >>> getting comments and having them addressed. I'm not sure how to = put > >> that into place really. > >>> As a WG chair, I felt like I was processing and pushing few enough > >>> drafts that I could do the shepherd job also - but I know that = there > >>> are some WGs where there is higher throughput. It's also a good = way > >>> of growing a person, to let them see the whole process and deal = with > >>> the > >> discussions. > >>> > >>> > >>> > >>> That is a good point. Honestly, I do not know, and am really torn = on > >>> this issue. > >>> > >>> > >>> > >>> On one hand, sometimes having a shepherd as "go-between" to whip > >>> lazy ADs ;) or reviewers to come back with "So, did this address > >>> your concerns?" could perhaps be helpful. Oftentimes, however - = and > >>> this is the "have been in this for long enough to have many of the > >>> ADs on Jabber by now" - the shepherd is > >>> just-another-go-in-the-way: popping an IM to Adrian (or whoever), > >>> getting a resolution, moving on, is a faster way of waking him up > >>> from hibernation than waiting for a third-party to do the same. = Same > >>> for an AD holding a discuss, adding an extra intermediary to go > >>> through ....not sold on the idea. > >>> > >>> > >>> > >>> So, I really do not know what to think about this. In the rare = cases > >>> where I have needed some whipping that I couldn't do myself, it = has > >>> been an AD so non-responsive that I doubt that a shepherd would do > >>> (was a long time ago) and it required several other ADs ganging > >>> up....or (more recently) where there was an issue with IANA > >>> requiring resolution (Adrian helped out there, but possibly = somebody > >>> else could > >> have, too). > >>> > >>> > >>> > >>> For the drafts, I'd love to see earlier reviews. I'm not sure if = at > >>> WG adoption is quite the right time, but it is a good = approximation > >>> of "early in the process". > >>> > >>> > >>> > >>> I agree. It was just the least-arbitrary version number I could = come > >>> up with on short notice ;) > >>> > >>> > >>> > >>> We could ask WG chairs to request a reviewer at that point for > >>> drafts that may need it and see what the load looks like. For a > >>> start-up, having interested WG chairs identify WG drafts that = could > >>> benefit from review would be helpful/interesting in terms of = seeing the > workload. > >>> > >>> > >>> > >>> Can't disagree on this. > >>> > >>> > >>> > >>> Thomas > >>> > >>> > >>> > >>> > >>> > >>> Regards, > >>> > >>> Alia > >>> > >>> > >>> > >>> On Tue, Mar 25, 2014 at 10:38 AM, Thomas Clausen > >>> > >>> wrote: > >>> > >>> Hello ADs, Directorate, Chairs, > >>> > >>> Interesting questions, thanks for caring and asking. > >>> > >>> I am probably going to cut my answer into separate independent > >>> mails, as there are vastly different topics in this question. > >>> > >>> First, as a member of the RTG Directorate, I actually feel a = little > >>> "under-utilized". An occasional review of an I-D at an extremely > >>> late state of its process, and a very rare more global question = like this. > >>> As has been discussed widely lately, ADs are overworked and have = too > >>> little time, so perhaps they do not call on the directorate enough = - > >>> and, also, delegation of tasks that the ADs have to do is probably > >>> perceived > >> as rather hard. > >>> > >>> I've been dumbfounded by some of the reviews I have seen from ADs, > >>> either during AD Evaluation or IESG Reviews: one particular case > >>> came to mind where Adrian sent what looked like a 10-page > >>> DISCUSS/COMMENT to the tracker during IESG Evaluation. It doesn't > >>> matter what document or WG it was, what matters is that (i) it > >>> doesn't scale IETF-wide, > >>> (ii) it's poor use of Adrian's time, > >>> (iii) there wasn't really something in the DISCUSS/COMMENTs that > >>> required the wizardry of a yellow dot (just some routing > >>> background), and -- most importantly -- (iv) getting a 10-page > >>> DISCUSS/COMMENT during IESG Evaluation really isn't helpful to the > >>> document authors...its late, design decisions have been made, = which > >>> are being questioned, etc....it tires people out, pisses off > >>> authors, and frustrates > >> everybody involved. > >>> > >>> So, I've been playing around with a couple of ideas on the = sideline, > >>> unofficially, and with only unwitting assistance from others = involved.... > >>> > >>> Thought #1: > >>> I-Ds - when called for adoption as WG documents, or when published > >>> as draft-ietf-...-00's, gets someone from the directorate = assigned, > >>> to provide an initial review and thoughts on "what directions = would > >>> be good to take (or > >>> avoid) here". That same reviewer can, occasionally, be invoked by > >>> the WG chairs or authors, in the "so, did we catch this right?" -- > >>> and, of course, should be called in on the WGLC of the document. I > >>> think of it a little as the "area advisors" but to a document = rather > >>> than a WG as a > >> whole. > >>> > >>> I've been playing around with that a bit, as an author: > >>> > >>> o Since I know very little about security, I've = looped in > >>> somebody who did, when > >>> having published a -00, and again the same person > >>> as needed later in the process. > >>> I've gotten hugely valuable feedback - making = the > >>> ultimate SEC-DIR and SEC-AD > >>> reviews a lot less painful for me (and, given = how > >>> little I knew about security, presumably > >>> less frustrating/time-consuming for the ADs, = too, > >>> than if I had been just shooting blind). > >>> > >>> o Since I know even less about OPS stuff, Adrian = looped an OPS > >>> guy in on an > >>> individual -01, who asked a lot of good questions > >>> to what we were doing, and why, > >>> and which is hugely helpful. > >>> > >>> As an author in the RTG Area, the SEC and OPS ADs are often real > >>> "roadblocks". Reasonably so, of course, they represent important > concerns. > >>> And gosh, every time I encounter any AD, I have to explain the = whole > >>> context over once again since, even if they've already gotten the > >>> story once, they have to follow sufficiently many documents and > >>> topics that something is bound to be flushed from their cache. > >>> > >>> Having someone, from the respective directorate, be more of a > >>> facilitator, sparring-partner, and who - over time - follows the > >>> document (and, presumably, follows much fewer documents > >>> concurrently) through the process with the authors would be great, > >>> as an author. And possibly makes the ADs encounter less poor > documents. > >>> > >>> I know that Adrian can (cf. the aforementioned 10-page > >>> DISCUSS/COMMENT) be just as much of a roadblock as the SEC/OPS > >>> folks, and I have no reason to not expect Alia to have the same = high > >>> (or > >>> higher) standards....so I imagine that a way the RTG-DIR could = help > >>> "improve the image of the ADs" and at the same time get the ADs = time > >>> liberated from writing 10-page discusses, would be something like > >>> the > >> above.... > >>> > >>> In short, what I envision is a structured way of getting: > >>> o very early-reviews > >>> o a semi-permanent attachment of a reviewer from = the > >>> directorateS to a document > >>> o this, through the documents lifecycle. > >>> > >>> Not sure if it scales, either, but as an author I've greatly = enjoyed > >>> having such a "ongoing relationship" with people helping me avoid > pitfalls. > >>> > >>> A final note: having been around for a while in the IETF, it is > >>> really easy to ask around for help from among other IETFers that = one > >>> knows -- then again, having been around for a while, presumably = one > >>> has more experience and needs less help in avoiding pitfalls. For = a > >>> new(ish) author, who knows few people and who presumably might be > >>> likely to need more help in avoiding said pitfalls, it's a lot > >>> harder to actually reach out and get the right people's eyes on a > >>> document -- and, even to know what eyes are good to get on it. > >>> > >>> This might, actually, therefore be also a good way of the IETF to = be > >>> more welcoming and inclusive to new folks wanting to get involved. > >>> > >>> Thought #2: > >>> So back to Adrian's 10-page DISCUSS/COMMENT....a, perhaps, lighter > >>> version of thought #1 is to have a more structure directorate = review > >>> cycle during IETF LC, or perhaps during "Publication Requested" = and > >>> before "AD Evaluation". I am thinking that these be of the form: = an > >>> I-D hits the AD, the responsible/sponsoring AD requests = directorate > >>> reviews from all the concerned directorates (GEN, SEC, OPS, RTG, > >>> TSP, ...). Authors and reviewer iterate until either (i) issues = are > >>> squared off or (ii) either authors or reviewer declare the other = as > >>> "bat-crap-crazy" (or, complains that the other side is not > >>> responsive) and raise the issue to the AD. AD moves the document > >>> forward to "AD Evaluation" only once happy with the outcome of > directorate reviews. > >>> In short, hiving out a lot more of the "problem fixing" that = happens > >>> during these reviews off to the directorates - and leaving ADs to > >>> process > >> presumably "less broken" documents. > >>> > >>> As an author, I have actually found it a LOT easier/faster to > >>> iterate with a directorate reviewer (who has my document fresh in > >>> mind), than with an AD who's preoccupied with a dozen or so > >>> documents at the same time, and other emergencies. Now, mind you, > >>> some ADs are good at saying "Busy, will come back to you in n = days" > >>> -- others, alas, do "play dead" if they feel they have more > >>> important fish to fry, and that's > >> frustrating. > >>> > >>> This might lessen the load on the ADs, but still has the > >>> disadvantage that one gets feedback *very* late in the > >>> process....just a little bit earlier than during IESG processing. > >>> > >>> Thought #3: > >>> I thought it's worth calling out, that either of the above are not > >>> really related to RTG documents: I should think that RTG WG Chairs > >>> are plenty able to do the necessary during WG processing, and as = an > >>> author in the RTG Area, I do usually know how to grab someone > >>> competent from the same area for advice, as needed. While doing > >>> something like this intra-area can be a good thing, the real boast > >>> that I, as document author, have felt has been through getting > >>> cross-area feedback. Just as (being forced to be) reviewing = document > >>> outside of the RTG area has > >> been hugely educational and. > >>> > >>> Cheers, > >>> > >>> Thomas > >>> > >>> > >>> > >>> On 21 Mar 2014, at 19:31, Adrian Farrel = wrote: > >>> > >>>> Hello Directorate and WG chairs, > >>>> > >>>> Alia and I have been discussing the Routing Area, its work, its > >>>> output, and its working groups. > >>>> > >>>> We have reached a conclusion (which perhaps we should have come = to > >>>> sooner) that we need your help and input. > >>>> > >>>> The crunch question for us is "What makes it hard to get work = done > >>>> in the Routing Area?" What gets in the way of your work? What is > >>>> making life hard for document authors? How could working groups = be > >>>> doing better? We are open to all and every type of answer. We are > >>>> happy to have quick, one-line answers or deeply-considered = essays. > >>>> > >>>> What do you think? > >>>> > >>>> Thanks for all your input, > >>>> Adrian and Alia > >>>> > >>>> PS Please respond to both aliases because not everyone is on both = lists. > >>>> Sorry > >>>> that that means some of you will get duplicates. > >>>> > >>> > >>> > >>> > >>> > >>> > >>> > > >=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 From nobody Fri Mar 28 11:30:51 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454241A093A for ; Fri, 28 Mar 2014 11:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 vsVD9wEOIpVM for ; Fri, 28 Mar 2014 11:30:48 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id EC16A1A0964 for ; Fri, 28 Mar 2014 11:30:47 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93]:50044 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WTbYA-0005ZA-Ct; Fri, 28 Mar 2014 18:30:42 +0000 From: "Russ White" To: "'Geoff Huston'" , References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> <69010e3b5af445a09b31e9cbee0e94ef@BLUPR05MB562.namprd05.prod.outlook.com> <532D62BE.3040102@pi.nu> <016a22f47ada48549c3d46b693f08ec4@BLUPR05MB562.namprd05.prod.outlook.com> <047201cf45d6$465e3250$d31a96f0$@riw.us> <9B091063-01ED-4DA0-AED3-712B9EBEF770@apnic.net> In-Reply-To: <9B091063-01ED-4DA0-AED3-712B9EBEF770@apnic.net> Date: Fri, 28 Mar 2014 14:30:37 -0400 Message-ID: <042401cf4ab3$d14d28d0$73e77a70$@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: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wGfr6KFARRJlhYCZgSzJQIiDeNyAP+bCsCZHsfh0A== 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/rtg-dir/85i9Zzr49x5UiVp1K2BH3fSDqw0 Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:30:49 -0000 > There are, as far as I can see, outstanding with validation, local repository > cache management, signalling, as well as path protection that tend to suggest > "unsafe to deploy" to me. Path protection is specifically an area that I think needs to be returned to research for various reasons. :-) Russ From nobody Fri Mar 28 11:49:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A791A033D; Fri, 28 Mar 2014 11:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 Oi7fMwYQJzU4; Fri, 28 Mar 2014 11:48:58 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id D3BF11A01DB; Fri, 28 Mar 2014 11:48:58 -0700 (PDT) Received: from cpe-174-106-045-093.ec.res.rr.com ([174.106.45.93]:64486 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WTbpn-00064y-M1; Fri, 28 Mar 2014 18:48:55 +0000 From: "Russ White" To: "'Alia Atlas'" , "'Thomas Clausen'" References: <090901cf4533$bc895840$359c08c0$@olddog.co.uk> In-Reply-To: Date: Fri, 28 Mar 2014 14:48:50 -0400 Message-ID: <04a201cf4ab6$5cf1af80$16d50e80$@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: AQKaYQ1J8gXd4GH3IB1tPGKwBZHb1wF5D2kGAgX2wc+ZRLJBoA== 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/rtg-dir/MPd0_z3pxQiymDjawIun1hFAtL8 Cc: 'Adrian Farrel' , 'Alia Atlas' , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:49:00 -0000 > Thanks very much for your thoughts. On the being underutilized and on > cross-area review, what do you and others in the Routing Directorate think > about being asked to follow a single additional working group that is not in > RTG and may have routing related issues? I actually like this idea, so long as we don't (as Joel pointed out) simply assign every review from that WG to the one "watcher." :-) Russ From nobody Fri Mar 28 11:57:03 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FE51A01DB; Fri, 28 Mar 2014 11:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 GEXK8LhoTWHw; Fri, 28 Mar 2014 11:56:58 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7EA1A094E; Fri, 28 Mar 2014 11:56:58 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so3999099ykp.15 for ; Fri, 28 Mar 2014 11:56:56 -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=sQl0KSj0MnDtY1xXciEbDb3qOWzJSYcTtEL8A9FvhSA=; b=bsB+ZfTtaTPPEN07Z/RbaDGtDJuN1Zejyb/cDKZfM+UXr+Miiaa8KDPGsRX3LUqMZU O/2gAV8Nw8T3dIfGzLnsir/DFaKIY6ZhEI62Il/86wgXDc1j3ensUh1BJIshDhHfQV7o 9KEqYWLvU5oY5oGRtPlgyHO1nC4TP3SR0oV9p0CV/9V7IXUArLug8Y38gR70WVo9G68S 4J6VM3rw9qAE+GNyM6dUl1/eEOiYF48n4ccLteGo1BTbCzOKpcgVWV4bY7+aSsI2fvrZ x/GVHgWzg7q5tGS7naS1Y9+t/evTy2//L6HI9PHG7RekzNQQGqwGxj+8RmIeYsyGoLQ1 QSNw== MIME-Version: 1.0 X-Received: by 10.236.110.131 with SMTP id u3mr6934246yhg.99.1396033016142; Fri, 28 Mar 2014 11:56:56 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Fri, 28 Mar 2014 11:56:55 -0700 (PDT) In-Reply-To: <00af01cf482f$79cc5210$6d64f630$@ndzh.com> References: <00af01cf482f$79cc5210$6d64f630$@ndzh.com> Date: Fri, 28 Mar 2014 14:56:55 -0400 Message-ID: From: Alia Atlas To: Susan Hares Content-Type: multipart/alternative; boundary=001a1133236c05a06704f5af4497 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/S5SxhEwKiSJBsik9EQFlx3InUcI Cc: "rtg-dir@ietf.org" , Adrian Farrel , Alia Atlas , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Routing Area Health Check X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 18:57:03 -0000 --001a1133236c05a06704f5af4497 Content-Type: text/plain; charset=ISO-8859-1 Hi Sue, On Tue, Mar 25, 2014 at 9:38 AM, Susan Hares wrote: > [Soap box on] > > What's not necessary to consider in this discussion is: > > 1) Maximum number of working groups - > [Alia] Yes - while it is harder to schedule each IETF meeting, that is not a reason for an artificial limit on the number of working groups in routing. It is a reason for WG chairs to think deeply about how much time they really need and to have planned and purposeful agendas. > 2) Instant cutting of number of working groups > [Alia] Yes - working groups completing their charter and ending is a good thing and a natural part of the WG life-cycle. That there are working groups on that trajectory is not a surprise. > 3) Bullying or badgering toward cutting working groups > [Alia] Absolutely on bullying. It is useful to have an impetus towards saying that we could be doing things better and part of that may be consolidating working groups or admitting that some are done or should be soon. > Three issues exist in the routing area: > > > > 1) Getting new work in - from new applications of routing protocols > in Data centers, > [Alia] We've had a rash of new work in the last couple years - which is great - and may not be done. > 2) Getting work completed - > > a. Getting the last drafts out and then, declaring victory and > closing, > [Alia] For protocol groups, we have tended to keep them individually alive as maintenance > b. Determining the last drafts are not worth-while, so stopping at a > good point. > [Alia] Yes - I do wonder for some of the not-enough-review complaints whether that is because drafts are addressing more corner cases where there isn't active implementation or serious wide interest. > c. Determine things are at maintenance point and scheduling based > on this point. > [Alia] I think this has been hard to do. Part of it is determining when there is enough maintenance work to keep a WG and when there could be benefits from merging some. > 3) Listening to each other (which prevents 1 & 2 effectively > occurring) > [Alia] What do you think might help here? I don't think that it is just a socialization/respect problem. > ------------------- > > 1) The most important of these facets is the ability to rapidly > adopt and get new work in. This means we must actively go out and listen > for new work. Data Center people have a lot of traffic and a new ideas. > ETSI/NFV have a new needs. It is good news that people attending heavily > SFC, Spring, and I2RS. > > This is where most of our discussion should be focused - because this is > what keeps us vibrant as a standard group. > [Alia] Yes on listening to new work - and I would encourage you all to think about what new ideas may be worth bringing to the IETF. We need to actively engage in new work as well as figure out how to make that work go quickly, which means not merely excitement but active intent to implement quickly. [Alia] To act well on new work, we have to understand that there are limited cycles and that sometimes means finishing up and putting down old work. > 2) Getting work completed. > > Here is the tough part we are really talking about. With SIDR, KARP, and > the rest - the real question is have we finished our first grouping? What > does it take to complete it? > [Alia] Yes, there are a few groups in this state. It's not clear to me that SIDR is one of them, but I'm happy to listen and learn. > One middle ground to closing is "hiatus". Yakov put IDR into hiatus for > several sessions. This was a good forcing function for the new uses. > Putting your WG into hiatus may signal people that if they do not have > drafts ready and active on the mail list - you will simply not meet or get > the 1/2 hour time slot. Hiatus is a step before closing. AD's can handle a > lot of groups in Hiatus, if we "de-emotionalize" this state. > [Alia] Yes, and BFD functions frequently in that mode. It's hard to get there if there are a lot of corner-case drafts in the WG. > Some groups are in maintenance or a change. IDR is both in maintenance > (fixing those pesty error conditions), and new growth. The difficulty with > MPLS, L2VPN, L3VPN, PWE - is we are not sure if it is maintenance (for > large deployments) or new growth. If we have a hiatus state, perhaps we > can talk about the problems as chairs and a directorate. > [Alia] One idea is to merge WGs that have similar/related technologies when there seems to be duplication of the maintenance work. > 3) Listening to one another - We have OMC (Old Married Couple) > syndrome > > > > We in the routing group have been at this for almost 30 years. We have > OMC syndrome. > > We have ceased to listen because we KNOW what the other person will say, > and fight rather than think about new ideas. Are Alia and Adrian like OMC > marriage counselors? Yes - but is about time we started listening because > the best time for working on routing - are ahead of us. > [Alia] I think you are arguing for Adrian and I to force people to sit down in the same room and talk to each other as well as encouraging it on the mailing list. We are, as you read now, doing the latter. We are also (still tentatively) talking about possibly doing the former at the next IETF - probably in a dinner time slot so there's enough time to get work done during it as well. > The virtualization of the edge and the data center has endless > possibilities, and we have the wisdom to figure it out. We are the best > people to help the next generation of technology come to full bloom. > > [Alia] Absolutely! We've got to figure out the right types of abstractions and how to make this work practically. > [Soap box off] > [Alia] Guess I should climb down too :-) Regards, Alia --001a1133236c05a06704f5af4497 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sue,

On Tue, Mar 25, 2014 at 9:38 AM, Susan Hares <shares@= ndzh.com> wrote:

[So= ap box on]

What’s not necessary to consider in this discu= ssion is: 

1)    =   Maximum number of working groups -

[Alia] Yes - while it is harder to schedule each IE= TF meeting, that is not a reason for an artificial limit on the number of w= orking groups in routing.  It is a reason for WG chairs to think deepl= y about how much time they really need and to have planned and purposeful a= gendas.

2)      Instant cutting of number of working groups

[Alia] Yes - working groups completing their = charter and ending is a good thing and a natural part of the WG life-cycle.=  That there are working groups on that trajectory is not a surprise.<= /div>
 

3)    &nb= sp; Bullying or badgering toward cutting working group= s 

[Alia] Absolutely on bullying.  It is us= eful to have an impetus towards saying that we could be doing things better= and part of that may be consolidating working groups or admitting that som= e are done or should be soon. 

Three issues exist in th= e routing area:

 

1)     = Getting new work in – from new applications of = routing protocols in Data centers,

[Alia] We've had a rash of new work in the last= couple years - which is great - and may not be done.   

2)&nbs= p;     Getting work completed &nda= sh;

a. = ;      Getting the last draft= s out and then,  declaring victory and closing,

=
[Alia] For protocol groups, we have tended to keep them individually a= live as maintenance 

b. = ;     Determining the last drafts = are not worth-while, so stopping at a good point.

[Alia] Yes - I do wonder for some of the not-enough-review complaints whe= ther that is because drafts are addressing more corner cases where there is= n't active implementation or serious wide interest. 

c. = ;      Determine things are a= t  maintenance point and scheduling based on this point.

[Alia] I think this has been hard to do.  Part of it is = determining when there is enough maintenance work to keep a WG and when the= re could be benefits from merging some.
 

<= p>3)&nb= sp;     Listening to each other &n= bsp;(which prevents 1 & 2 effectively occurring)

[Alia] What do you think might help here?  I d= on't think that it is just a socialization/respect problem.  
 

 -------------------

1)      The most = important of these facets is the ability to rapidly adopt and get new work = in. This means we must actively go out and listen for new work.  Data = Center people have a lot of traffic and a new ideas.  ETSI/NFV have a = new needs.  It is good news that people attending heavily SFC, Spring,= and I2RS. 

This is where most of our discussion should be focused – because t= his is what keeps us vibrant as a standard group.

[Alia] Yes on listening to new work - and I would encourage you all to th= ink about what new ideas may be worth bringing to the IETF.   We need = to actively engage in new work as well as figure out how to make that work = go quickly, which means not merely excitement but active intent to implemen= t quickly. 

[Alia] To act well on new work, we have to understand t= hat there are limited cycles and that sometimes means finishing up and putt= ing down old work.

 2)      G= etting work completed. 

 Here is the tough part we are really talking about.  W= ith SIDR, KARP, and the rest – the real question is have we finished = our first grouping?  What does it take to complete it?  

[Alia] Yes, there are a few groups in this state.  = It's not clear to me that SIDR is one of them, but I'm happy to lis= ten and learn. 

 One middle ground to closing is &ldquo= ;hiatus”.  Yakov put IDR into hiatus for several sessions. This = was a good forcing function for the new uses.  Putting your WG into hi= atus may signal people that if they do not have drafts ready and active on = the mail list – you will simply not meet or get the ½ hour tim= e slot.  Hiatus is a step before closing.  AD’s can handle = a lot of groups in Hiatus, if we “de-emotionalize” this state. =  

[Alia] Yes, and BFD functions frequently in that mo= de.  It's hard to get there if there are a lot of corner-case draf= ts in the WG. 

Some gr= oups are in maintenance or a change.  IDR is both in maintenance (fixi= ng those pesty error conditions), and new growth.  The difficulty with= MPLS, L2VPN, L3VPN, PWE – is we are not sure if it is maintenance (f= or large deployments) or new growth.  If we have a hiatus state, perha= ps we can talk about the problems as chairs and a directorate.  

[Alia] One idea is to merge WGs that have similar/r= elated technologies when there seems to be duplication of the maintenance w= ork.
 

 3)      Li= stening to one another  - We have OMC (Old Married Couple) syndrome

 

We in the routing group have been at th= is for almost 30 years.  We have OMC syndrome.

We have ceased to listen because we KNOW what the other person will say, an= d fight rather than think about new ideas.  Are Alia and Adrian like O= MC marriage counselors?  Yes – but is about time we started list= ening because the best time for working on routing – are ahead of us.=  


[Alia] I think you are arguing for A= drian and I to force people to sit down in the same room and talk to each o= ther as well as encouraging it on the mailing list.  We are, as you re= ad now, doing the latter.  We are also (still tentatively) talking abo= ut possibly doing the former at the next IETF - probably in a dinner time s= lot so there's enough time to get work done during it as well.
 

=

The virtualization of the= edge and the data center has endless possibilities, and we have the wisdom= to figure it out.  We are the best people to help the next generation= of technology come to full bloom.


[A= lia] Absolutely!  We've got to figure out the right types of abstr= actions and how to make this work practically.   

<= /div>
 

[Soap box off]  

<= div>
[Alia] Guess I should climb down too :-)

Rega= rds,
Alia

--001a1133236c05a06704f5af4497-- From nobody Sun Mar 30 19:22:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78D1A0412; Sun, 30 Mar 2014 19:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 eHi9CjmOCYZE; Sun, 30 Mar 2014 19:22:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA231A0924; Sun, 30 Mar 2014 19:22:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCO66684; Mon, 31 Mar 2014 02:22:35 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 03:21:47 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 03:22:33 +0100 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.94]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Mon, 31 Mar 2014 10:22:30 +0800 From: Mach Chen To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: Ac9MiA8kPZwsDe8nRuKlfe9UUOMhxA== Date: Mon, 31 Mar 2014 02:22:29 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.72] 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/rtg-dir/4jtwvPahBY1voLT4EuJx3_B1oa4 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 02:22:44 -0000 Hello,=20 I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html=20 Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft.=20 Document: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt=20 Reviewer: Mach Chen=20 Review Date: March 29, 2014 IETF LC End Date:=20 Intended Status: Standards Track=20 Summary:=20 I have some minor concerns about this document that I think should be resol= ved before publication. Comments:=20 The draft is well written and easy to read. The solution is technical worka= ble, but for some corner cases, more considerations are needed. Major Issues:=20 None. =20 Minor Issues:=20 1. Since the TTL TLV is defined for both MS-PW and bidirectional co-routed = LSP, it should be better to explicitly state this in the abstract section. 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo request", "echo = request" and "request" are interchangeably used in the draft, it's better t= o unify the usage of it to "MPLS echo request" (to align with the usage in = RFC4379). For "echo reply", "bidirectional co-routed LSP", they have the si= milar issue. 3.Section 3.1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | Reserved | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the TTL TLV, the value filed should include the "value", "Reserved" and= "Flags", so it's better to change the "Value" field to "TTL" field hence t= o reduce the confusion.=20 4. Section 3.2 "This TLV shall be included in the echo request by the originator of request. The use of this TLV is optional. If a receiver does not understand the TTL TLV, it will simply ignore the TLV (Type value of TLV is assumed to be in the range of optional TLV's which SHOULD be ignored if an implementation does not support or understand them). In the absence of TTL TLV or if TTL TLV is ignored by a receiver, the determination of the TTL value used in the MPLS label on the echo reply is beyond the scope of this document." What's your mean of "beyond the scope of this document" here? Is it to appl= y the procedures defined in RFC4379 or just let it to the implementation? I= guess you assume to apply the definition in RFC4379, if so, the TTL of the= MPLS label will be more probably set to 255, means the echo reply will be = sent to the ingress of the MS-PW or LSP. I am not sure whether this is the = right procedure, it seems a security issue. IMHO, it does not make any sens= e to expect the receiver to send echo reply in this situation, and even sen= t, the initiator will not receive the reply. The safer way is to drop the w= hole echo request and record an error log. 5. Section 3.2 "In other words, if the value of the TTL provided by this TLV does not matc= h the TTL determined by other means, such as Switching Point TLV in MS-PW, then TTL TLV must be used." Here, it implies that the receiver has to perform TTL matching process, sin= ce how to set the TTL is independent of such matching, seems this sentence = is redundant and confusion. =20 6. Section 4. "...The value field of the TTL TLV and the TTL field of the MPLS label are = set to 2," I guess that the MPLS Label is the PW label, right? It's better to add more= text to make this more explicit. In addition, how to set the TTL value of = the tunnel Label? 255 or any other value? 5. Section 4.1. Traceroute mode "In the traceroute mode TTL value in the TLV is successively set to 1, 2, and so on. This is similar to the TTL values used for the label set on the packet." IMHO, some text may be needed to clarify which "FEC" should be carried, esp= ecially for MS-PW trace. Since in Section 4.0, the example says the FEC of = segment C-D should be carried, does it mean the FEC of last PW Segment of t= he segment under test should be carried or the FEC will vary when TTL chang= ed. For example, when perform segment trace (e.g., to trace B-D segment), w= hen TTL is 1, which FEC should be carried? 6. Section 4.2. Error scenario For this scenario, do you need to define some error codes here?=20 7. For MS-PW trace, seems that you assume the tunnel is pipe mode, if so, i= t should be explicitly stated. If not, you should define how the MS-PW trac= e works (given that the tunnels in both directions may span different hops)= .=20 Nits:=20 1. Please check the text for acronyms that have not been expanded in their = first use. 2. I run the idnits tool and found the following nits, please check and fix= .=20 (See RFCs 3967 and 4897 for information about using normative reference= s to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC2119' on line 121 -- Looks like a reference, but probably isn't: 'RFC4379' on line 258 =3D=3D Unused Reference: '1' is defined on line 284, but no explicit refe= rence was found in the text =3D=3D Unused Reference: '2' is defined on line 287, but no explicit refe= rence was found in the text =3D=3D Unused Reference: '3' is defined on line 291, but no explicit refe= rence was found in the text 3. Section 3.2, 3.1 first para first sentence s/shall/SHALL 3.2 last para, the last second sentence s/must/MUST 4. The draft quotes the MS-PW and bidirectional co-routed LSP concept, it's= better to add related references to this document. Best regards, Mach From nobody Mon Mar 31 05:12:31 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F2A1A07B8; Mon, 31 Mar 2014 05:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.083 X-Spam-Level: X-Spam-Status: No, score=-97.083 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 bgO9gT1ZrJiQ; Mon, 31 Mar 2014 05:12:27 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id E1CD01A07B0; Mon, 31 Mar 2014 05:12:26 -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 s2VCCMgg024576; Mon, 31 Mar 2014 13:12:22 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VCCIot024519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 13:12:21 +0100 From: "Adrian Farrel" To: , Date: Mon, 31 Mar 2014 13:12:19 +0100 Message-ID: <00cc01cf4cda$78f298e0$6ad7caa0$@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: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1Q== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20600.007 X-TM-AS-Result: No--11.611-10.0-31-10 X-imss-scan-details: No--11.611-10.0-31-10 X-TMASE-MatchedRID: z4uLnt0oIRb91PNXKgBDmXBRIrj8R47FDRi0jfY6gL1F+YXPIqAdviM7 ldcX6wW8edSp+M2T6JvVh3YqHycTRW9PyFCtLnnLRsqQuQlRTh/01irNvag5a+VLofsFQv6xMwR yrAxy6J/92Y3c0yZ6+h7tAcM+YxG8v6BXK4P/i1ZNCH0Dib0S0bQ0n3DEfu2TgSvcAq2G7Vt2eL SH9FRxBJB9htPKoAS7jD+YaeCTSJ1zgDEqoQageijQ4osdfamB/4+GQcsmc+KInvV8Dy0ZaNOTf 2cXwO/OSjIjJrIbmJ0EhdPrp/TFym4l9oKv28YokE7MrqaPYs2l9VzHf0qr7gmZ1fM6EQx2s/91 xjA/KoEWc2o14KVrNLnmLMOQLbZHR+3dVuJy7PLhuXUWQoMQtzpVtQQHm78w0VVCHBcKxaur/fg klKxHtjbxighHosarkacsm9f9+oBcsv0/qKQxRcK7fT3t6J55wx0jRRxcQfOsIMnczyxe57L1DH cHWIt2jYq5iW7uqkObu+FyWYBKSk1+zyfzlN7y/sToY2qzpx7dB/CxWTRRu25FeHtsUoHulRBaQ dKmuPAWk+4TXzpO3b+1aXr3+ZCPAElcnu26My5oBmTSwRxjXg== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/rRNoV0bwrMRX5Db3pKrD8puyM-c Subject: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:12:29 -0000 Hi, One of the ideas to come out of the recent discussions is appointing a mentor per document from the time it is adopted by a Routing Area working group until it completes WG last call. This would be voluntary in two dimensions: - the WG chairs would need to deem that one would be beneficial - we would have to find someone from the Directorate willing to take on the document. We don't think that technology expertise is as useful in this as IETF clue and general routing experience. So, to take this forward we would need: - WG chairs to say "Yes, we can see that that would have potential benefit - Directorate members to say "Yes, we could take on that additional work. Alia and I have put together some preliminary notes on how this would all hang together. Your opinions and rotten fruit are solicited. Thanks, Adrian and Alia ========= Document Mentors in the Routing Area The Problems: a) Drafts get little review outside the working group and sometimes inside the working group until after working group last call. At that point it is often painful and costly to make meaningful improvements to the drafts. b) Authors may not know how or whom to ask for assistance or review (e.g., IANA section, Security Section, Operational and Management considerations, details of a protocol, etc. ). The Goals: a) Excellent and consistent review at WG adoption and before WG last call. b) Ability for prolonged discussion and problem-solving when the draft can still be easily enhanced. c) Reduced time to delivery of RFCs. d) Quality documents. The Solution: A per-document mentor who is a known neutral party to whom the authors can go for advice on: - how to write a section - specific issues that arise - ways to resolve conflicts. The document mentor also watches the progress of the document and gives advice and steerage. It is not assumed that every document will need or benefit from having a mentor. The Expected Workload: The routing directorate has approximately 40 people. If we assume that approximately 50 drafts pass WG adoption and a similar number pass WGLC each year, then the load is 2.5 documents per person per year. If we assume that there are about 200 WG drafts in the Routing Area and that they all have mentors, then each Routing Directorate member will have 5 drafts that she or he is mentoring. The Supporting Data Artefacts: a) As part of the Routing Area wiki, the areas of knowledge for each member of the Routing Directorate will be publicly specified. This is added to the wiki by the Routing Area Coordinators (or AD) when the member joins the Routing Directorate, updated by the member while he or she is on the Directorate, and updated by the Routing Area Coordinators (or AD) if and when the member's term renews. b) Document Mentor Availability and Assignments: As part of the Routing Area wiki, each Directorate member will specify the maximum number of documents that he or she is able to mentor. Also listed will be the list of mentored documents (and a count). i) When a Directorate member is assigned as the Document mentor, the Routing Directorate Coordinator will update the wiki page and create a wiki page for the draft. ii) When a Document Mentor provides a review, that should be stored in the draft's wiki page along with the resolutions. iii) When the Document Mentor's final review at WGLC is done, the Document Mentor should move the draft to a list of "previously mentored documents" associated with their name. It is ideal to write up a summary of the document mentoring experience. c) Unmentored Documents: Drafts which have declined a document mentor should be listed on a wiki page. d) For each WG's wiki, it'd be useful to have the list of drafts with their associated Document Mentors (or lack thereof) and the link to the draft's wiki page. The Basic Process: When a new WG draft is adopted, the WG chairs and the Routing Directorate Coordinators discuss and agree on possible Document Mentors (up to 3). Then the Routing Directorate Coordinator confirms with the Routing Directorate members about their availability and willingness to mentor this particular draft. Once one is selected, the Routing Directorate Coordinator updates the wiki and notifies the WG chairs and draft authors. a) With the agreement of the ADs, a Document Mentor who is not a member of the Routing Directorate may be selected. b) The WG chairs can, after consulting with the draft authors, decline to have a Document Mentor. c) The Document Mentor should coordinate with the Document Shepherd for hand-off after WGLC. From nobody Mon Mar 31 05:48:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C531A084E; Mon, 31 Mar 2014 05:48:29 -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 C3DqIrBcMkdJ; Mon, 31 Mar 2014 05:48:27 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6C01A0851; Mon, 31 Mar 2014 05:48:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id A829A241244; Mon, 31 Mar 2014 05:48:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D8A0F2412A5; Mon, 31 Mar 2014 05:48:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> Date: Mon, 31 Mar 2014 14:48:18 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78EB7945-E25C-4E0F-BDA7-3198305446B3@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/zE49T7Wvzk537IPIJAaQQ9FuWBY Cc: "" , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:48:29 -0000 All, Apologies, I used up all my expired produce in London about a week back, = I have yet to stock up... Sounds pretty reasonable to me - allowing as much, or as little, = interference in document process as is necessary, and not stepping on = the toes of current process steps.=20 I would suspect, though, that the workload would be very heterogenous = among documents, with some being "close to nothing" whereas others being = "almost as much as the authors", and that "number of I-Ds mentored" is = not a perfectly accurate way of distributing the workload. Assuming = that there's a sentient being (AD or RDC) somewhere in the process, = that's probably not a problem. =20 There probably are edges to file off, but I say let's get to run the = experiment and see what comes from it.=20 I see that Adrian suggested two acceptable positive responses, depending = on to which list one is subscribed, so count this as my: "Yes, we [I] could take on that additional work" Cheers, Thomas On 31 Mar 2014, at 14:12, Adrian Farrel wrote: > Hi, >=20 > One of the ideas to come out of the recent discussions is appointing a = mentor > per document from the time it is adopted by a Routing Area working = group until > it completes WG last call. >=20 > This would be voluntary in two dimensions: > - the WG chairs would need to deem that one would be beneficial > - we would have to find someone from the Directorate willing to > take on the document. >=20 > We don't think that technology expertise is as useful in this as IETF = clue and > general routing experience. >=20 > So, to take this forward we would need: > - WG chairs to say "Yes, we can see that that would have > potential benefit > - Directorate members to say "Yes, we could take on that > additional work. >=20 > Alia and I have put together some preliminary notes on how this would = all hang > together. >=20 > Your opinions and rotten fruit are solicited. >=20 > Thanks, > Adrian and Alia >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Document Mentors in the Routing Area >=20 > The Problems:=20 >=20 > a) Drafts get little review outside the working group and sometimes = inside=20 > the working group until after working group last call. At that point = it is > often > painful and costly to make meaningful improvements to the drafts. >=20 > b) Authors may not know how or whom to ask for assistance or review=20= > (e.g., IANA section, Security Section, Operational and Management > considerations, details of a protocol, etc. ). >=20 > The Goals: >=20 > a) Excellent and consistent review at WG adoption and before WG last > call. =20 >=20 > b) Ability for prolonged discussion and problem-solving when the > draft can still be easily enhanced. >=20 > c) Reduced time to delivery of RFCs. >=20 > d) Quality documents. >=20 > The Solution: >=20 > A per-document mentor who is a known neutral party to whom the > authors can go for advice on: > - how to write a section > - specific issues that arise > - ways to resolve conflicts. >=20 > The document mentor also watches the progress of the document > and gives advice and steerage. >=20 > It is not assumed that every document will need or benefit from=20 > having a mentor. >=20 > The Expected Workload: >=20 > The routing directorate has approximately 40 people. If we assume > that approximately 50 drafts pass WG adoption and a similar number > pass WGLC each year, then the load is 2.5 documents per person > per year. If we assume that there are about 200 WG drafts in the > Routing Area and that they all have mentors, then each Routing > Directorate member will have 5 drafts that she or he is mentoring. >=20 > The Supporting Data Artefacts: >=20 > a) As part of the Routing Area wiki, the areas of knowledge for > each member of the Routing Directorate will be publicly specified. > This is added to the wiki by the Routing Area Coordinators (or AD) > when the member joins the Routing Directorate, updated by the > member while he or she is on the Directorate, and updated by the > Routing Area Coordinators (or AD) if and when the member's term > renews. >=20 > b) Document Mentor Availability and Assignments: As part of the > Routing Area wiki, each Directorate member will specify the maximum > number of documents that he or she is able to mentor. Also listed > will be the list of mentored documents (and a count). >=20 > i) When a Directorate member is assigned as the Document > mentor, the Routing Directorate Coordinator will update the > wiki page and create a wiki page for the draft. >=20 > ii) When a Document Mentor provides a review, that should be > stored in the draft's wiki page along with the resolutions. >=20 > iii) When the Document Mentor's final review at WGLC is done, > the Document Mentor should move the draft to a list of > "previously mentored documents" associated with their name. > It is ideal to write up a summary of the document mentoring = experience. >=20 > c) Unmentored Documents: Drafts which have declined a document > mentor should be listed on a wiki page. >=20 > d) For each WG's wiki, it'd be useful to have the list of drafts > with their associated Document Mentors (or lack thereof) and the > link to the draft's wiki page. >=20 > The Basic Process: >=20 > When a new WG draft is adopted, the WG chairs and the Routing > Directorate Coordinators discuss and agree on possible Document > Mentors (up to 3). Then the Routing Directorate Coordinator > confirms with the Routing Directorate members about their > availability and willingness to mentor this particular draft. Once > one is selected, the Routing Directorate Coordinator updates the > wiki and notifies the WG chairs and draft authors. >=20 > a) With the agreement of the ADs, a Document Mentor who is not a > member of the Routing Directorate may be selected. >=20 > b) The WG chairs can, after consulting with the draft authors, > decline to have a Document Mentor. =20 >=20 > c) The Document Mentor should coordinate with the Document > Shepherd for hand-off after WGLC. >=20 >=20 >=20 >=20 From nobody Mon Mar 31 05:49:24 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A761A084B for ; Mon, 31 Mar 2014 05:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] 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 pnOFfSloLqZU for ; Mon, 31 Mar 2014 05:49:20 -0700 (PDT) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) by ietfa.amsl.com (Postfix) with ESMTP id E34221A084E for ; Mon, 31 Mar 2014 05:49:18 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id x10so7934665pdj.20 for ; Mon, 31 Mar 2014 05:49:15 -0700 (PDT) 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=Zy4sTWDfoS4KNkDp/OfPJy95x1ZYbqwlnc65K3Z+qGE=; b=mCSH1Pj+8QN05C2X8QBAz1cp1/AfMt97MvgSYKYcJNsOdLYFP+efgLxxhnVXVcQFPe 35N36NGTL/+bTancYB7f0CX3Fcb7iPQ92xto1qaLL2wWiwug+64ava2riwUQcte167NV /wTAD4vGGREt58KF2Rc925W8p+rxcK9dulAOYfyhXmqQ2o6r6VvwVjpaCjf8g1olBS+E h8N14pLiKGH1OjjeZuS/PS3VjVi0+JH4T69Z6Z+FGtMkaIYGB/iZQ/r8ySQrMw/XAVNT yLegVZUmFv4BYJ1MnjJKf1A9RXg7wRfbCE6Aai3HtA3Hsra44qOySPXCWwvee9F7hQT9 7c1g== X-Gm-Message-State: ALoCoQkQfRCmaUi8MqN44LjS8gBZleX42dt7OSfJQU6hqF1nD1Qv8iyB+mOa1mctl61wy4OM/vVJ X-Received: by 10.68.133.229 with SMTP id pf5mr8171888pbb.115.1396270155776; Mon, 31 Mar 2014 05:49:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.11.234 with HTTP; Mon, 31 Mar 2014 05:48:55 -0700 (PDT) In-Reply-To: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> From: Jamal Hadi Salim Date: Mon, 31 Mar 2014 08:48:55 -0400 Message-ID: To: Adrian Farrel Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/UgmYN_jeVNxSmt8HClXTuaDUuME Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 12:49:22 -0000 The only hole i see is your scale/workload numbers dont take into consideration the fact that there could be a lot more spread than 200 active documents per year that are in between WG adoption to publication. And that at times that process takes a little longer. Jari's tools could provide some stats (and i could be therefore off), but to make my point i will handwave and say it is a magnitude more docs, some of which a mentor is responsible for and some which are making progress. This means each of the 40 people is actively mentoring about 25 documents per year. And lets say 60 over 3 years. You will need a large number of people in the directorate to scale. And then there's handoff challenges. If i am mentoring a doc that is not complete before i let go ... cheers, jamal On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel wrote: > Hi, > > One of the ideas to come out of the recent discussions is appointing a mentor > per document from the time it is adopted by a Routing Area working group until > it completes WG last call. > > This would be voluntary in two dimensions: > - the WG chairs would need to deem that one would be beneficial > - we would have to find someone from the Directorate willing to > take on the document. > > We don't think that technology expertise is as useful in this as IETF clue and > general routing experience. > > So, to take this forward we would need: > - WG chairs to say "Yes, we can see that that would have > potential benefit > - Directorate members to say "Yes, we could take on that > additional work. > > Alia and I have put together some preliminary notes on how this would all hang > together. > > Your opinions and rotten fruit are solicited. > > Thanks, > Adrian and Alia > > ========= > > Document Mentors in the Routing Area > > The Problems: > > a) Drafts get little review outside the working group and sometimes inside > the working group until after working group last call. At that point it is > often > painful and costly to make meaningful improvements to the drafts. > > b) Authors may not know how or whom to ask for assistance or review > (e.g., IANA section, Security Section, Operational and Management > considerations, details of a protocol, etc. ). > > The Goals: > > a) Excellent and consistent review at WG adoption and before WG last > call. > > b) Ability for prolonged discussion and problem-solving when the > draft can still be easily enhanced. > > c) Reduced time to delivery of RFCs. > > d) Quality documents. > > The Solution: > > A per-document mentor who is a known neutral party to whom the > authors can go for advice on: > - how to write a section > - specific issues that arise > - ways to resolve conflicts. > > The document mentor also watches the progress of the document > and gives advice and steerage. > > It is not assumed that every document will need or benefit from > having a mentor. > > The Expected Workload: > > The routing directorate has approximately 40 people. If we assume > that approximately 50 drafts pass WG adoption and a similar number > pass WGLC each year, then the load is 2.5 documents per person > per year. If we assume that there are about 200 WG drafts in the > Routing Area and that they all have mentors, then each Routing > Directorate member will have 5 drafts that she or he is mentoring. > > The Supporting Data Artefacts: > > a) As part of the Routing Area wiki, the areas of knowledge for > each member of the Routing Directorate will be publicly specified. > This is added to the wiki by the Routing Area Coordinators (or AD) > when the member joins the Routing Directorate, updated by the > member while he or she is on the Directorate, and updated by the > Routing Area Coordinators (or AD) if and when the member's term > renews. > > b) Document Mentor Availability and Assignments: As part of the > Routing Area wiki, each Directorate member will specify the maximum > number of documents that he or she is able to mentor. Also listed > will be the list of mentored documents (and a count). > > i) When a Directorate member is assigned as the Document > mentor, the Routing Directorate Coordinator will update the > wiki page and create a wiki page for the draft. > > ii) When a Document Mentor provides a review, that should be > stored in the draft's wiki page along with the resolutions. > > iii) When the Document Mentor's final review at WGLC is done, > the Document Mentor should move the draft to a list of > "previously mentored documents" associated with their name. > It is ideal to write up a summary of the document mentoring experience. > > c) Unmentored Documents: Drafts which have declined a document > mentor should be listed on a wiki page. > > d) For each WG's wiki, it'd be useful to have the list of drafts > with their associated Document Mentors (or lack thereof) and the > link to the draft's wiki page. > > The Basic Process: > > When a new WG draft is adopted, the WG chairs and the Routing > Directorate Coordinators discuss and agree on possible Document > Mentors (up to 3). Then the Routing Directorate Coordinator > confirms with the Routing Directorate members about their > availability and willingness to mentor this particular draft. Once > one is selected, the Routing Directorate Coordinator updates the > wiki and notifies the WG chairs and draft authors. > > a) With the agreement of the ADs, a Document Mentor who is not a > member of the Routing Directorate may be selected. > > b) The WG chairs can, after consulting with the draft authors, > decline to have a Document Mentor. > > c) The Document Mentor should coordinate with the Document > Shepherd for hand-off after WGLC. > > > > From nobody Mon Mar 31 06:13:13 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154F61A0851; Mon, 31 Mar 2014 06:13:11 -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 p0TvmJkQyicZ; Mon, 31 Mar 2014 06:13:07 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id A59AF1A0982; Mon, 31 Mar 2014 06:13:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id D08462412B7; Mon, 31 Mar 2014 06:13:03 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 91D5C2403C5; Mon, 31 Mar 2014 06:13:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 31 Mar 2014 15:12:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/7xKnE3zjS2SNXcPLUASdPsEyl1w Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:13:11 -0000 Jamal, On 31 Mar 2014, at 14:48, Jamal Hadi Salim wrote: > The only hole i see is your scale/workload numbers dont take into > consideration the fact that there could be a lot more spread than 200 = active > documents per year that are in between WG adoption to publication. > And that at times that process takes a little longer. > Jari's tools could provide some stats (and i could be therefore off), = but > to make my point i will handwave and say it is a magnitude more docs, > some of which a mentor is responsible for and some which are making > progress. > This means each of the 40 people is actively mentoring about 25 = documents > per year. And lets say 60 over 3 years. You will need a large number = of people > in the directorate to scale. Scalability is an issue in whatever we are designing in the IETF, to be = sure. But I think that various documents are very heterogenous in = nature. Some documents would be written by people who really do not need a = mentor ("Come here, Ross Callon, so that this whippersnapper can tell = you how the IETF works - and Adrian, now, let me explain to you what a = good RFC looks like" -- that just doesn't seem plausible to happen). Other documents would probably need the occasional review, but mostly be = consensual and developed by a well engaged WG, so the "mentor" would be = mostly redundant, and just "be there" without doing much. A few documents would likely benefit from more continuing mentoring - = unexperienced IETFers as authors, but eager to learn the ropes. That's = actually the "good kind of effort" to spend, that's working on renewing = the future stock of RTG-DIR members and WG Chairs. I know that when I = put pen to paper for the first time in the IETF decades ago, I'd have = appreciated having had a mentor. Further, I predict that many documents would likely be rather bursty in = the efforts required. If I was to mentor a document, I'd probably want = to spend a good chunk of effort around WG adoption on reviews, = discussions with the authors, commenting, learning what the WG wants = with it - but, hopefully then it will drop to an occasional review = (ideally, at least, looking at the diff at each release), discussions on = precise points and potential pitfalls, and likely with another burst = when the authors start preparing for WGLC. I think that as long as the ADs are not mechanically dooling out = documents, but there's a human in the loop to whom we can say "Well, = gee, I may mentor just one document, but right now it's a full-time job = to work with the authors, could you ask Jamal to take thisone instead?" = we'll do alright. > And then there's handoff challenges. If i am mentoring a doc that is > not complete > before i let go ... >=20 Worst case: think of the document taking over as "having just been = called for WG adoption", so provide a review, chat with the authors. = Best case, you have notes to hand over, or even sit down and have a beer = with whoever takes over after you. Anything more complicated than that? Thomas >=20 > cheers, > jamal >=20 >=20 >=20 > On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel = wrote: >> Hi, >>=20 >> One of the ideas to come out of the recent discussions is appointing = a mentor >> per document from the time it is adopted by a Routing Area working = group until >> it completes WG last call. >>=20 >> This would be voluntary in two dimensions: >> - the WG chairs would need to deem that one would be beneficial >> - we would have to find someone from the Directorate willing to >> take on the document. >>=20 >> We don't think that technology expertise is as useful in this as IETF = clue and >> general routing experience. >>=20 >> So, to take this forward we would need: >> - WG chairs to say "Yes, we can see that that would have >> potential benefit >> - Directorate members to say "Yes, we could take on that >> additional work. >>=20 >> Alia and I have put together some preliminary notes on how this would = all hang >> together. >>=20 >> Your opinions and rotten fruit are solicited. >>=20 >> Thanks, >> Adrian and Alia >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Document Mentors in the Routing Area >>=20 >> The Problems: >>=20 >> a) Drafts get little review outside the working group and sometimes = inside >> the working group until after working group last call. At that point = it is >> often >> painful and costly to make meaningful improvements to the drafts. >>=20 >> b) Authors may not know how or whom to ask for assistance or review >> (e.g., IANA section, Security Section, Operational and Management >> considerations, details of a protocol, etc. ). >>=20 >> The Goals: >>=20 >> a) Excellent and consistent review at WG adoption and before WG last >> call. >>=20 >> b) Ability for prolonged discussion and problem-solving when the >> draft can still be easily enhanced. >>=20 >> c) Reduced time to delivery of RFCs. >>=20 >> d) Quality documents. >>=20 >> The Solution: >>=20 >> A per-document mentor who is a known neutral party to whom the >> authors can go for advice on: >> - how to write a section >> - specific issues that arise >> - ways to resolve conflicts. >>=20 >> The document mentor also watches the progress of the document >> and gives advice and steerage. >>=20 >> It is not assumed that every document will need or benefit from >> having a mentor. >>=20 >> The Expected Workload: >>=20 >> The routing directorate has approximately 40 people. If we assume >> that approximately 50 drafts pass WG adoption and a similar number >> pass WGLC each year, then the load is 2.5 documents per person >> per year. If we assume that there are about 200 WG drafts in the >> Routing Area and that they all have mentors, then each Routing >> Directorate member will have 5 drafts that she or he is mentoring. >>=20 >> The Supporting Data Artefacts: >>=20 >> a) As part of the Routing Area wiki, the areas of knowledge for >> each member of the Routing Directorate will be publicly specified. >> This is added to the wiki by the Routing Area Coordinators (or AD) >> when the member joins the Routing Directorate, updated by the >> member while he or she is on the Directorate, and updated by the >> Routing Area Coordinators (or AD) if and when the member's term >> renews. >>=20 >> b) Document Mentor Availability and Assignments: As part of the >> Routing Area wiki, each Directorate member will specify the maximum >> number of documents that he or she is able to mentor. Also listed >> will be the list of mentored documents (and a count). >>=20 >> i) When a Directorate member is assigned as the Document >> mentor, the Routing Directorate Coordinator will update the >> wiki page and create a wiki page for the draft. >>=20 >> ii) When a Document Mentor provides a review, that should be >> stored in the draft's wiki page along with the resolutions. >>=20 >> iii) When the Document Mentor's final review at WGLC is done, >> the Document Mentor should move the draft to a list of >> "previously mentored documents" associated with their name. >> It is ideal to write up a summary of the document mentoring = experience. >>=20 >> c) Unmentored Documents: Drafts which have declined a document >> mentor should be listed on a wiki page. >>=20 >> d) For each WG's wiki, it'd be useful to have the list of drafts >> with their associated Document Mentors (or lack thereof) and the >> link to the draft's wiki page. >>=20 >> The Basic Process: >>=20 >> When a new WG draft is adopted, the WG chairs and the Routing >> Directorate Coordinators discuss and agree on possible Document >> Mentors (up to 3). Then the Routing Directorate Coordinator >> confirms with the Routing Directorate members about their >> availability and willingness to mentor this particular draft. Once >> one is selected, the Routing Directorate Coordinator updates the >> wiki and notifies the WG chairs and draft authors. >>=20 >> a) With the agreement of the ADs, a Document Mentor who is not a >> member of the Routing Directorate may be selected. >>=20 >> b) The WG chairs can, after consulting with the draft authors, >> decline to have a Document Mentor. >>=20 >> c) The Document Mentor should coordinate with the Document >> Shepherd for hand-off after WGLC. >>=20 >>=20 >>=20 >>=20 >=20 From nobody Mon Mar 31 06:40:24 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94F51A0A01; Mon, 31 Mar 2014 06:40:20 -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, 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 V1KM3Oy2dbS6; Mon, 31 Mar 2014 06:40:18 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 792A31A09A7; Mon, 31 Mar 2014 06:40:12 -0700 (PDT) X-AuditID: c618062d-b7fa68e000006444-5b-53396de43fd1 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B4.85.25668.4ED69335; Mon, 31 Mar 2014 15:30:12 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Mon, 31 Mar 2014 09:40:06 -0400 From: Acee Lindem To: Thomas Heide Clausen Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QAJqvOAAADXBgAAAPJxgA== Date: Mon, 31 Mar 2014 13:40:05 +0000 Message-ID: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> In-Reply-To: <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> 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: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXRPiO6TXMtgg99PjSx+9Nxgtri9dQ+b xYPDC9ksFqx5ym7R/o3ZgdVjyZKfTB7bbq1l9VixeSWjx/VpnxgDWKK4bFJSczLLUov07RK4 Mi4tOMNW8Mqz4vfPH0wNjAutuhg5OSQETCServrPBmGLSVy4tx7I5uIQEjjKKPG2ZwEjhLOc UWLnw83MIFVsAjoSzx/9A7NFBIwlNp3czQJSxCywlFFi2ZtJYAlhAXWJDyc+sEAUaUhMmfKX HcJ2kmj7N5Opi5GDg0VAVWJpUyBImFfAXmLZ2lPMEMv2MEpMWLuFDaSGU8BV4mNnEkgNI9B1 30+tYQKxmQXEJW49mc8EcbWAxJI955khbFGJl4//sULYihL7+qezQ9QbSLw/N58ZwraWOLfu HdQcbYllC18zQ9wgKHFy5hOWCYzis5CsmIWkfRaS9llI2mchaV/AyLqKkaO0OLUsN93IYBMj MA6PSbDp7mDc89LyEKM0B4uSOO+Xt85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgZd6X+ TBbUKmWfove3729ml/X0B94pF9zjb1jqbXg801xJOvn+tV3hV4XMyhIuJFRMeflrjViE9Axh GWFP1nyhbKHQ96LvDXIermO3WHh3SXOe2/1V4n1On7Y4yCS5LE/YUHHvj0VFjcjvS4Hrpyr+ lVz9Krc8xc/nz2IdJoOcsuV7b6wKbFZiKc5INNRiLipOBACyq8hvkQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/lAsaKRE_2wcmY3QY_Bf6yQimWGc Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , Jamal Hadi Salim Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:40:21 -0000 Hi Thomas, Jamal, and Adrian,=20 I agree with Jamal on scaling. There may not be an order of magnitude diffe= rence between the number of drafts accepted as WG documents and those that = make it through WG last call but it is certainly some power of 2. Hence, we= =92d be increasing our workload by 2 to 4 times just in shear numbers witho= ut even taking into account the fact that the bad drafts will take much mor= e time than the ones making it through WG last call.=20 Thanks, Acee=20 On Mar 31, 2014, at 9:12 AM, Thomas Clausen wrot= e: > Jamal, >=20 > On 31 Mar 2014, at 14:48, Jamal Hadi Salim wrote: >=20 >> The only hole i see is your scale/workload numbers dont take into >> consideration the fact that there could be a lot more spread than 200 ac= tive >> documents per year that are in between WG adoption to publication. >> And that at times that process takes a little longer. >> Jari's tools could provide some stats (and i could be therefore off), bu= t >> to make my point i will handwave and say it is a magnitude more docs, >> some of which a mentor is responsible for and some which are making >> progress. >> This means each of the 40 people is actively mentoring about 25 document= s >> per year. And lets say 60 over 3 years. You will need a large number of = people >> in the directorate to scale. >=20 > Scalability is an issue in whatever we are designing in the IETF, to be s= ure. But I think that various documents are very heterogenous in nature. >=20 > Some documents would be written by people who really do not need a mentor= ("Come here, Ross Callon, so that this whippersnapper can tell you how the= IETF works - and Adrian, now, let me explain to you what a good RFC looks = like" -- that just doesn't seem plausible to happen). >=20 > Other documents would probably need the occasional review, but mostly be = consensual and developed by a well engaged WG, so the "mentor" would be mos= tly redundant, and just "be there" without doing much. >=20 > A few documents would likely benefit from more continuing mentoring - une= xperienced IETFers as authors, but eager to learn the ropes. That's actuall= y the "good kind of effort" to spend, that's working on renewing the future= stock of RTG-DIR members and WG Chairs. I know that when I put pen to pape= r for the first time in the IETF decades ago, I'd have appreciated having h= ad a mentor. >=20 > Further, I predict that many documents would likely be rather bursty in t= he efforts required. If I was to mentor a document, I'd probably want to sp= end a good chunk of effort around WG adoption on reviews, discussions with = the authors, commenting, learning what the WG wants with it - but, hopefull= y then it will drop to an occasional review (ideally, at least, looking at = the diff at each release), discussions on precise points and potential pitf= alls, and likely with another burst when the authors start preparing for WG= LC. >=20 > I think that as long as the ADs are not mechanically dooling out document= s, but there's a human in the loop to whom we can say "Well, gee, I may men= tor just one document, but right now it's a full-time job to work with the = authors, could you ask Jamal to take thisone instead?" we'll do alright. >=20 >> And then there's handoff challenges. If i am mentoring a doc that is >> not complete >> before i let go ... >>=20 >=20 > Worst case: think of the document taking over as "having just been called= for WG adoption", so provide a review, chat with the authors. Best case, y= ou have notes to hand over, or even sit down and have a beer with whoever t= akes over after you. >=20 > Anything more complicated than that? >=20 > Thomas >=20 >>=20 >> cheers, >> jamal >>=20 >>=20 >>=20 >> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel wro= te: >>> Hi, >>>=20 >>> One of the ideas to come out of the recent discussions is appointing a = mentor >>> per document from the time it is adopted by a Routing Area working grou= p until >>> it completes WG last call. >>>=20 >>> This would be voluntary in two dimensions: >>> - the WG chairs would need to deem that one would be beneficial >>> - we would have to find someone from the Directorate willing to >>> take on the document. >>>=20 >>> We don't think that technology expertise is as useful in this as IETF c= lue and >>> general routing experience. >>>=20 >>> So, to take this forward we would need: >>> - WG chairs to say "Yes, we can see that that would have >>> potential benefit >>> - Directorate members to say "Yes, we could take on that >>> additional work. >>>=20 >>> Alia and I have put together some preliminary notes on how this would a= ll hang >>> together. >>>=20 >>> Your opinions and rotten fruit are solicited. >>>=20 >>> Thanks, >>> Adrian and Alia >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Document Mentors in the Routing Area >>>=20 >>> The Problems: >>>=20 >>> a) Drafts get little review outside the working group and sometimes ins= ide >>> the working group until after working group last call. At that point it= is >>> often >>> painful and costly to make meaningful improvements to the drafts. >>>=20 >>> b) Authors may not know how or whom to ask for assistance or review >>> (e.g., IANA section, Security Section, Operational and Management >>> considerations, details of a protocol, etc. ). >>>=20 >>> The Goals: >>>=20 >>> a) Excellent and consistent review at WG adoption and before WG last >>> call. >>>=20 >>> b) Ability for prolonged discussion and problem-solving when the >>> draft can still be easily enhanced. >>>=20 >>> c) Reduced time to delivery of RFCs. >>>=20 >>> d) Quality documents. >>>=20 >>> The Solution: >>>=20 >>> A per-document mentor who is a known neutral party to whom the >>> authors can go for advice on: >>> - how to write a section >>> - specific issues that arise >>> - ways to resolve conflicts. >>>=20 >>> The document mentor also watches the progress of the document >>> and gives advice and steerage. >>>=20 >>> It is not assumed that every document will need or benefit from >>> having a mentor. >>>=20 >>> The Expected Workload: >>>=20 >>> The routing directorate has approximately 40 people. If we assume >>> that approximately 50 drafts pass WG adoption and a similar number >>> pass WGLC each year, then the load is 2.5 documents per person >>> per year. If we assume that there are about 200 WG drafts in the >>> Routing Area and that they all have mentors, then each Routing >>> Directorate member will have 5 drafts that she or he is mentoring. >>>=20 >>> The Supporting Data Artefacts: >>>=20 >>> a) As part of the Routing Area wiki, the areas of knowledge for >>> each member of the Routing Directorate will be publicly specified. >>> This is added to the wiki by the Routing Area Coordinators (or AD) >>> when the member joins the Routing Directorate, updated by the >>> member while he or she is on the Directorate, and updated by the >>> Routing Area Coordinators (or AD) if and when the member's term >>> renews. >>>=20 >>> b) Document Mentor Availability and Assignments: As part of the >>> Routing Area wiki, each Directorate member will specify the maximum >>> number of documents that he or she is able to mentor. Also listed >>> will be the list of mentored documents (and a count). >>>=20 >>> i) When a Directorate member is assigned as the Document >>> mentor, the Routing Directorate Coordinator will update the >>> wiki page and create a wiki page for the draft. >>>=20 >>> ii) When a Document Mentor provides a review, that should be >>> stored in the draft's wiki page along with the resolutions. >>>=20 >>> iii) When the Document Mentor's final review at WGLC is done, >>> the Document Mentor should move the draft to a list of >>> "previously mentored documents" associated with their name. >>> It is ideal to write up a summary of the document mentoring exper= ience. >>>=20 >>> c) Unmentored Documents: Drafts which have declined a document >>> mentor should be listed on a wiki page. >>>=20 >>> d) For each WG's wiki, it'd be useful to have the list of drafts >>> with their associated Document Mentors (or lack thereof) and the >>> link to the draft's wiki page. >>>=20 >>> The Basic Process: >>>=20 >>> When a new WG draft is adopted, the WG chairs and the Routing >>> Directorate Coordinators discuss and agree on possible Document >>> Mentors (up to 3). Then the Routing Directorate Coordinator >>> confirms with the Routing Directorate members about their >>> availability and willingness to mentor this particular draft. Once >>> one is selected, the Routing Directorate Coordinator updates the >>> wiki and notifies the WG chairs and draft authors. >>>=20 >>> a) With the agreement of the ADs, a Document Mentor who is not a >>> member of the Routing Directorate may be selected. >>>=20 >>> b) The WG chairs can, after consulting with the draft authors, >>> decline to have a Document Mentor. >>>=20 >>> c) The Document Mentor should coordinate with the Document >>> Shepherd for hand-off after WGLC. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >=20 From nobody Mon Mar 31 06:51:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB041A0862 for ; Mon, 31 Mar 2014 06:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ns7XBJdF1Fg3 for ; Mon, 31 Mar 2014 06:51:18 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8B1A0A3E for ; Mon, 31 Mar 2014 06:51:17 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id rd3so8228916pab.39 for ; Mon, 31 Mar 2014 06:51:15 -0700 (PDT) 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:content-transfer-encoding; bh=RShTmUdAhi3y2UZkApVC6xPt5Z+x7XhOWbK+7S7MgQI=; b=QLusY3FaGQcNCLQAk8tIcu9gol4ZUtvYHkmytQWmAJId9cWk1wC1PrXogSFFDmlBhU +6lWZG+v/wxxeEwPylTty6s1RwkNdo/lTOj4i9lEOFwgE6qCRZ5Kwk2Zw9VnkYZn0+Yx 3kCo/qA+vOplkIlJss82Xk6ady/WQT2PTsZZMLDe/XnPEah/kR6IR2wx8rpCtR6Q7vDa Xp8IxSEGrOowkfcnyvwwPxxOMfQJZbi2EXd0wWO+eyjHiCknvk4fCNl2LV7Z0WXk1i1w zRR1kcA4Ne2SnG3WRFM4uSE4kjmpy6rBi6Rz34MRRWfp1Otb1PF+OwcQRN+GskCLtotL 2zSQ== X-Gm-Message-State: ALoCoQlNlU3SAyWkcw2tuRicfOOc276mN/P45P+k9RmQ2KmTxoSR8J6cfoyQJThQAwMJHVU0TtL1 X-Received: by 10.68.237.133 with SMTP id vc5mr25308205pbc.92.1396273874894; Mon, 31 Mar 2014 06:51:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.11.234 with HTTP; Mon, 31 Mar 2014 06:50:54 -0700 (PDT) In-Reply-To: <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> From: Jamal Hadi Salim Date: Mon, 31 Mar 2014 09:50:54 -0400 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/tEdLrbcMCsdwY9UUFOlecCbV83c Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 13:51:20 -0000 Hi Thomas, On Mon, Mar 31, 2014 at 9:12 AM, Thomas Clausen wrote: > Scalability is an issue in whatever we are designing in the IETF, to be s= ure. > But I think that various documents are very heterogenous in nature. > > Some documents would be written by people who really do not need a mentor= ("Come here, Ross >Callon, so that this whippersnapper can tell you how th= e IETF works - and Adrian, now, let me explain to >you what a good RFC look= s like" -- that just doesn't seem plausible to happen). > > Other documents would probably need the occasional review, but mostly be = consensual and developed >by a well engaged WG, so the "mentor" would be mo= stly redundant, and just "be there" without doing >much. > > A few documents would likely benefit from more continuing mentoring - une= xperienced IETFers as >authors, but eager to learn the ropes. That's actual= ly the "good kind of effort" to spend, that's working on >renewing the futu= re stock of RTG-DIR members and WG Chairs. You are right in that different docs will require different effort and that on average the apocalypse I am painting is exaggerated to make a point. Again stats here would help. I think just a baseline response to "on average how long does it take to go from WG adoption to publication in the Routing Area" would help get an estimate. I have seen these stats on a per doc level - some effort is needed to get them on a per area aggregation. I think with such a stat at hand one can deduce the average time a mentor would have to be involved with a document. >I know that when I put pen to paper for >the first time in the IETF decade= s ago, I'd have appreciated having had a mentor. > > Further, I predict that many documents would likely be rather bursty in t= he efforts required. If I was to mentor a document, I'd probably want to sp= end a good chunk of effort around WG adoption on reviews, discussions with = the authors, commenting, learning what the WG wants with it - but, hopefull= y then it will drop to an occasional review (ideally, at least, looking at = the diff at each release), discussions on precise points and potential pitf= alls, and likely with another burst when the authors start preparing for WG= LC. > > I think that as long as the ADs are not mechanically dooling out document= s, but there's a human in the loop to whom we can say "Well, gee, I may men= tor just one document, but right now it's a full-time job to work with the = authors, could you ask Jamal to take thisone instead?" we'll do alright. > My view of mentorship is skewed a little. There has to be a return on investment for the mentor. If i am going to spend many hours reviewing and rewritting the draft, I might as well be an author and i have to be very interested in the topic iam volunteering for. As an example, Linux has something called "kernel newbies" which is supposed to be a mentorship interface where experienced people come to help the newbies. In my opinion it is a fringe group where people get to learn but it rarely produces useful work that contributes to the kernel proper. Not many experienced people get involved at all (the choice is whether I am going to do more exciting things or i have to handle newbie loops). What helps some sanity in quality is the gatekeeper / maintainer of the code - you send bad code that doesnt conform, you are not going past the gate. And I think the current system where you have Routing directorate reviews serves that except they really have no authority (which is a good thing). >> And then there's handoff challenges. If i am mentoring a doc that is >> not complete >> before i let go ... >> > > Worst case: think of the document taking over as "having just been called= for WG adoption", so provide a review, chat with the authors. Best case, y= ou have notes to hand over, or even sit down and have a beer with whoever t= akes over after you. > > Anything more complicated than that? > Good ideas. We probably just need to revamp the routing area directorate review involvement not to be after the adoption but rather just before the shepherding step. cheers, jamal > Thomas > >> >> cheers, >> jamal >> >> >> >> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel wro= te: >>> Hi, >>> >>> One of the ideas to come out of the recent discussions is appointing a = mentor >>> per document from the time it is adopted by a Routing Area working grou= p until >>> it completes WG last call. >>> >>> This would be voluntary in two dimensions: >>> - the WG chairs would need to deem that one would be beneficial >>> - we would have to find someone from the Directorate willing to >>> take on the document. >>> >>> We don't think that technology expertise is as useful in this as IETF c= lue and >>> general routing experience. >>> >>> So, to take this forward we would need: >>> - WG chairs to say "Yes, we can see that that would have >>> potential benefit >>> - Directorate members to say "Yes, we could take on that >>> additional work. >>> >>> Alia and I have put together some preliminary notes on how this would a= ll hang >>> together. >>> >>> Your opinions and rotten fruit are solicited. >>> >>> Thanks, >>> Adrian and Alia >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Document Mentors in the Routing Area >>> >>> The Problems: >>> >>> a) Drafts get little review outside the working group and sometimes in= side >>> the working group until after working group last call. At that point i= t is >>> often >>> painful and costly to make meaningful improvements to the drafts. >>> >>> b) Authors may not know how or whom to ask for assistance or review >>> (e.g., IANA section, Security Section, Operational and Management >>> considerations, details of a protocol, etc. ). >>> >>> The Goals: >>> >>> a) Excellent and consistent review at WG adoption and before WG last >>> call. >>> >>> b) Ability for prolonged discussion and problem-solving when the >>> draft can still be easily enhanced. >>> >>> c) Reduced time to delivery of RFCs. >>> >>> d) Quality documents. >>> >>> The Solution: >>> >>> A per-document mentor who is a known neutral party to whom the >>> authors can go for advice on: >>> - how to write a section >>> - specific issues that arise >>> - ways to resolve conflicts. >>> >>> The document mentor also watches the progress of the document >>> and gives advice and steerage. >>> >>> It is not assumed that every document will need or benefit from >>> having a mentor. >>> >>> The Expected Workload: >>> >>> The routing directorate has approximately 40 people. If we assume >>> that approximately 50 drafts pass WG adoption and a similar number >>> pass WGLC each year, then the load is 2.5 documents per person >>> per year. If we assume that there are about 200 WG drafts in the >>> Routing Area and that they all have mentors, then each Routing >>> Directorate member will have 5 drafts that she or he is mentoring. >>> >>> The Supporting Data Artefacts: >>> >>> a) As part of the Routing Area wiki, the areas of knowledge for >>> each member of the Routing Directorate will be publicly specified. >>> This is added to the wiki by the Routing Area Coordinators (or AD) >>> when the member joins the Routing Directorate, updated by the >>> member while he or she is on the Directorate, and updated by the >>> Routing Area Coordinators (or AD) if and when the member's term >>> renews. >>> >>> b) Document Mentor Availability and Assignments: As part of the >>> Routing Area wiki, each Directorate member will specify the maximum >>> number of documents that he or she is able to mentor. Also listed >>> will be the list of mentored documents (and a count). >>> >>> i) When a Directorate member is assigned as the Document >>> mentor, the Routing Directorate Coordinator will update the >>> wiki page and create a wiki page for the draft. >>> >>> ii) When a Document Mentor provides a review, that should be >>> stored in the draft's wiki page along with the resolutions. >>> >>> iii) When the Document Mentor's final review at WGLC is done, >>> the Document Mentor should move the draft to a list of >>> "previously mentored documents" associated with their name. >>> It is ideal to write up a summary of the document mentoring expe= rience. >>> >>> c) Unmentored Documents: Drafts which have declined a document >>> mentor should be listed on a wiki page. >>> >>> d) For each WG's wiki, it'd be useful to have the list of drafts >>> with their associated Document Mentors (or lack thereof) and the >>> link to the draft's wiki page. >>> >>> The Basic Process: >>> >>> When a new WG draft is adopted, the WG chairs and the Routing >>> Directorate Coordinators discuss and agree on possible Document >>> Mentors (up to 3). Then the Routing Directorate Coordinator >>> confirms with the Routing Directorate members about their >>> availability and willingness to mentor this particular draft. Once >>> one is selected, the Routing Directorate Coordinator updates the >>> wiki and notifies the WG chairs and draft authors. >>> >>> a) With the agreement of the ADs, a Document Mentor who is not a >>> member of the Routing Directorate may be selected. >>> >>> b) The WG chairs can, after consulting with the draft authors, >>> decline to have a Document Mentor. >>> >>> c) The Document Mentor should coordinate with the Document >>> Shepherd for hand-off after WGLC. >>> >>> >>> >>> >> > From nobody Mon Mar 31 07:15:46 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295201A6EE2; Mon, 31 Mar 2014 07:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 YcOvu0MOCiD2; Mon, 31 Mar 2014 07:15:42 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id E17951A0A1B; Mon, 31 Mar 2014 07:15:41 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:57782 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WUczw-0007yf-3a; Mon, 31 Mar 2014 14:15:36 +0000 From: "Russ White" To: "'Jamal Hadi Salim'" , "'Thomas Clausen'" References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> In-Reply-To: Date: Mon, 31 Mar 2014 10:15:34 -0400 Message-ID: <02c701cf4ceb$af62d870$0e288950$@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: AQLRW8MC2jlgo4YShVQKqZSaQzM51wDaXBXyAmj3F30Bsi0auJjPc0xQ 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/rtg-dir/ZcA-N_Nlk5ZzbDk1XF9kXxTWTPY Cc: 'Adrian Farrel' , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:15:43 -0000 > My view of mentorship is skewed a little. There has to be a return on > investment for the mentor. This, IMHO, is the biggest blocker. While it "should be enough," to know that we're improving the quality of the IETF's output, it's probably not. Maybe add the mentor as "editor," or create a new "editor," type slot in the acks, or something like that? :-) Russ From nobody Mon Mar 31 07:18:23 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F0B1A0A1B; Mon, 31 Mar 2014 07:18:21 -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 RU6YWq5ET-EU; Mon, 31 Mar 2014 07:18:19 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id EA3111A087B; Mon, 31 Mar 2014 07:18:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 1F433240182; Mon, 31 Mar 2014 07:18:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id CA311240462; Mon, 31 Mar 2014 07:18:13 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 31 Mar 2014 16:18:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0246663B-D112-489E-B060-5686253C98E7@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/lXHBNiLq_MHWfLubWvDgnpddZvc Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:18:21 -0000 Dear Jamal, Below. On 31 Mar 2014, at 15:50, Jamal Hadi Salim wrote: > Hi Thomas, >=20 > On Mon, Mar 31, 2014 at 9:12 AM, Thomas Clausen > wrote: >=20 >> Scalability is an issue in whatever we are designing in the IETF, to = be sure. >> But I think that various documents are very heterogenous in nature. >>=20 >> Some documents would be written by people who really do not need a = mentor ("Come here, Ross >Callon, so that this whippersnapper can tell = you how the IETF works - and Adrian, now, let me explain to >you what a = good RFC looks like" -- that just doesn't seem plausible to happen). >>=20 >> Other documents would probably need the occasional review, but mostly = be consensual and developed >by a well engaged WG, so the "mentor" would = be mostly redundant, and just "be there" without doing >much. >>=20 >> A few documents would likely benefit from more continuing mentoring - = unexperienced IETFers as >authors, but eager to learn the ropes. That's = actually the "good kind of effort" to spend, that's working on >renewing = the future stock of RTG-DIR members and WG Chairs. >=20 > You are right in that different docs will require different effort and > that on average the apocalypse > I am painting is exaggerated to make a point. > Again stats here would help. I think just a baseline response to "on > average how long > does it take to go from WG adoption to publication in the Routing > Area" would help > get an estimate. I have seen these stats on a per doc level - some > effort is needed to get > them on a per area aggregation. I think with such a stat at hand one > can deduce the average > time a mentor would have to be involved with a document. The thing is, that averages not always are helpful.=20 I have a document with the RFC Editor right now, where the -00 came out = almost 10 years ago. =46rom that -00, however, 4-6 other RFCs were = shaken out over the years. To statistics, however, that document would = look like a "10 year process" if seen in isolation. At the same time, I = have a document sitting with the RFC Editor also, which hit the IESG in = its -00 version. These may not be typical cases, but it's far from = unheard of either, to see stuff of this sort. I agree, though, that getting some data would be helpful. I am not sure, = though, that we should hold up and wait for data before digging in. The = data from the tracker is there to mine, in case we want to measure if = there's any impact of this measure.=20 More to the point...the tracker does not have any data on the "mentor = workload incurred". Which is why I think that running what the ADs = suggest as an experiment is a great idea. We can always kill it down the = line if it turns out to be a failure: not to help, to scale poorly, = etc. >> I know that when I put pen to paper for >the first time in the IETF = decades ago, I'd have appreciated having had a mentor. >>=20 >> Further, I predict that many documents would likely be rather bursty = in the efforts required. If I was to mentor a document, I'd probably = want to spend a good chunk of effort around WG adoption on reviews, = discussions with the authors, commenting, learning what the WG wants = with it - but, hopefully then it will drop to an occasional review = (ideally, at least, looking at the diff at each release), discussions on = precise points and potential pitfalls, and likely with another burst = when the authors start preparing for WGLC. >>=20 >> I think that as long as the ADs are not mechanically dooling out = documents, but there's a human in the loop to whom we can say "Well, = gee, I may mentor just one document, but right now it's a full-time job = to work with the authors, could you ask Jamal to take thisone instead?" = we'll do alright. >>=20 >=20 > My view of mentorship is skewed a little. There has to be a return on > investment for the mentor. > If i am going to spend many hours reviewing and rewritting the draft, > I might as well be an author > and i have to be very interested in the topic iam volunteering for. Fair enough. Personally, I am grateful enough for the work that was done by others in = building the Internet, and the help I got from elder IETFers when I = started in the IETF, to want to "pay it forward" a bit, as best I can. > As an example, Linux has something called "kernel newbies" which is > supposed to be a mentorship interface > where experienced people come to help the newbies. In my opinion it is > a fringe group where people get > to learn but it rarely produces useful work that contributes to the > kernel proper. Not many experienced people > get involved at all (the choice is whether I am going to do more > exciting things or i have to handle newbie loops). > What helps some sanity in quality is the gatekeeper / maintainer of > the code - you send bad code that doesnt > conform, you are not going past the gate. And I think the current > system where you have Routing directorate > reviews serves that except they really have no authority (which is a > good thing). That's a very different philosophy, I think.=20 Essentially, you say that you prefer "spending time evaluating and = rejecting a kernel-patch on submission" than "spending time making sure = that submitted kernel-patches are good". "Spending time evaluating and rejecting a kernel-patch on submission" = is, essentially, that which we have now: IETF LCs with roadblocks by way = of directorate reviews and ADs. Speaking as an author, I'd think that getting "early guidance" is more = valuable than getting "late roadblocks". Nothing more frustrating than a = "late roadblock" when you feel you're done. Speaking as a RTG-Dir member, I'd actually also much rather spend 1h30 = mentoring someone early, than would I like to spend 1h writing a harsh = review during IETF LC. I do personally believe that this is an "ounce of = prevention worth a pound of cure" situation -- assuming that authors are = working on more than a single document through their IETF careers. >>> And then there's handoff challenges. If i am mentoring a doc that is >>> not complete >>> before i let go ... >>>=20 >>=20 >> Worst case: think of the document taking over as "having just been = called for WG adoption", so provide a review, chat with the authors. = Best case, you have notes to hand over, or even sit down and have a beer = with whoever takes over after you. >>=20 >> Anything more complicated than that? >>=20 >=20 > Good ideas. We probably just need to revamp the routing area > directorate review involvement not to be > after the adoption but rather just before the shepherding step. >=20 Well, I disagree there, I think at WG adoption is the right time. Just = before shepherding step is (for all intents and purposes) the same as = during IETF LC. Thomas > cheers, > jamal >=20 >> Thomas >>=20 >>>=20 >>> cheers, >>> jamal >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel = wrote: >>>> Hi, >>>>=20 >>>> One of the ideas to come out of the recent discussions is = appointing a mentor >>>> per document from the time it is adopted by a Routing Area working = group until >>>> it completes WG last call. >>>>=20 >>>> This would be voluntary in two dimensions: >>>> - the WG chairs would need to deem that one would be beneficial >>>> - we would have to find someone from the Directorate willing to >>>> take on the document. >>>>=20 >>>> We don't think that technology expertise is as useful in this as = IETF clue and >>>> general routing experience. >>>>=20 >>>> So, to take this forward we would need: >>>> - WG chairs to say "Yes, we can see that that would have >>>> potential benefit >>>> - Directorate members to say "Yes, we could take on that >>>> additional work. >>>>=20 >>>> Alia and I have put together some preliminary notes on how this = would all hang >>>> together. >>>>=20 >>>> Your opinions and rotten fruit are solicited. >>>>=20 >>>> Thanks, >>>> Adrian and Alia >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Document Mentors in the Routing Area >>>>=20 >>>> The Problems: >>>>=20 >>>> a) Drafts get little review outside the working group and sometimes = inside >>>> the working group until after working group last call. At that = point it is >>>> often >>>> painful and costly to make meaningful improvements to the drafts. >>>>=20 >>>> b) Authors may not know how or whom to ask for assistance or = review >>>> (e.g., IANA section, Security Section, Operational and Management >>>> considerations, details of a protocol, etc. ). >>>>=20 >>>> The Goals: >>>>=20 >>>> a) Excellent and consistent review at WG adoption and before WG = last >>>> call. >>>>=20 >>>> b) Ability for prolonged discussion and problem-solving when the >>>> draft can still be easily enhanced. >>>>=20 >>>> c) Reduced time to delivery of RFCs. >>>>=20 >>>> d) Quality documents. >>>>=20 >>>> The Solution: >>>>=20 >>>> A per-document mentor who is a known neutral party to whom the >>>> authors can go for advice on: >>>> - how to write a section >>>> - specific issues that arise >>>> - ways to resolve conflicts. >>>>=20 >>>> The document mentor also watches the progress of the document >>>> and gives advice and steerage. >>>>=20 >>>> It is not assumed that every document will need or benefit from >>>> having a mentor. >>>>=20 >>>> The Expected Workload: >>>>=20 >>>> The routing directorate has approximately 40 people. If we assume >>>> that approximately 50 drafts pass WG adoption and a similar number >>>> pass WGLC each year, then the load is 2.5 documents per person >>>> per year. If we assume that there are about 200 WG drafts in the >>>> Routing Area and that they all have mentors, then each Routing >>>> Directorate member will have 5 drafts that she or he is mentoring. >>>>=20 >>>> The Supporting Data Artefacts: >>>>=20 >>>> a) As part of the Routing Area wiki, the areas of knowledge for >>>> each member of the Routing Directorate will be publicly specified. >>>> This is added to the wiki by the Routing Area Coordinators (or AD) >>>> when the member joins the Routing Directorate, updated by the >>>> member while he or she is on the Directorate, and updated by the >>>> Routing Area Coordinators (or AD) if and when the member's term >>>> renews. >>>>=20 >>>> b) Document Mentor Availability and Assignments: As part of the >>>> Routing Area wiki, each Directorate member will specify the = maximum >>>> number of documents that he or she is able to mentor. Also listed >>>> will be the list of mentored documents (and a count). >>>>=20 >>>> i) When a Directorate member is assigned as the Document >>>> mentor, the Routing Directorate Coordinator will update the >>>> wiki page and create a wiki page for the draft. >>>>=20 >>>> ii) When a Document Mentor provides a review, that should be >>>> stored in the draft's wiki page along with the resolutions. >>>>=20 >>>> iii) When the Document Mentor's final review at WGLC is done, >>>> the Document Mentor should move the draft to a list of >>>> "previously mentored documents" associated with their name. >>>> It is ideal to write up a summary of the document mentoring = experience. >>>>=20 >>>> c) Unmentored Documents: Drafts which have declined a document >>>> mentor should be listed on a wiki page. >>>>=20 >>>> d) For each WG's wiki, it'd be useful to have the list of drafts >>>> with their associated Document Mentors (or lack thereof) and the >>>> link to the draft's wiki page. >>>>=20 >>>> The Basic Process: >>>>=20 >>>> When a new WG draft is adopted, the WG chairs and the Routing >>>> Directorate Coordinators discuss and agree on possible Document >>>> Mentors (up to 3). Then the Routing Directorate Coordinator >>>> confirms with the Routing Directorate members about their >>>> availability and willingness to mentor this particular draft. Once >>>> one is selected, the Routing Directorate Coordinator updates the >>>> wiki and notifies the WG chairs and draft authors. >>>>=20 >>>> a) With the agreement of the ADs, a Document Mentor who is not a >>>> member of the Routing Directorate may be selected. >>>>=20 >>>> b) The WG chairs can, after consulting with the draft authors, >>>> decline to have a Document Mentor. >>>>=20 >>>> c) The Document Mentor should coordinate with the Document >>>> Shepherd for hand-off after WGLC. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 From nobody Mon Mar 31 07:19:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565361A6EEA; Mon, 31 Mar 2014 07:19:14 -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 SMFqW92WdvFy; Mon, 31 Mar 2014 07:19:03 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA91A0A1B; Mon, 31 Mar 2014 07:19:03 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so7639337yha.10 for ; Mon, 31 Mar 2014 07:19:00 -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=JLzchZma6zmgFNWA47+vPCm2u02xdUt27HAcbEvZ8AM=; b=qn4ai+1iSGj1S3kqIkjtTqH3OZ/4qCGAwyQW6aOw17DyVi5qQdff2SrQaUFlenBBa9 JiSmQu6avoFmpKTbHgn6hzTPmGRWgO6RIyJnoRLShiePxl9FcEuYpxGISVSwP4TfQHDM 1uTc1yEy9OlIkQIHohutTxT2S7jBjV18hkZm9KyVeV2kv8+cAKH1wnPp4mnq7VCWjg7c cOfAxHtOrUGev8fcxsKqw05Ryb8x86qsDpP781UtR2bOHI+/9+OwpzWAXaKthSrISv3D qC31iDC5T1dG+/Q3yvH1eyQQjn6RrZT939ojdXLXMExm7RXfDNO/w3Yl9II9Pz6saQWj asrQ== MIME-Version: 1.0 X-Received: by 10.236.199.78 with SMTP id w54mr2227680yhn.139.1396275540045; Mon, 31 Mar 2014 07:19:00 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 07:18:59 -0700 (PDT) In-Reply-To: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> Date: Mon, 31 Mar 2014 10:18:59 -0400 Message-ID: From: Alia Atlas To: Acee Lindem Content-Type: multipart/alternative; boundary=089e0158c41c92b54904f5e7bb4b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/0kuDjSFiHYJVn5dJQjzvTao3Z4w Cc: Adrian Farrel , Jamal Hadi Salim , Thomas Heide Clausen , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:19:14 -0000 --089e0158c41c92b54904f5e7bb4b Content-Type: text/plain; charset=ISO-8859-1 Acee, Absolutely, this would be doing more work. It would be doing it earlier in the draft life-cycle when there is a chance of improving or killing bad drafts that did make it past working group adoption. Having better drafts coming out out of WGLC seems to me to be a clear win - easier to understand, better technology, common issues and nits addressed, faster to process through the endgame (IETF Last Call, IESG, IANA, etc). As for current scale, there are 187 WG drafts in routing plus 27 is IESG processing. At the moment, the routing directorate is not highly loaded. Alia On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem wrote: > Hi Thomas, Jamal, and Adrian, > I agree with Jamal on scaling. There may not be an order of magnitude > difference between the number of drafts accepted as WG documents and those > that make it through WG last call but it is certainly some power of 2. > Hence, we'd be increasing our workload by 2 to 4 times just in shear > numbers without even taking into account the fact that the bad drafts will > take much more time than the ones making it through WG last call. > Thanks, > Acee > > > On Mar 31, 2014, at 9:12 AM, Thomas Clausen > wrote: > > > Jamal, > > > > On 31 Mar 2014, at 14:48, Jamal Hadi Salim wrote: > > > >> The only hole i see is your scale/workload numbers dont take into > >> consideration the fact that there could be a lot more spread than 200 > active > >> documents per year that are in between WG adoption to publication. > >> And that at times that process takes a little longer. > >> Jari's tools could provide some stats (and i could be therefore off), > but > >> to make my point i will handwave and say it is a magnitude more docs, > >> some of which a mentor is responsible for and some which are making > >> progress. > >> This means each of the 40 people is actively mentoring about 25 > documents > >> per year. And lets say 60 over 3 years. You will need a large number of > people > >> in the directorate to scale. > > > > Scalability is an issue in whatever we are designing in the IETF, to be > sure. But I think that various documents are very heterogenous in nature. > > > > Some documents would be written by people who really do not need a > mentor ("Come here, Ross Callon, so that this whippersnapper can tell you > how the IETF works - and Adrian, now, let me explain to you what a good RFC > looks like" -- that just doesn't seem plausible to happen). > > > > Other documents would probably need the occasional review, but mostly be > consensual and developed by a well engaged WG, so the "mentor" would be > mostly redundant, and just "be there" without doing much. > > > > A few documents would likely benefit from more continuing mentoring - > unexperienced IETFers as authors, but eager to learn the ropes. That's > actually the "good kind of effort" to spend, that's working on renewing the > future stock of RTG-DIR members and WG Chairs. I know that when I put pen > to paper for the first time in the IETF decades ago, I'd have appreciated > having had a mentor. > > > > Further, I predict that many documents would likely be rather bursty in > the efforts required. If I was to mentor a document, I'd probably want to > spend a good chunk of effort around WG adoption on reviews, discussions > with the authors, commenting, learning what the WG wants with it - but, > hopefully then it will drop to an occasional review (ideally, at least, > looking at the diff at each release), discussions on precise points and > potential pitfalls, and likely with another burst when the authors start > preparing for WGLC. > > > > I think that as long as the ADs are not mechanically dooling out > documents, but there's a human in the loop to whom we can say "Well, gee, I > may mentor just one document, but right now it's a full-time job to work > with the authors, could you ask Jamal to take thisone instead?" we'll do > alright. > > > >> And then there's handoff challenges. If i am mentoring a doc that is > >> not complete > >> before i let go ... > >> > > > > Worst case: think of the document taking over as "having just been > called for WG adoption", so provide a review, chat with the authors. Best > case, you have notes to hand over, or even sit down and have a beer with > whoever takes over after you. > > > > Anything more complicated than that? > > > > Thomas > > > >> > >> cheers, > >> jamal > >> > >> > >> > >> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel > wrote: > >>> Hi, > >>> > >>> One of the ideas to come out of the recent discussions is appointing a > mentor > >>> per document from the time it is adopted by a Routing Area working > group until > >>> it completes WG last call. > >>> > >>> This would be voluntary in two dimensions: > >>> - the WG chairs would need to deem that one would be beneficial > >>> - we would have to find someone from the Directorate willing to > >>> take on the document. > >>> > >>> We don't think that technology expertise is as useful in this as IETF > clue and > >>> general routing experience. > >>> > >>> So, to take this forward we would need: > >>> - WG chairs to say "Yes, we can see that that would have > >>> potential benefit > >>> - Directorate members to say "Yes, we could take on that > >>> additional work. > >>> > >>> Alia and I have put together some preliminary notes on how this would > all hang > >>> together. > >>> > >>> Your opinions and rotten fruit are solicited. > >>> > >>> Thanks, > >>> Adrian and Alia > >>> > >>> ========= > >>> > >>> Document Mentors in the Routing Area > >>> > >>> The Problems: > >>> > >>> a) Drafts get little review outside the working group and sometimes > inside > >>> the working group until after working group last call. At that point > it is > >>> often > >>> painful and costly to make meaningful improvements to the drafts. > >>> > >>> b) Authors may not know how or whom to ask for assistance or review > >>> (e.g., IANA section, Security Section, Operational and Management > >>> considerations, details of a protocol, etc. ). > >>> > >>> The Goals: > >>> > >>> a) Excellent and consistent review at WG adoption and before WG last > >>> call. > >>> > >>> b) Ability for prolonged discussion and problem-solving when the > >>> draft can still be easily enhanced. > >>> > >>> c) Reduced time to delivery of RFCs. > >>> > >>> d) Quality documents. > >>> > >>> The Solution: > >>> > >>> A per-document mentor who is a known neutral party to whom the > >>> authors can go for advice on: > >>> - how to write a section > >>> - specific issues that arise > >>> - ways to resolve conflicts. > >>> > >>> The document mentor also watches the progress of the document > >>> and gives advice and steerage. > >>> > >>> It is not assumed that every document will need or benefit from > >>> having a mentor. > >>> > >>> The Expected Workload: > >>> > >>> The routing directorate has approximately 40 people. If we assume > >>> that approximately 50 drafts pass WG adoption and a similar number > >>> pass WGLC each year, then the load is 2.5 documents per person > >>> per year. If we assume that there are about 200 WG drafts in the > >>> Routing Area and that they all have mentors, then each Routing > >>> Directorate member will have 5 drafts that she or he is mentoring. > >>> > >>> The Supporting Data Artefacts: > >>> > >>> a) As part of the Routing Area wiki, the areas of knowledge for > >>> each member of the Routing Directorate will be publicly specified. > >>> This is added to the wiki by the Routing Area Coordinators (or AD) > >>> when the member joins the Routing Directorate, updated by the > >>> member while he or she is on the Directorate, and updated by the > >>> Routing Area Coordinators (or AD) if and when the member's term > >>> renews. > >>> > >>> b) Document Mentor Availability and Assignments: As part of the > >>> Routing Area wiki, each Directorate member will specify the maximum > >>> number of documents that he or she is able to mentor. Also listed > >>> will be the list of mentored documents (and a count). > >>> > >>> i) When a Directorate member is assigned as the Document > >>> mentor, the Routing Directorate Coordinator will update the > >>> wiki page and create a wiki page for the draft. > >>> > >>> ii) When a Document Mentor provides a review, that should be > >>> stored in the draft's wiki page along with the resolutions. > >>> > >>> iii) When the Document Mentor's final review at WGLC is done, > >>> the Document Mentor should move the draft to a list of > >>> "previously mentored documents" associated with their name. > >>> It is ideal to write up a summary of the document mentoring > experience. > >>> > >>> c) Unmentored Documents: Drafts which have declined a document > >>> mentor should be listed on a wiki page. > >>> > >>> d) For each WG's wiki, it'd be useful to have the list of drafts > >>> with their associated Document Mentors (or lack thereof) and the > >>> link to the draft's wiki page. > >>> > >>> The Basic Process: > >>> > >>> When a new WG draft is adopted, the WG chairs and the Routing > >>> Directorate Coordinators discuss and agree on possible Document > >>> Mentors (up to 3). Then the Routing Directorate Coordinator > >>> confirms with the Routing Directorate members about their > >>> availability and willingness to mentor this particular draft. Once > >>> one is selected, the Routing Directorate Coordinator updates the > >>> wiki and notifies the WG chairs and draft authors. > >>> > >>> a) With the agreement of the ADs, a Document Mentor who is not a > >>> member of the Routing Directorate may be selected. > >>> > >>> b) The WG chairs can, after consulting with the draft authors, > >>> decline to have a Document Mentor. > >>> > >>> c) The Document Mentor should coordinate with the Document > >>> Shepherd for hand-off after WGLC. > >>> > >>> > >>> > >>> > >> > > > > --089e0158c41c92b54904f5e7bb4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Acee,

Absolutely, this would be doing m= ore work.  It would be doing it earlier in the draft life-cycle when t= here is a chance of improving or killing bad drafts that did make it past w= orking group adoption.   Having better drafts coming out out of W= GLC seems to me to be a clear win - easier to understand, better technology= , common issues and nits addressed, faster to process through the endgame (= IETF Last Call, IESG, IANA, etc).

As for current scale, there are 187 WG drafts in routin= g plus 27 is IESG processing.  At the moment, the routing directorate = is not highly loaded.   

Alia


On Mon, Mar 31, 2014 at 9:40 AM, Acee Li= ndem <acee.lindem@ericsson.com> wrote:
Hi Thomas, Jamal, and Adrian,
I agree with Jamal on scaling. There may not be an order of magnitude diffe= rence between the number of drafts accepted as WG documents and those that = make it through WG last call but it is certainly some power of 2. Hence, we= ’d be increasing our workload by 2 to 4 times just in shear numbers w= ithout even taking into account the fact that the bad drafts will take much= more time than the ones making it through WG last call.
Thanks,
Acee


On Mar 31, 2014, at 9:12 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:

> Jamal,
>
> On 31 Mar 2014, at 14:48, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>
>> The only hole i see is your scale/workload numbers dont take into<= br> >> consideration the fact that there could be a lot more spread than = 200 active
>> documents per year that are in between WG adoption to publication.=
>> And that at times that process takes a little longer.
>> Jari's tools could provide some stats (and i could be therefor= e off), but
>> to make my point  i will handwave and say it is a magnitude m= ore docs,
>> some of which a mentor is responsible for and some which are makin= g
>> progress.
>> This means each of the 40 people is actively mentoring about 25 do= cuments
>> per year. And lets say 60 over 3 years. You will need a large numb= er of people
>> in the directorate to scale.
>
> Scalability is an issue in whatever we are designing in the IETF, to b= e sure. But I think that various documents are very heterogenous in nature.=
>
> Some documents would be written by people who really do not need a men= tor ("Come here, Ross Callon, so that this whippersnapper can tell you= how the IETF works - and Adrian, now, let me explain to you what a good RF= C looks like" -- that just doesn't seem plausible to happen).
>
> Other documents would probably need the occasional review, but mostly = be consensual and developed by a well engaged WG, so the "mentor"= would be mostly redundant, and just "be there" without doing muc= h.
>
> A few documents would likely benefit from more continuing mentoring - = unexperienced IETFers as authors, but eager to learn the ropes. That's = actually the "good kind of effort" to spend, that's working o= n renewing the future stock of RTG-DIR members and WG Chairs. I know that w= hen I put pen to paper for the first time in the IETF decades ago, I'd = have appreciated having had a mentor.
>
> Further, I predict that many documents would likely be rather bursty i= n the efforts required. If I was to mentor a document, I'd probably wan= t to spend a good chunk of effort around WG adoption on reviews, discussion= s with the authors, commenting, learning what the WG wants with it - but, h= opefully then it will drop to an occasional review (ideally, at least, look= ing at the diff at each release), discussions on precise points and potenti= al pitfalls, and likely with another burst when the authors start preparing= for WGLC.
>
> I think that as long as the ADs are not mechanically dooling out docum= ents, but there's a human in the loop to whom we can say "Well, ge= e, I may mentor just one document, but right now it's a full-time job t= o work with the authors, could you ask Jamal to take thisone instead?"= we'll do alright.
>
>> And then there's handoff challenges. If i am mentoring a doc t= hat is
>> not complete
>> before i let go ...
>>
>
> Worst case: think of the document taking over as "having just bee= n called for WG adoption", so provide a review, chat with the authors.= Best case, you have notes to hand over, or even sit down and have a beer w= ith whoever takes over after you.
>
> Anything more complicated than that?
>
> Thomas
>
>>
>> cheers,
>> jamal
>>
>>
>>
>> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>> Hi,
>>>
>>> One of the ideas to come out of the recent discussions is appo= inting a mentor
>>> per document from the time it is adopted by a Routing Area wor= king group until
>>> it completes WG last call.
>>>
>>> This would be voluntary in two dimensions:
>>> - the WG chairs would need to deem that one would be beneficia= l
>>> - we would have to find someone from the Directorate willing t= o
>>>  take on the document.
>>>
>>> We don't think that technology expertise is as useful in t= his as IETF clue and
>>> general routing experience.
>>>
>>> So, to take this forward we would need:
>>> - WG chairs to say "Yes, we can see that that would have<= br> >>>  potential benefit
>>> - Directorate members to say "Yes, we could take on that<= br> >>> additional work.
>>>
>>> Alia and I have put together some preliminary notes on how thi= s would all hang
>>> together.
>>>
>>> Your opinions and rotten fruit are solicited.
>>>
>>> Thanks,
>>> Adrian and Alia
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> Document Mentors in the Routing Area
>>>
>>> The Problems:
>>>
>>> a) Drafts get little review outside the working group and some= times inside
>>> the working group until after working group last call. At that= point it is
>>> often
>>> painful and costly to make meaningful improvements to the draf= ts.
>>>
>>> b) Authors may not know how or whom to ask for assistance &nbs= p;or review
>>> (e.g., IANA section, Security Section, Operational and Managem= ent
>>> considerations, details of a protocol, etc. ).
>>>
>>> The Goals:
>>>
>>> a) Excellent and consistent review at WG adoption and before W= G last
>>> call.
>>>
>>> b) Ability for prolonged discussion and problem-solving when t= he
>>> draft can still be easily enhanced.
>>>
>>> c) Reduced time to delivery of RFCs.
>>>
>>> d) Quality documents.
>>>
>>> The Solution:
>>>
>>> A per-document mentor who is a known neutral party to whom the=
>>> authors can go for advice on:
>>> - how to write a section
>>> - specific issues that arise
>>> - ways to resolve conflicts.
>>>
>>> The document mentor also watches the progress of the document<= br> >>> and gives advice and steerage.
>>>
>>> It is not assumed that every document will need or benefit fro= m
>>> having a mentor.
>>>
>>> The Expected Workload:
>>>
>>>  The routing directorate has approximately 40 people. &nb= sp;If we assume
>>>  that approximately 50 drafts pass WG adoption and a simi= lar number
>>>  pass WGLC each year, then the load is 2.5 documents per = person
>>>  per year.  If we assume that there are about 200 WG= drafts in the
>>>  Routing Area and that they all have mentors, then each R= outing
>>>  Directorate member will have 5 drafts that she or he is = mentoring.
>>>
>>> The Supporting Data Artefacts:
>>>
>>>  a) As part of the Routing Area wiki, the areas of knowle= dge for
>>>  each member of the Routing Directorate will be publicly = specified.
>>>  This is added to the wiki by the Routing Area Coordinato= rs (or AD)
>>>  when the member joins the Routing Directorate, updated b= y the
>>>  member while he or she is on the Directorate, and update= d by the
>>>  Routing Area Coordinators (or AD) if and when the member= 's term
>>>  renews.
>>>
>>>  b) Document Mentor Availability and Assignments: As part= of the
>>>  Routing Area wiki, each Directorate member will specify = the maximum
>>>  number of documents that he or she is able to mentor. &n= bsp;Also listed
>>>  will be the list of mentored documents (and a count). >>>
>>>       i) When a Directorate member is assigned = as the Document
>>>       mentor, the Routing Directorate Coordinat= or will update the
>>>       wiki page and create a wiki page for the = draft.
>>>
>>>       ii) When a Document Mentor provides a rev= iew, that should be
>>>       stored in the draft's wiki page along= with the resolutions.
>>>
>>>       iii) When the Document Mentor's final= review at WGLC is done,
>>>       the Document Mentor should move the draft= to a list of
>>>       "previously mentored documents"= associated with their name.
>>>       It is ideal to write up a summary of the = document mentoring experience.
>>>
>>>  c) Unmentored Documents: Drafts which have declined a do= cument
>>>  mentor should be listed on a wiki page.
>>>
>>>  d) For each WG's wiki, it'd be useful to have th= e list of drafts
>>>  with their associated Document Mentors (or lack thereof)= and the
>>>  link to the draft's wiki page.
>>>
>>> The Basic Process:
>>>
>>> When a new WG draft is adopted, the WG chairs and the Routing<= br> >>> Directorate Coordinators discuss and agree on possible Documen= t
>>> Mentors (up to 3).  Then the Routing Directorate Coordina= tor
>>> confirms with the Routing Directorate members about their
>>> availability and willingness to mentor this particular draft. = Once
>>> one is selected, the Routing Directorate Coordinator updates t= he
>>> wiki and notifies the WG chairs and draft authors.
>>>
>>>    a) With the agreement of the ADs, a Document Ment= or who is not a
>>>    member of the Routing Directorate may be selected= .
>>>
>>>    b) The WG chairs can, after consulting with the d= raft authors,
>>>    decline to have a Document Mentor.
>>>
>>>    c) The Document Mentor should coordinate with the= Document
>>>    Shepherd for hand-off after WGLC.
>>>
>>>
>>>
>>>
>>
>


--089e0158c41c92b54904f5e7bb4b-- From nobody Mon Mar 31 07:21:14 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DFA1A087B; Mon, 31 Mar 2014 07:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 88uaKncaU587; Mon, 31 Mar 2014 07:21:10 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C14A1A0A1B; Mon, 31 Mar 2014 07:21:10 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (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 5EBFE1802AB4; Mon, 31 Mar 2014 16:21:06 +0200 (CEST) Message-ID: <533979D4.1050608@pi.nu> Date: Mon, 31 Mar 2014 16:21:08 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Acee Lindem , Thomas Heide Clausen References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/4hDumAGROBkaS6p6t8hz767fWi0 Cc: Adrian Farrel , Jamal Hadi Salim , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:21:14 -0000 Acee, et.al., I did not read our ADs as "applicable to all documents", but a tool to be used when beneficial. Anyhow, I'm a bit concerned about the increasing number of rules that pop up around documents. But so far I'll sit on my hands and hope that it either turns out to be beneficial, or wither away because it is not. /Loa On 2014-03-31 15:40, Acee Lindem wrote: > Hi Thomas, Jamal, and Adrian, > I agree with Jamal on scaling. There may not be an order of magnitude difference between the number of drafts accepted as WG documents and those that make it through WG last call but it is certainly some power of 2. Hence, we’d be increasing our workload by 2 to 4 times just in shear numbers without even taking into account the fact that the bad drafts will take much more time than the ones making it through WG last call. > Thanks, > Acee > > > On Mar 31, 2014, at 9:12 AM, Thomas Clausen wrote: > >> Jamal, >> >> On 31 Mar 2014, at 14:48, Jamal Hadi Salim wrote: >> >>> The only hole i see is your scale/workload numbers dont take into >>> consideration the fact that there could be a lot more spread than 200 active >>> documents per year that are in between WG adoption to publication. >>> And that at times that process takes a little longer. >>> Jari's tools could provide some stats (and i could be therefore off), but >>> to make my point i will handwave and say it is a magnitude more docs, >>> some of which a mentor is responsible for and some which are making >>> progress. >>> This means each of the 40 people is actively mentoring about 25 documents >>> per year. And lets say 60 over 3 years. You will need a large number of people >>> in the directorate to scale. >> >> Scalability is an issue in whatever we are designing in the IETF, to be sure. But I think that various documents are very heterogenous in nature. >> >> Some documents would be written by people who really do not need a mentor ("Come here, Ross Callon, so that this whippersnapper can tell you how the IETF works - and Adrian, now, let me explain to you what a good RFC looks like" -- that just doesn't seem plausible to happen). >> >> Other documents would probably need the occasional review, but mostly be consensual and developed by a well engaged WG, so the "mentor" would be mostly redundant, and just "be there" without doing much. >> >> A few documents would likely benefit from more continuing mentoring - unexperienced IETFers as authors, but eager to learn the ropes. That's actually the "good kind of effort" to spend, that's working on renewing the future stock of RTG-DIR members and WG Chairs. I know that when I put pen to paper for the first time in the IETF decades ago, I'd have appreciated having had a mentor. >> >> Further, I predict that many documents would likely be rather bursty in the efforts required. If I was to mentor a document, I'd probably want to spend a good chunk of effort around WG adoption on reviews, discussions with the authors, commenting, learning what the WG wants with it - but, hopefully then it will drop to an occasional review (ideally, at least, looking at the diff at each release), discussions on precise points and potential pitfalls, and likely with another burst when the authors start preparing for WGLC. >> >> I think that as long as the ADs are not mechanically dooling out documents, but there's a human in the loop to whom we can say "Well, gee, I may mentor just one document, but right now it's a full-time job to work with the authors, could you ask Jamal to take thisone instead?" we'll do alright. >> >>> And then there's handoff challenges. If i am mentoring a doc that is >>> not complete >>> before i let go ... >>> >> >> Worst case: think of the document taking over as "having just been called for WG adoption", so provide a review, chat with the authors. Best case, you have notes to hand over, or even sit down and have a beer with whoever takes over after you. >> >> Anything more complicated than that? >> >> Thomas >> >>> >>> cheers, >>> jamal >>> >>> >>> >>> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel wrote: >>>> Hi, >>>> >>>> One of the ideas to come out of the recent discussions is appointing a mentor >>>> per document from the time it is adopted by a Routing Area working group until >>>> it completes WG last call. >>>> >>>> This would be voluntary in two dimensions: >>>> - the WG chairs would need to deem that one would be beneficial >>>> - we would have to find someone from the Directorate willing to >>>> take on the document. >>>> >>>> We don't think that technology expertise is as useful in this as IETF clue and >>>> general routing experience. >>>> >>>> So, to take this forward we would need: >>>> - WG chairs to say "Yes, we can see that that would have >>>> potential benefit >>>> - Directorate members to say "Yes, we could take on that >>>> additional work. >>>> >>>> Alia and I have put together some preliminary notes on how this would all hang >>>> together. >>>> >>>> Your opinions and rotten fruit are solicited. >>>> >>>> Thanks, >>>> Adrian and Alia >>>> >>>> ========= >>>> >>>> Document Mentors in the Routing Area >>>> >>>> The Problems: >>>> >>>> a) Drafts get little review outside the working group and sometimes inside >>>> the working group until after working group last call. At that point it is >>>> often >>>> painful and costly to make meaningful improvements to the drafts. >>>> >>>> b) Authors may not know how or whom to ask for assistance or review >>>> (e.g., IANA section, Security Section, Operational and Management >>>> considerations, details of a protocol, etc. ). >>>> >>>> The Goals: >>>> >>>> a) Excellent and consistent review at WG adoption and before WG last >>>> call. >>>> >>>> b) Ability for prolonged discussion and problem-solving when the >>>> draft can still be easily enhanced. >>>> >>>> c) Reduced time to delivery of RFCs. >>>> >>>> d) Quality documents. >>>> >>>> The Solution: >>>> >>>> A per-document mentor who is a known neutral party to whom the >>>> authors can go for advice on: >>>> - how to write a section >>>> - specific issues that arise >>>> - ways to resolve conflicts. >>>> >>>> The document mentor also watches the progress of the document >>>> and gives advice and steerage. >>>> >>>> It is not assumed that every document will need or benefit from >>>> having a mentor. >>>> >>>> The Expected Workload: >>>> >>>> The routing directorate has approximately 40 people. If we assume >>>> that approximately 50 drafts pass WG adoption and a similar number >>>> pass WGLC each year, then the load is 2.5 documents per person >>>> per year. If we assume that there are about 200 WG drafts in the >>>> Routing Area and that they all have mentors, then each Routing >>>> Directorate member will have 5 drafts that she or he is mentoring. >>>> >>>> The Supporting Data Artefacts: >>>> >>>> a) As part of the Routing Area wiki, the areas of knowledge for >>>> each member of the Routing Directorate will be publicly specified. >>>> This is added to the wiki by the Routing Area Coordinators (or AD) >>>> when the member joins the Routing Directorate, updated by the >>>> member while he or she is on the Directorate, and updated by the >>>> Routing Area Coordinators (or AD) if and when the member's term >>>> renews. >>>> >>>> b) Document Mentor Availability and Assignments: As part of the >>>> Routing Area wiki, each Directorate member will specify the maximum >>>> number of documents that he or she is able to mentor. Also listed >>>> will be the list of mentored documents (and a count). >>>> >>>> i) When a Directorate member is assigned as the Document >>>> mentor, the Routing Directorate Coordinator will update the >>>> wiki page and create a wiki page for the draft. >>>> >>>> ii) When a Document Mentor provides a review, that should be >>>> stored in the draft's wiki page along with the resolutions. >>>> >>>> iii) When the Document Mentor's final review at WGLC is done, >>>> the Document Mentor should move the draft to a list of >>>> "previously mentored documents" associated with their name. >>>> It is ideal to write up a summary of the document mentoring experience. >>>> >>>> c) Unmentored Documents: Drafts which have declined a document >>>> mentor should be listed on a wiki page. >>>> >>>> d) For each WG's wiki, it'd be useful to have the list of drafts >>>> with their associated Document Mentors (or lack thereof) and the >>>> link to the draft's wiki page. >>>> >>>> The Basic Process: >>>> >>>> When a new WG draft is adopted, the WG chairs and the Routing >>>> Directorate Coordinators discuss and agree on possible Document >>>> Mentors (up to 3). Then the Routing Directorate Coordinator >>>> confirms with the Routing Directorate members about their >>>> availability and willingness to mentor this particular draft. Once >>>> one is selected, the Routing Directorate Coordinator updates the >>>> wiki and notifies the WG chairs and draft authors. >>>> >>>> a) With the agreement of the ADs, a Document Mentor who is not a >>>> member of the Routing Directorate may be selected. >>>> >>>> b) The WG chairs can, after consulting with the draft authors, >>>> decline to have a Document Mentor. >>>> >>>> c) The Document Mentor should coordinate with the Document >>>> Shepherd for hand-off after WGLC. >>>> >>>> >>>> >>>> >>> >> > -- 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 Mar 31 07:27:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959181A6EF6; Mon, 31 Mar 2014 07:27:05 -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 epNblfD5-HaJ; Mon, 31 Mar 2014 07:26:58 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 262E61A6EF3; Mon, 31 Mar 2014 07:26:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4D58B245AB4; Mon, 31 Mar 2014 07:26:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id D38BD245AA3; Mon, 31 Mar 2014 07:26:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <02c701cf4ceb$af62d870$0e288950$@riw.us> Date: Mon, 31 Mar 2014 16:26:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1105331A-C1D4-40D3-9EF6-CCC996E99632@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/x2JPn-96KRFhRvHBOJ_jrihqEx0 Cc: Adrian Farrel , rtg-chairs@ietf.org, "" , Jamal Hadi Salim Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:27:05 -0000 On 31 Mar 2014, at 16:15, Russ White wrote: >=20 >> My view of mentorship is skewed a little. There has to be a return on >> investment for the mentor. >=20 > This, IMHO, is the biggest blocker. While it "should be enough," to = know > that we're improving the quality of the IETF's output, it's probably = not. > Maybe add the mentor as "editor," or create a new "editor," type slot = in the > acks, or something like that?=20 >=20 > :-) >=20 > Russ Russ, often we do agree on things -- but in this case, Yikes..... ;) 1) Following the document authors development process is one thing. That = could be the "RTG Dir document mentor". 2) Following the document authors through the review process (IETF LC, = AD, IESG) is the job of the document shepherd. 3) Following the document through the RFC Editor process is the job of = the authors (and perhaps the ADs, in case of non-editorial edits). Sticking the "mentor" onto a document as an editor/co-author would also = require the "mentor" to be part of 2) and 3) -- that seems to scale even = less well :) Also..... Sticking the "mentor" onto a document as an editor/co-author is (imo) = actually intellectually dishonest, and something I'd much ask to not = have done to me, if I was a mentor of a doc. My contributions may be = simply "process guidance" and I should not get any credit for the clever = algorithm/protocol/design that somebody else came up with (And, = conversely, if by accident I was to come up with something clever, I'd = want credit for that - not to share it with somebody just giving process = advice). And also, I may be assigned a document which I profoundly disagree with, = or which my employer disagrees with, and having my name on it may be a = bad career move..... Thomas= From nobody Mon Mar 31 07:39:35 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9D01A6F2B; Mon, 31 Mar 2014 07:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 rPwhAwZ0bpcb; Mon, 31 Mar 2014 07:39:28 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC521A6F28; Mon, 31 Mar 2014 07:39:28 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:61315 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WUdMw-0008Bk-VG; Mon, 31 Mar 2014 14:39:23 +0000 From: "Russ White" To: "'Thomas Clausen'" References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> <1105331A-C1D4-40D3-9EF6-CCC996E99632@thomasclausen.org> In-Reply-To: <1105331A-C1D4-40D3-9EF6-CCC996E99632@thomasclausen.org> Date: Mon, 31 Mar 2014 10:39:21 -0400 Message-ID: <030d01cf4cef$01da9270$058fb750$@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: AQLRW8MC2jlgo4YShVQKqZSaQzM51wDaXBXyAmj3F30Bsi0auAH32ulCAoCn3LiYq7UcYA== 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/rtg-dir/CxyNeudtramgpcMa0z5xsdlbAw4 Cc: 'Adrian Farrel' , 'Jamal Hadi Salim' , rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:39:32 -0000 > > This, IMHO, is the biggest blocker. While it "should be enough," to > > know that we're improving the quality of the IETF's output, it's probably > not. > > Maybe add the mentor as "editor," or create a new "editor," type slot > > in the acks, or something like that? > Russ, often we do agree on things -- but in this case, Yikes..... ;) Just throwing ideas out. :-) > 1) Following the document authors development process is one thing. That > could be the "RTG Dir document mentor". Sure... This is what I'd advocate -- maybe some new "thing" we can put on drafts beyond the author/co-author slot. "Editor," seems like a good point of insertion, since that's really what we're mostly talking about (right? -- or maybe not?) -- someone who helps get the draft into some sort of shape for publication, rather than someone who materially contributes to the content of the draft itself (in technical terms). IE, I don't expect my editors to actually contribute content, but rather to help me with places where I've been unclear, or in asking questions that I've not answered, so I can make certain the text covers everything that needs to be covered. To some degree, I'm gravitating towards a "book editor" model, since that's what I'm most familiar with. > 2) Following the document authors through the review process (IETF LC, AD, > IESG) is the job of the document shepherd. > > 3) Following the document through the RFC Editor process is the job of the > authors (and perhaps the ADs, in case of non-editorial edits). > Sticking the "mentor" onto a document as an editor/co-author would also > require the "mentor" to be part of 2) and 3) -- that seems to scale even less > well :) Agreed on these points. > Sticking the "mentor" onto a document as an editor/co-author is (imo) > actually intellectually dishonest, and something I'd much ask to not have > done to me, if I was a mentor of a doc. Which is precisely why I don't think this is the right thing to do... :-) Russ From nobody Mon Mar 31 07:40:44 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B901A6F2A; Mon, 31 Mar 2014 07:40:41 -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 jGL3Yu-hcWFd; Mon, 31 Mar 2014 07:40:39 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C61931A0A24; Mon, 31 Mar 2014 07:40:38 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so6302059ykp.1 for ; Mon, 31 Mar 2014 07:40:35 -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=NCxgK/YGA9DgbjIdwu1ScAYSl/jdMN76lJFDmRv7Z8Y=; b=Mr7mdKjvluVYLmYSZ1rr22gVDfWsSbaePIXl72zpd5W/eUmuKPCH/zUlemBrLRxEaJ Ez1iFsnQv4Tn0BkgQtRlqm1DLHJrXlIYUOhzQ3HjIHkhVYzVSjCk1rQf779h1C4TFKhF yguiYo+8cUxf4FEx1xIz9wFrG8hxqR+CK81LiJtP33ckLB+M9+d3y8ezMdVe6qtOz5dn KoSjJ9s+97Av2Hd2mFEOlorj3LWFaJRx7LU91KXRLaWGcBR5E05UP3Kex2Uh46WDIeMh zokwT/yIP5/xOYjLQpN1IrgZ2S5pSwj2j33sarIl+EGrxC4RU0M6wEukqb3pDyW1A5gn +FyA== MIME-Version: 1.0 X-Received: by 10.236.22.74 with SMTP id s50mr2593337yhs.109.1396276835548; Mon, 31 Mar 2014 07:40:35 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 07:40:35 -0700 (PDT) In-Reply-To: <02c701cf4ceb$af62d870$0e288950$@riw.us> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> Date: Mon, 31 Mar 2014 10:40:35 -0400 Message-ID: From: Alia Atlas To: Russ White Content-Type: multipart/alternative; boundary=e89a8f646df3ca812004f5e8086f Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/LOeePblCoMD_dAeU1gtGE9_IiF4 Cc: Adrian Farrel , Thomas Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , Jamal Hadi Salim Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:40:42 -0000 --e89a8f646df3ca812004f5e8086f Content-Type: text/plain; charset=ISO-8859-1 Jamal and Russ, We are not talking about assigning random people as document mentors. We are discussing having members of the Routing Directorate do this. These are people who have agreed to spend some of their time doing reviews and helping support the IETF and the routing area. If someone does not have cycles or can only mentor a certain number of documents, that can be articulated. I do see the role of editor or author as being completely separated from a document mentor. There is no way for the document mentor to be or be perceived as neutral if the document mentor is a co-author. As far as benefits to the directorate member, presumably they see some good reasons to have agreed. Professional networking relationships, broadening ones knowledge, helping support the IETF so that it continues to be a healthy organization, etc. That said - clearly having document mentors is a way of trying to address the problems of inadequate review and difficulty in actively improving the document when changes can be made. If we kill even 1 in 2 WG drafts, that is not something that I've seen... Regards, Alia On Mon, Mar 31, 2014 at 10:15 AM, Russ White wrote: > > > My view of mentorship is skewed a little. There has to be a return on > > investment for the mentor. > > This, IMHO, is the biggest blocker. While it "should be enough," to know > that we're improving the quality of the IETF's output, it's probably not. > Maybe add the mentor as "editor," or create a new "editor," type slot in > the > acks, or something like that? > > :-) > > Russ > > --e89a8f646df3ca812004f5e8086f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Jamal and Russ,

We are not talking abou= t assigning random people as document mentors. =A0 We are discussing having= members of the Routing Directorate do this. =A0These are people who have a= greed to spend some of their time doing reviews and helping support the IET= F and the routing area. =A0If someone does not have cycles or can only ment= or a certain number of documents, that can be articulated.

I do see the role of editor or author as being complete= ly separated from a document mentor. =A0There is no way for the document me= ntor to be or be perceived as neutral if the document mentor is a co-author= .

As far as benefits to the directorate member, presumabl= y they see some good reasons to have agreed. =A0 Professional networking re= lationships, broadening ones knowledge, helping support the IETF so that it= continues to be a healthy organization, etc.

That said - clearly having document mentors is a way of= trying to address the problems of inadequate review and difficulty in acti= vely improving the document when changes can be made. =A0If we kill even 1 = in 2 WG drafts, that is not something that I've seen...

Regards,
Alia


On Mon, Mar 31, 2014 at 10:15 AM,= Russ White <russw@riw.us> wrote:

> My view of mentorship is skewed a little. There has to be a return on<= br> > investment for the mentor.

This, IMHO, is the biggest blocker. While it "should be enough,&= quot; to know
that we're improving the quality of the IETF's output, it's pro= bably not.
Maybe add the mentor as "editor," or create a new "editor,&q= uot; type slot in the
acks, or something like that?

:-)

Russ


--e89a8f646df3ca812004f5e8086f-- From nobody Mon Mar 31 07:41:32 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780C81A6F2D; Mon, 31 Mar 2014 07:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-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 wzltUjA6TMm6; Mon, 31 Mar 2014 07:41:28 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 297FC1A6F29; Mon, 31 Mar 2014 07:41:28 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:61373 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WUdOs-0008DM-Dh; Mon, 31 Mar 2014 14:41:22 +0000 From: "Russ White" To: "'Thomas Clausen'" References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> <1105331A-C1D4-40D3-9EF6-CCC996E99632@thomasclausen.org> <030d01cf4cef$01da9270$058fb750$@riw.us> In-Reply-To: <030d01cf4cef$01da9270$058fb750$@riw.us> Date: Mon, 31 Mar 2014 10:41:21 -0400 Message-ID: <032201cf4cef$490df560$db29e020$@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: AQLRW8MC2jlgo4YShVQKqZSaQzM51wDaXBXyAmj3F30Bsi0auAH32ulCAoCn3LgB+6Lzypib2XzQ 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/rtg-dir/XJJXkfVxS4GWIiX9IIDpORlHi5k Cc: 'Adrian Farrel' , rtg-chairs@ietf.org, rtg-dir@ietf.org, 'Jamal Hadi Salim' Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:41:29 -0000 > To some degree, I'm gravitating towards a "book editor" model, since that's > what I'm most familiar with. I'm not saying this is the right model, btw, just the one I'm familiar with, so it's the easiest framework for me to put this discussion in to. I may have the wrong framework entirely, and so my thinking might be completely wrong. :-) Russ From nobody Mon Mar 31 07:45:20 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73111A6F22; Mon, 31 Mar 2014 07:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-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 p0N9YFrzlrRL; Mon, 31 Mar 2014 07:45:17 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2381A6F05; Mon, 31 Mar 2014 07:45:17 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:61471 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WUdSa-0008FQ-7Z; Mon, 31 Mar 2014 14:45:12 +0000 From: "Russ White" To: "'Alia Atlas'" References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> In-Reply-To: Date: Mon, 31 Mar 2014 10:45:10 -0400 Message-ID: <032901cf4cef$d207e060$7617a120$@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: AQLRW8MC2jlgo4YShVQKqZSaQzM51wDaXBXyAmj3F30Bsi0auAH32ulCAk9p6hKYrUDpAA== 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/rtg-dir/qF3c-CjZYb-zubvtU46fCEPL77I Cc: 'Adrian Farrel' , 'Thomas Clausen' , rtg-chairs@ietf.org, rtg-dir@ietf.org, 'Jamal Hadi Salim' Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:45:19 -0000 > We are not talking about assigning random people as document mentors. Of course... > I do see the role of editor or author as being completely separated from a > document mentor. There is no way for the document mentor to be or be > perceived as neutral if the document mentor is a co-author. I think the problem here might be the terminology -- I probably shouldn't have chosen to say, "editor," since that actually already has a specific meaning within the IETF context. But I'm not certain what else you could call this role -- "mentor," doesn't seem right, as it seems to imply something on a more personal level. "Shepherd," is already taken. "Editor" might cause confusion... Maybe "Copy Editor," or "Copyreader," or some such (those seem to be the only suggestions from my large green creature wandering through the woods never using one word when two or more will do -- thesaurus). > As far as benefits to the directorate member, presumably they see some > good reasons to have agreed. Professional networking relationships, > broadening ones knowledge, helping support the IETF so that it continues to > be a healthy organization, etc. Sure -- and a lot of folks would volunteer silently just for these reasons. OTOH, giving official recognition of some type would help bring people out of the woodwork, and also provide a traction point for people who want this sort of help with their drafts. :-) Russ From nobody Mon Mar 31 07:51:34 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12BB1A6EEA; Mon, 31 Mar 2014 07:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 5LPa0hQafUmT; Mon, 31 Mar 2014 07:51:31 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAB71A6EDB; Mon, 31 Mar 2014 07:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5630; q=dns/txt; s=iport; t=1396277488; x=1397487088; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i1UKPPXJJaHcITvT225FtSqpgBbo23YRQRG6K0E2LEc=; b=KMJekCofO4fgCm9AKMCqMTrw7cCa2RpFORCbPD5ew4oxC9cJlBVaBQGL k9LhiEGOMYmqD+ERNhEE8n1JSz0z05P/xLpJA8D+wXkNxv8fX3bdywEsw fG7t6B6JDk7uVF0tX3J6fu64NXydtTeWzNYHUtV0XihMp5X5rjrtcNbbo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFALF/OVOtJV2Y/2dsb2JhbABZgkJEgRLDF4EfFnSCJgEBBHkQAgEIPwcyFBEBAQQOBYd50FgXjn8HgySBFASYTpI1gzCCKw X-IronPort-AV: E=Sophos; i="4.97,766,1389744000"; d="scan'208,217"; a="31711885" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 31 Mar 2014 14:51:28 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2VEpSIx015638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 14:51:28 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 09:51:27 -0500 From: "Carlos Pignataro (cpignata)" To: Adrian Farrel Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QAQC18A Date: Mon, 31 Mar 2014 14:51:26 +0000 Message-ID: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> In-Reply-To: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.219.78] Content-Type: multipart/alternative; boundary="_000_F648DC4861344ECFB7E45C4235B88A25ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/_N-ijBoKTBVy4AIZ3khGW-p071k Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:51:33 -0000 --_000_F648DC4861344ECFB7E45C4235B88A25ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Mar 31, 2014, at 2:12 PM, Adrian Farrel > wrote: So, to take this forward we would need: - WG chairs to say "Yes, we can see that that would have potential benefit - Directorate members to say "Yes, we could take on that additional work. I think it is a fantastic idea -- arguably it is front-loading some of the = collective workload, as better documents should be produced to be reviewed = for others to review later. I think the aded workload is worth it. Thanks, Carlos. --_000_F648DC4861344ECFB7E45C4235B88A25ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6614206B986FA3418F15E08A4D80B8B5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Mar 31, 2014, at 2:12 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
 &nb= sp;potential benefit
- Directorate members to say "Yes, we could take on that
 add= itional work.

I think it is a fantastic idea -- arguably it is front-loading some of= the collective workload, as better documents should be produced to be revi= ewed for others to review later.

I think the aded workload is worth it.

Thanks,

Carlos.
--_000_F648DC4861344ECFB7E45C4235B88A25ciscocom_-- From nobody Mon Mar 31 07:54:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6961A0849; Mon, 31 Mar 2014 07:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 jvRiV5wlvcIK; Mon, 31 Mar 2014 07:54:53 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 195041A0833; Mon, 31 Mar 2014 07:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=536; q=dns/txt; s=iport; t=1396277690; x=1397487290; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ssIg/nlXhnOxdMKAj/pbE28mbcz/UvLkZ8kTZ8WmX6s=; b=PK33AB+9LUeZFznv6HlTa+SjH9QzxJhju/PHZFCJh5FEoJQMiGGUPXRv TuyBpYVhZQCU5Ypu+QmNB+8G2ub6oW4RMRTzHC00BQnREfZLkV3/tq37m JaBP8DcoeWiWXw0OE2rCGJSvgev1HM5Jx0y1vIpWJnKeHdIX8ap3HS73z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAFmAOVOtJV2a/2dsb2JhbABZgwaBEsMXgR8WdIIlAQEBAwE6PxACAQg2EDIlAQEEDgUUh10I0FgXjkwzB4MkgRQBA5hOkjWDMIIr X-IronPort-AV: E=Sophos;i="4.97,766,1389744000"; d="scan'208";a="31701353" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 31 Mar 2014 14:54:49 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VEsnwP014284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 14:54:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 09:54:49 -0500 From: "Carlos Pignataro (cpignata)" To: Russ White Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QALw2SAAADXBgAAAVMmAAAA3IoAAAFV1QA= Date: Mon, 31 Mar 2014 14:54:49 +0000 Message-ID: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> In-Reply-To: <02c701cf4ceb$af62d870$0e288950$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.219.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <7C688056B160F14AB85320809489FD08@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/uflMFCKfR_gy7TMyp7uCrQcpkoQ Cc: Adrian Farrel , Thomas Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , Jamal Hadi Salim Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 14:54:54 -0000 On Mar 31, 2014, at 4:15 PM, Russ White wrote: >=20 >> My view of mentorship is skewed a little. There has to be a return on >> investment for the mentor. Giving back to the community? >=20 > This, IMHO, is the biggest blocker. While it "should be enough," to know > that we're improving the quality of the IETF's output, it's probably not. > Maybe add the mentor as "editor," or create a new "editor," type slot in = the > acks, or something like that?=20 >=20 > :-) >=20 > Russ >=20 Carlos.= From nobody Mon Mar 31 08:25:05 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81561A6EDC; Mon, 31 Mar 2014 08:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, T_RP_MATCHES_RCVD=-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 E56_3RiRBkir; Mon, 31 Mar 2014 08:25:00 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 260661A0884; Mon, 31 Mar 2014 08:25:00 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:64847 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WUe50-0000DF-7f; Mon, 31 Mar 2014 15:24:54 +0000 From: "Russ White" To: "'Carlos Pignataro \(cpignata\)'" References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> In-Reply-To: Date: Mon, 31 Mar 2014 11:24:52 -0400 Message-ID: <04c101cf4cf5$5dce8db0$196ba910$@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: AQLRW8MC2jlgo4YShVQKqZSaQzM51wDaXBXyAmj3F30Bsi0auAH32ulCAquNUdSYqmuGgA== 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/rtg-dir/D3gvjVasJ9myGZM_IZH830HUnHc Cc: 'Adrian Farrel' , 'Thomas Clausen' , rtg-chairs@ietf.org, rtg-dir@ietf.org, 'Jamal Hadi Salim' Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:25:02 -0000 > >> My view of mentorship is skewed a little. There has to be a return on > >> investment for the mentor. > > Giving back to the community? This will work for some folks, but not for others. Some folks have to justify time spent through their jobs, etc.; having some way to ack folks who play this role would be helpful. :-) Russ From nobody Mon Mar 31 08:32:05 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5071A6F24; Mon, 31 Mar 2014 08:32:02 -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 771TCqqgrZTP; Mon, 31 Mar 2014 08:31:59 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 49BCA1A0549; Mon, 31 Mar 2014 08:31:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6E76C2412A7; Mon, 31 Mar 2014 08:31:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 904AB240182; Mon, 31 Mar 2014 08:31:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <04c101cf4cf5$5dce8db0$196ba910$@riw.us> Date: Mon, 31 Mar 2014 17:31:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <02E6CC26-D9AC-4ACE-BA7C-949B011EF47E@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> <04c101cf4cf5$5dce8db0$196ba910$@riw.us> To: Russ White X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/6le_W5Jofx7UVD_cbJVVQhUxo20 Cc: "Carlos Pignataro \(cpignata\)" , Jamal Hadi Salim , rtg-chairs@ietf.org, "" , Adrian Farrel Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:32:02 -0000 On 31 Mar 2014, at 17:24, Russ White wrote: >=20 >>>> My view of mentorship is skewed a little. There has to be a return = on >>>> investment for the mentor. >>=20 >> Giving back to the community? >=20 > This will work for some folks, but not for others. Some folks have to > justify time spent through their jobs, etc.; having some way to ack = folks > who play this role would be helpful. >=20 I think that I have vague memories of a section in some documents, = titled "Acknowledgements". Might that be a place for the authors to = express gratitude (at their leisure) to the mentor?=20 I firmly believe that authors will know when to say "Special thanks to = Russ White for his unfaltering support in seeing this document = successfully from WG adoption to publication, and for providing strong = guidance on how to best deal with ....", if indeed Russ White has been = helpful (even, if he wasn't an official mentor). On the other hand, I also firmly believe that no author should be = obligated to say "Special thanks to Thomas Clausen" if, in fact, all = that nefarious Thomas Clausen has done has been to make fun of document = typos, just because he was the assigned official mentor.... From nobody Mon Mar 31 08:40:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AA51A0A70; Mon, 31 Mar 2014 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 70zpmwzQgDLu; Mon, 31 Mar 2014 08:39:53 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id CADB61A0A6F; Mon, 31 Mar 2014 08:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7253; q=dns/txt; s=iport; t=1396280390; x=1397489990; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uOOig9JyCstYucTBhkVqueijZKrBb0pFjRNLoNjafDw=; b=VaytiTzgCWAhWHA2M4xEWpFiQZ7N3JoejoccDi3zzrtcPlfyDtafogp+ QmpNFLgYn+TwTVYh9ip9DKUYW13sRFzEYcU8GUyLvTP6r753uHcFimCqO 3f0aLb50YP+FcuMR6Z8+FaTnnQPoKI53p/VxvanH50hEvP9c+VFUbrbVh k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFADCLOVOtJA2I/2dsb2JhbABZgwaBEsMXgSAWdIIlAQEBAwE6MRMHBAIBCBEEAQELFAkHMhQJCAEBBAESCBOHVgjQWxeOTjgGgx6BFASrA4Mwgis X-IronPort-AV: E=Sophos;i="4.97,766,1389744000"; d="scan'208";a="31713919" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 31 Mar 2014 15:39:49 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VFdnwq019876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 15:39:49 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 10:39:49 -0500 From: "Les Ginsberg (ginsberg)" To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QAFwtIQ Date: Mon, 31 Mar 2014 15:39:48 +0000 Message-ID: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> In-Reply-To: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/avgXCXbgCVu8JbRm65d2XdRseS4 Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:39:55 -0000 The way I read what is proposed below is that all documents will be assigne= d a mentor. Perhaps that is not what you intended - but it does seem to rea= d that way. And as others who have replied to this have suggested that does= n't make sense for all documents and doesn't scale well. Also, the stated p= rocess introduces mentoring AFTER a document is adopted as a WG item. IMHO = this is too late. What I would suggest is that there become three options available for a WG = to choose when a document is proposed as a WG item: 1)Accept 2)Reject 3)Resubmit after mentoring The third category is reserved for documents which the WG feels have an ide= a/solution which might be worth the WG group's time, but the current "quali= ty" of the document is such that meaningful discussion would be hindered. The authors are free to reject the offer of mentoring in which case the doc= ument is rejected. This limits the time/effort on the part of the mentors to a smaller number = of documents and only for ones that are actually worth the time. Also, it m= eans the time of the entire WG is not wasted on discussions that might be u= nnecessary if the draft presentation were improved.=20 That said, the danger I see here is that in some cases it will be very hard= for a mentor to provide meaningful feedback without also commenting on the= guts of the solution. If the only issue is "grammar", then not a concern. = But I think what we are trying to address may go beyond simply editorial/gr= ammatical issues in some cases and then it is not clear to me how one separ= ates "mentoring" from "authorship".=20 Les > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farre= l > Sent: Monday, March 31, 2014 5:12 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: [RTG-DIR] Document Mentors >=20 > Hi, >=20 > One of the ideas to come out of the recent discussions is appointing a me= ntor > per document from the time it is adopted by a Routing Area working group > until > it completes WG last call. >=20 > This would be voluntary in two dimensions: > - the WG chairs would need to deem that one would be beneficial > - we would have to find someone from the Directorate willing to > take on the document. >=20 > We don't think that technology expertise is as useful in this as IETF clu= e > and > general routing experience. >=20 > So, to take this forward we would need: > - WG chairs to say "Yes, we can see that that would have > potential benefit > - Directorate members to say "Yes, we could take on that > additional work. >=20 > Alia and I have put together some preliminary notes on how this would all > hang > together. >=20 > Your opinions and rotten fruit are solicited. >=20 > Thanks, > Adrian and Alia >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Document Mentors in the Routing Area >=20 > The Problems: >=20 > a) Drafts get little review outside the working group and sometimes ins= ide > the working group until after working group last call. At that point it= is > often > painful and costly to make meaningful improvements to the drafts. >=20 > b) Authors may not know how or whom to ask for assistance or review > (e.g., IANA section, Security Section, Operational and Management > considerations, details of a protocol, etc. ). >=20 > The Goals: >=20 > a) Excellent and consistent review at WG adoption and before WG last > call. >=20 > b) Ability for prolonged discussion and problem-solving when the > draft can still be easily enhanced. >=20 > c) Reduced time to delivery of RFCs. >=20 > d) Quality documents. >=20 > The Solution: >=20 > A per-document mentor who is a known neutral party to whom the > authors can go for advice on: > - how to write a section > - specific issues that arise > - ways to resolve conflicts. >=20 > The document mentor also watches the progress of the document > and gives advice and steerage. >=20 > It is not assumed that every document will need or benefit from > having a mentor. >=20 > The Expected Workload: >=20 > The routing directorate has approximately 40 people. If we assume > that approximately 50 drafts pass WG adoption and a similar number > pass WGLC each year, then the load is 2.5 documents per person > per year. If we assume that there are about 200 WG drafts in the > Routing Area and that they all have mentors, then each Routing > Directorate member will have 5 drafts that she or he is mentoring. >=20 > The Supporting Data Artefacts: >=20 > a) As part of the Routing Area wiki, the areas of knowledge for > each member of the Routing Directorate will be publicly specified. > This is added to the wiki by the Routing Area Coordinators (or AD) > when the member joins the Routing Directorate, updated by the > member while he or she is on the Directorate, and updated by the > Routing Area Coordinators (or AD) if and when the member's term > renews. >=20 > b) Document Mentor Availability and Assignments: As part of the > Routing Area wiki, each Directorate member will specify the maximum > number of documents that he or she is able to mentor. Also listed > will be the list of mentored documents (and a count). >=20 > i) When a Directorate member is assigned as the Document > mentor, the Routing Directorate Coordinator will update the > wiki page and create a wiki page for the draft. >=20 > ii) When a Document Mentor provides a review, that should be > stored in the draft's wiki page along with the resolutions. >=20 > iii) When the Document Mentor's final review at WGLC is done, > the Document Mentor should move the draft to a list of > "previously mentored documents" associated with their name. > It is ideal to write up a summary of the document mentoring > experience. >=20 > c) Unmentored Documents: Drafts which have declined a document > mentor should be listed on a wiki page. >=20 > d) For each WG's wiki, it'd be useful to have the list of drafts > with their associated Document Mentors (or lack thereof) and the > link to the draft's wiki page. >=20 > The Basic Process: >=20 > When a new WG draft is adopted, the WG chairs and the Routing > Directorate Coordinators discuss and agree on possible Document > Mentors (up to 3). Then the Routing Directorate Coordinator > confirms with the Routing Directorate members about their > availability and willingness to mentor this particular draft. Once > one is selected, the Routing Directorate Coordinator updates the > wiki and notifies the WG chairs and draft authors. >=20 > a) With the agreement of the ADs, a Document Mentor who is not a > member of the Routing Directorate may be selected. >=20 > b) The WG chairs can, after consulting with the draft authors, > decline to have a Document Mentor. >=20 > c) The Document Mentor should coordinate with the Document > Shepherd for hand-off after WGLC. >=20 >=20 >=20 From nobody Mon Mar 31 08:40:09 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE68F1A6F21; Mon, 31 Mar 2014 08:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.083 X-Spam-Level: X-Spam-Status: No, score=-97.083 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 Xa6MeWGTSwUn; Mon, 31 Mar 2014 08:40:03 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 125931A6F11; Mon, 31 Mar 2014 08:40:02 -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 s2VFdwIZ008522; Mon, 31 Mar 2014 16:39:58 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VFduVZ008469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 16:39:58 +0100 From: "Adrian Farrel" To: , Date: Mon, 31 Mar 2014 16:39:54 +0100 Message-ID: <01c501cf4cf7$7938c370$6baa4a50$@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: Ac9M93UmFPa+gFhmQEeWzCw9poDduA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20602.000 X-TM-AS-Result: No--9.280-10.0-31-10 X-imss-scan-details: No--9.280-10.0-31-10 X-TMASE-MatchedRID: C9LEXEN5+WI2ZY2CIpwed8rT39PoDNtWfiuvKi9huaaInvV8Dy0ZaFoG k1xo9dm6weVBQN3YxDGZxtOEJRkgHiVqTewNlt0efuyIS1ZjfrsD1SED8QyvA3RBu8vg+6OQq8k 2QEqE4yUx+pdcsuckRzlxJCBnFBJP0H/zLeBgX2+n1yJegn+lazORfNQuKM+x47E6rstCUYvqv1 NCtNKuKTObFBEnNWjnxusUM2si5Bglr4UAbUFME9YGsi8PEW5DxdIDNApeqSsPpGoR1th3nrsDT C3Ikufr1JHB1JT+1hWKIiL3TnPeKP4a/ieYcSSRqbg9uWhLYLd9LQinZ4QefJacqsSFIP2UyeMt MD9QOgDGlDvsLUDW2o6HM5rqDwqtVvN7O0JkI8ka1/YGL1SVWXX4RVSVz4MwIC0Ru8GjT7JytVj MeAfr+w== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/cOFXtf6LOvtgVPIAShEsOpgZWT0 Subject: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:40:05 -0000 To answer two concerns in one email: Yes, we might have the scaling numbers wrong. I suspect that only about half of the documents would end up with a mentor. Alia (I think - but she can comment) would like a higher number. The number of documents we need to worry about is the number of WG documents across the Routing Area at any one time. Alia has counted this as 187+27. I make that 200 :-) The Directorate is currently 40 people. That means between 2.5 and 5 documents per person. 5 seems too many, but some people might want to take on that sort of load while others will not. We do not know how much effort will be involved. I would guess 3 detailed reviews over the course of the document, reviews of a few diffs, and some email exchanges. As the load ramps up, and according to people's willingness to participate we might: - declare the project a failure - increase the size of the Directorate - see that everything is cool. I do note that several Directorate members said that they wished they got more work from the Directorate, so at least some of you want something else to do. Not sure if this is it :-) Which takes me to "rewards". What reward does a Directorate member get today? I think that anyone in the Directorate who participates in this scheme could easily expect to double the reward. And lastly, is this new process and rules? Absolutely not. This is just a way to inject resource into documents and help the authors/WGs to deliver stuff that is useful and works. Does a WG have to halt processing while a mentor is found? No. A mentor is just something that might happen in parallel. Does a WG have to pay attention to what a mentor says? Yes. But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events. A From nobody Mon Mar 31 08:40:54 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18C81A6EE6; Mon, 31 Mar 2014 08:40:51 -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 tCyH4wx__vS2; Mon, 31 Mar 2014 08:40:49 -0700 (PDT) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AF4DD1A0862; Mon, 31 Mar 2014 08:40:49 -0700 (PDT) Received: by mail-yk0-f175.google.com with SMTP id 131so6329259ykp.34 for ; Mon, 31 Mar 2014 08:40:46 -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=W293H9QGj53UGWJbRD2Wh9KGW5RaIGgE18TRqbZfUA4=; b=Dy3KPsNVY+NQG6jqzH24/fdoIyIhKn/OfIoMK2ToMYsDGiG8RA5awUl5cDoJr8LPs5 l0WQdlu2BVVWpDTO+M5XvrE3OwSbfwit34GWX7B4zLVLnfrK8dfOSC42vJVZTh04JNyM o3D1KuOLLsF5hva7Dlqha4Izi1kwrfsvch1UzUTEghrLo5JP2o9Ev3nA6xiHR2hjSuMc pJUxS+KTIzGoYDSvvDzokdTAD8kNTyCu9Z81QEO8qHmJCbzbzcWzyfKFXZoorLbbvCsB 2Y2tXSCSUpWO7YnV4hlwHt3n2kXso1h/lSGcYZYkd/E9ZAwVPfp6dLKU8S67bG7I/0BE a80g== MIME-Version: 1.0 X-Received: by 10.236.138.73 with SMTP id z49mr2534694yhi.152.1396280446473; Mon, 31 Mar 2014 08:40:46 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 08:40:46 -0700 (PDT) In-Reply-To: <02E6CC26-D9AC-4ACE-BA7C-949B011EF47E@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> <04c101cf4cf5$5dce8db0$196ba910$@riw.us> <02E6CC26-D9AC-4ACE-BA7C-949B011EF47E@thomasclausen.org> Date: Mon, 31 Mar 2014 11:40:46 -0400 Message-ID: From: Alia Atlas To: Thomas Clausen Content-Type: multipart/alternative; boundary=20cf303ea63404db2404f5e8e0f2 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ciWSDuZZn8exAGCpsGbqvwsVXcE Cc: "Carlos Pignataro \(cpignata\)" , "" , Jamal Hadi Salim , Russ White , "rtg-chairs@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:40:52 -0000 --20cf303ea63404db2404f5e8e0f2 Content-Type: text/plain; charset=ISO-8859-1 I agree with what Thomas here. I don't see a reason to institutionalize and require acknowledgements. There is already membership in the directorate; there would be the association in the wiki. It would also be helpful to hear from more Routing Directorate members if they would be willing to do this and from more WG chairs as to whether it could be useful. Thanks, Alia On Mon, Mar 31, 2014 at 11:31 AM, Thomas Clausen wrote: > > On 31 Mar 2014, at 17:24, Russ White wrote: > > > > >>>> My view of mentorship is skewed a little. There has to be a return on > >>>> investment for the mentor. > >> > >> Giving back to the community? > > > > This will work for some folks, but not for others. Some folks have to > > justify time spent through their jobs, etc.; having some way to ack folks > > who play this role would be helpful. > > > > > I think that I have vague memories of a section in some documents, titled > "Acknowledgements". Might that be a place for the authors to express > gratitude (at their leisure) to the mentor? > > I firmly believe that authors will know when to say "Special thanks to > Russ White for his unfaltering support in seeing this document successfully > from WG adoption to publication, and for providing strong guidance on how > to best deal with ....", if indeed Russ White has been helpful (even, if he > wasn't an official mentor). > > On the other hand, I also firmly believe that no author should be > obligated to say "Special thanks to Thomas Clausen" if, in fact, all that > nefarious Thomas Clausen has done has been to make fun of document typos, > just because he was the assigned official mentor.... > > --20cf303ea63404db2404f5e8e0f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with what Thomas here. =A0I don't see a reason= to institutionalize and require acknowledgements.
There is already mem= bership in the directorate; there would be the association in the wiki.
=
It would also be helpful to hear from more Routing Directorate members if t= hey would be willing to do this
and from more WG chairs as to whe= ther it could be useful.

Thanks,
Alia
On Mon, Mar 31, 2014 at 11:31 AM, Thomas Cla= usen <thomas@thomasclausen.org> wrote:

On 31 Mar 2014, at 17:24, Russ White <ru= ssw@riw.us> wrote:

>
>>>> My view of mentorship is skewed a little. There has to be = a return on
>>>> investment for the mentor.
>>
>> Giving back to the community?
>
> This will work for some folks, but not for others. Some folks have to<= br> > justify time spent through their jobs, etc.; having some way to ack fo= lks
> who play this role would be helpful.
>


I think that I have vague memories of a section in some documen= ts, titled "Acknowledgements". Might that be a place for the auth= ors to express gratitude (at their leisure) to the mentor?

I firmly believe that authors will know when to say "Special thanks to= Russ White for his unfaltering support in seeing this document successfull= y from WG adoption to publication, and for providing strong guidance on how= to best deal with ....", if indeed Russ White has been helpful (even,= if he wasn't an official mentor).

On the other hand, I also firmly believe that no author should be obligated= to say "Special thanks to Thomas Clausen" if, in fact, all that = nefarious Thomas Clausen has done has been to make fun of document typos, j= ust because he was the assigned official mentor....


--20cf303ea63404db2404f5e8e0f2-- From nobody Mon Mar 31 08:51:56 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AA81A6F50; Mon, 31 Mar 2014 08:51:53 -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 a-9UyJsBfDLt; Mon, 31 Mar 2014 08:51:49 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 37FAE1A6F49; Mon, 31 Mar 2014 08:51:49 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so6404047ykp.1 for ; Mon, 31 Mar 2014 08:51:46 -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=8XDrLFdZJshq5kWpqEh4nrvFurd0hpGs0F8ctQO55Yc=; b=GZOZZsCVbZkDN9GyJNC78wxp2bFYyyGNfm7JAQ1Lh9r0DQyabsqNVVqTOYqOuhlgbR mCxFAVx/3vFuLeYKFs8RMI0pMPtsn2PWw5OWoFNkk0rd/dJR4FkVo3Z0v4C0RUUB8bHA fxLyBqNdLUV9yawosBJLAbhCHTbUYxgwP42SMkh1mtePUfy7NCpdGk0hriW/tGsZskw+ g2bFhwRsVouN8B8VDQX7/NMMNkWzJ5Me3l51+BOp+3brVWFoIlKfd+dCsoq0PD+4O3aR BsOyVYOaZFHYPp9boYLGf7wCfIA2me73eH4Iw1KMFMLlk4XDSWsVDsi/BZ/wqIaASrJy e+Ug== MIME-Version: 1.0 X-Received: by 10.236.22.74 with SMTP id s50mr3102378yhs.109.1396281105960; Mon, 31 Mar 2014 08:51:45 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 08:51:45 -0700 (PDT) In-Reply-To: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> Date: Mon, 31 Mar 2014 11:51:45 -0400 Message-ID: From: Alia Atlas To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=e89a8f646df353d45004f5e907b5 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/3FgcAIzNKrVIo1RMe5y3CPBqNn4 Cc: "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:51:54 -0000 --e89a8f646df353d45004f5e907b5 Content-Type: text/plain; charset=ISO-8859-1 Hi Les, Thanks for your thoughts, On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (ginsberg) < ginsberg@cisco.com> wrote: > The way I read what is proposed below is that all documents will be > assigned a mentor. Perhaps that is not what you intended - but it does seem > to read that way. And as others who have replied to this have suggested > that doesn't make sense for all documents and doesn't scale well. Also, the > stated process introduces mentoring AFTER a document is adopted as a WG > item. IMHO this is too late. > The process involves discussing having a document mentor. If the WG chairs and authors agree that there is no need, then no document mentor is required. It is intended to be expressly a check and decide against rather than requiring an ask. As for scaling, which aspect is the concern? There are really about 200 WG drafts in the state where they'd have document mentors and many of those wouldn't need them. I am happy to address scaling concerns - but I need to understand the parameters of concern. > What I would suggest is that there become three options available for a WG > to choose when a document is proposed as a WG item: > > 1)Accept > 2)Reject > 3)Resubmit after mentoring > > The third category is reserved for documents which the WG feels have an > idea/solution which might be worth the WG group's time, but the current > "quality" of the document is such that meaningful discussion would be > hindered. > The authors are free to reject the offer of mentoring in which case the > document is rejected. > > This limits the time/effort on the part of the mentors to a smaller number > of documents and only for ones that are actually worth the time. Also, it > means the time of the entire WG is not wasted on discussions that might be > unnecessary if the draft presentation were improved. > You are assuming that there is never any need for external review or to improve drafts by review (outside the standard WG members) before WGLC. The goal of the document mentor is to do early review and suggest improvements and changes once the draft is under control of the IETF - which individual drafts aren't. For the case that you are suggesting, I feel like that belongs to the WG chair to figure out getting the reviews and improvement needed. It is useful - of course! - but not the problem that this idea is trying to solve. > That said, the danger I see here is that in some cases it will be very > hard for a mentor to provide meaningful feedback without also commenting on > the guts of the solution. If the only issue is "grammar", then not a > concern. But I think what we are trying to address may go beyond simply > editorial/grammatical issues in some cases and then it is not clear to me > how one separates "mentoring" from "authorship". > This isn't a language review or an editing relationship! This is technical mentoring of the document - which includes making suggestions during a review of how it can be improved. Done well, I'd expect it to go to acknowledgements. I certainly review drafts and make significant comments without expecting or needing to become an author. Alia > > Les > > > > -----Original Message----- > > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian > Farrel > > Sent: Monday, March 31, 2014 5:12 AM > > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > > Subject: [RTG-DIR] Document Mentors > > > > Hi, > > > > One of the ideas to come out of the recent discussions is appointing a > mentor > > per document from the time it is adopted by a Routing Area working group > > until > > it completes WG last call. > > > > This would be voluntary in two dimensions: > > - the WG chairs would need to deem that one would be beneficial > > - we would have to find someone from the Directorate willing to > > take on the document. > > > > We don't think that technology expertise is as useful in this as IETF > clue > > and > > general routing experience. > > > > So, to take this forward we would need: > > - WG chairs to say "Yes, we can see that that would have > > potential benefit > > - Directorate members to say "Yes, we could take on that > > additional work. > > > > Alia and I have put together some preliminary notes on how this would all > > hang > > together. > > > > Your opinions and rotten fruit are solicited. > > > > Thanks, > > Adrian and Alia > > > > ========= > > > > Document Mentors in the Routing Area > > > > The Problems: > > > > a) Drafts get little review outside the working group and sometimes > inside > > the working group until after working group last call. At that point > it is > > often > > painful and costly to make meaningful improvements to the drafts. > > > > b) Authors may not know how or whom to ask for assistance or review > > (e.g., IANA section, Security Section, Operational and Management > > considerations, details of a protocol, etc. ). > > > > The Goals: > > > > a) Excellent and consistent review at WG adoption and before WG last > > call. > > > > b) Ability for prolonged discussion and problem-solving when the > > draft can still be easily enhanced. > > > > c) Reduced time to delivery of RFCs. > > > > d) Quality documents. > > > > The Solution: > > > > A per-document mentor who is a known neutral party to whom the > > authors can go for advice on: > > - how to write a section > > - specific issues that arise > > - ways to resolve conflicts. > > > > The document mentor also watches the progress of the document > > and gives advice and steerage. > > > > It is not assumed that every document will need or benefit from > > having a mentor. > > > > The Expected Workload: > > > > The routing directorate has approximately 40 people. If we assume > > that approximately 50 drafts pass WG adoption and a similar number > > pass WGLC each year, then the load is 2.5 documents per person > > per year. If we assume that there are about 200 WG drafts in the > > Routing Area and that they all have mentors, then each Routing > > Directorate member will have 5 drafts that she or he is mentoring. > > > > The Supporting Data Artefacts: > > > > a) As part of the Routing Area wiki, the areas of knowledge for > > each member of the Routing Directorate will be publicly specified. > > This is added to the wiki by the Routing Area Coordinators (or AD) > > when the member joins the Routing Directorate, updated by the > > member while he or she is on the Directorate, and updated by the > > Routing Area Coordinators (or AD) if and when the member's term > > renews. > > > > b) Document Mentor Availability and Assignments: As part of the > > Routing Area wiki, each Directorate member will specify the maximum > > number of documents that he or she is able to mentor. Also listed > > will be the list of mentored documents (and a count). > > > > i) When a Directorate member is assigned as the Document > > mentor, the Routing Directorate Coordinator will update the > > wiki page and create a wiki page for the draft. > > > > ii) When a Document Mentor provides a review, that should be > > stored in the draft's wiki page along with the resolutions. > > > > iii) When the Document Mentor's final review at WGLC is done, > > the Document Mentor should move the draft to a list of > > "previously mentored documents" associated with their name. > > It is ideal to write up a summary of the document mentoring > > experience. > > > > c) Unmentored Documents: Drafts which have declined a document > > mentor should be listed on a wiki page. > > > > d) For each WG's wiki, it'd be useful to have the list of drafts > > with their associated Document Mentors (or lack thereof) and the > > link to the draft's wiki page. > > > > The Basic Process: > > > > When a new WG draft is adopted, the WG chairs and the Routing > > Directorate Coordinators discuss and agree on possible Document > > Mentors (up to 3). Then the Routing Directorate Coordinator > > confirms with the Routing Directorate members about their > > availability and willingness to mentor this particular draft. Once > > one is selected, the Routing Directorate Coordinator updates the > > wiki and notifies the WG chairs and draft authors. > > > > a) With the agreement of the ADs, a Document Mentor who is not a > > member of the Routing Directorate may be selected. > > > > b) The WG chairs can, after consulting with the draft authors, > > decline to have a Document Mentor. > > > > c) The Document Mentor should coordinate with the Document > > Shepherd for hand-off after WGLC. > > > > > > > > --e89a8f646df353d45004f5e907b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Les,

Thanks for your thoughts,

On Mon, Mar 31, 2014 at= 11:39 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wro= te:
The way I read what is proposed below is tha= t all documents will be assigned a mentor. Perhaps that is not what you int= ended - but it does seem to read that way. And as others who have replied t= o this have suggested that doesn't make sense for all documents and doe= sn't scale well. Also, the stated process introduces mentoring AFTER a = document is adopted as a WG item. IMHO this is too late.

The process involves discussing having a d= ocument mentor. =A0If the WG chairs and authors agree that there is no need= , then no document mentor is required. =A0It is intended to be expressly a = check and decide against rather than requiring an ask. =A0As for scaling, w= hich aspect is the concern? =A0 There are really about 200 WG drafts in the= state where they'd have document mentors and many of those wouldn'= t need them. =A0 I am happy to address scaling concerns - but I need to und= erstand the parameters of concern.
=A0
What I would suggest is that there become three options available for a WG = to choose when a document is proposed as a WG item:

1)Accept
2)Reject
3)Resubmit after mentoring

The third category is reserved for documents which the WG feels have an ide= a/solution which might be worth the WG group's time, but the current &q= uot;quality" of the document is such that meaningful discussion would = be hindered.
The authors are free to reject the offer of mentoring in which case the doc= ument is rejected.

This limits the time/effort on the part of the mentors to a smaller number = of documents and only for ones that are actually worth the time. Also, it m= eans the time of the entire WG is not wasted on discussions that might be u= nnecessary if the draft presentation were improved.

You are assuming that there is never any n= eed for external review or to improve drafts by review (outside the standar= d WG members) before WGLC. =A0 The goal of the document mentor is to do ear= ly review and suggest improvements and changes once the draft is under cont= rol of the IETF - which individual drafts aren't.

For the case that you are suggesting, I feel like that = belongs to the WG chair to figure out getting the reviews and improvement n= eeded. =A0It is useful - of course! - but not the problem that this idea is= trying to solve.
=A0
That said, the danger I see he= re is that in some cases it will be very hard for a mentor to provide meani= ngful feedback without also commenting on the guts of the solution. If the = only issue is "grammar", then not a concern. But I think what we = are trying to address may go beyond simply editorial/grammatical issues in = some cases and then it is not clear to me how one separates "mentoring= " from "authorship".

This isn't a language review or an edi= ting relationship! =A0 This is technical mentoring of the document - which = includes making suggestions during a review of how it can be improved. =A0D= one well, I'd expect it to go to acknowledgements. =A0I certainly revie= w drafts and make significant comments without expecting or needing to beco= me an author.

Alia
=A0

=A0 =A0Les


> -----Original Message-----
> From: rtg-dir [mailto:rtg-= dir-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Monday, March 31, 2014 5:12 AM
> To: rtg-dir@ietf.org; rtg-chairs@ietf.org
> Subject: [RTG-DIR] Document Mentors
>
> Hi,
>
> One of the ideas to come out of the recent discussions is appointing a= mentor
> per document from the time it is adopted by a Routing Area working gro= up
> until
> it completes WG last call.
>
> This would be voluntary in two dimensions:
> - the WG chairs would need to deem that one would be beneficial
> - we would have to find someone from the Directorate willing to
> =A0 =A0take on the document.
>
> We don't think that technology expertise is as useful in this as I= ETF clue
> and
> general routing experience.
>
> So, to take this forward we would need:
> - WG chairs to say "Yes, we can see that that would have
> =A0 =A0potential benefit
> - Directorate members to say "Yes, we could take on that
> =A0 additional work.
>
> Alia and I have put together some preliminary notes on how this would = all
> hang
> together.
>
> Your opinions and rotten fruit are solicited.
>
> Thanks,
> Adrian and Alia
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Document Mentors in the Routing Area
>
> The Problems:
>
> =A0 a) Drafts get little review outside the working group and sometime= s inside
> =A0 the working group until after working group last call. At that poi= nt it is
> often
> =A0 painful and costly to make meaningful improvements to the drafts.<= br> >
> =A0 b) Authors may not know how or whom to ask for assistance =A0or re= view
> =A0 (e.g., IANA section, Security Section, Operational and Management<= br> > =A0 considerations, details of a protocol, etc. ).
>
> The Goals:
>
> =A0 a) Excellent and consistent review at WG adoption and before WG la= st
> =A0 call.
>
> =A0 b) Ability for prolonged discussion and problem-solving when the > =A0 draft can still be easily enhanced.
>
> =A0 c) Reduced time to delivery of RFCs.
>
> =A0 d) Quality documents.
>
> The Solution:
>
> =A0 A per-document mentor who is a known neutral party to whom the
> =A0 authors can go for advice on:
> =A0 - how to write a section
> =A0 - specific issues that arise
> =A0 - ways to resolve conflicts.
>
> =A0 The document mentor also watches the progress of the document
> =A0 and gives advice and steerage.
>
> =A0 It is not assumed that every document will need or benefit from > =A0 having a mentor.
>
> The Expected Workload:
>
> =A0 =A0The routing directorate has approximately 40 people. =A0If we a= ssume
> =A0 =A0that approximately 50 drafts pass WG adoption and a similar num= ber
> =A0 =A0pass WGLC each year, then the load is 2.5 documents per person<= br> > =A0 =A0per year. =A0If we assume that there are about 200 WG drafts in= the
> =A0 =A0Routing Area and that they all have mentors, then each Routing<= br> > =A0 =A0Directorate member will have 5 drafts that she or he is mentori= ng.
>
> The Supporting Data Artefacts:
>
> =A0 =A0a) As part of the Routing Area wiki, the areas of knowledge for=
> =A0 =A0each member of the Routing Directorate will be publicly specifi= ed.
> =A0 =A0This is added to the wiki by the Routing Area Coordinators (or = AD)
> =A0 =A0when the member joins the Routing Directorate, updated by the > =A0 =A0member while he or she is on the Directorate, and updated by th= e
> =A0 =A0Routing Area Coordinators (or AD) if and when the member's = term
> =A0 =A0renews.
>
> =A0 =A0b) Document Mentor Availability and Assignments: As part of the=
> =A0 =A0Routing Area wiki, each Directorate member will specify the max= imum
> =A0 =A0number of documents that he or she is able to mentor. =A0Also l= isted
> =A0 =A0will be the list of mentored documents (and a count).
>
> =A0 =A0 =A0 =A0 i) When a Directorate member is assigned as the Docume= nt
> =A0 =A0 =A0 =A0 mentor, the Routing Directorate Coordinator will updat= e the
> =A0 =A0 =A0 =A0 wiki page and create a wiki page for the draft.
>
> =A0 =A0 =A0 =A0 ii) When a Document Mentor provides a review, that sho= uld be
> =A0 =A0 =A0 =A0 stored in the draft's wiki page along with the res= olutions.
>
> =A0 =A0 =A0 =A0 iii) When the Document Mentor's final review at WG= LC is done,
> =A0 =A0 =A0 =A0 the Document Mentor should move the draft to a list of=
> =A0 =A0 =A0 =A0 "previously mentored documents" associated w= ith their name.
> =A0 =A0 =A0 =A0 It is ideal to write up a summary of the document ment= oring
> experience.
>
> =A0 =A0c) Unmentored Documents: Drafts which have declined a document<= br> > =A0 =A0mentor should be listed on a wiki page.
>
> =A0 =A0d) For each WG's wiki, it'd be useful to have the list = of drafts
> =A0 =A0with their associated Document Mentors (or lack thereof) and th= e
> =A0 =A0link to the draft's wiki page.
>
> The Basic Process:
>
> =A0 When a new WG draft is adopted, the WG chairs and the Routing
> =A0 Directorate Coordinators discuss and agree on possible Document > =A0 Mentors (up to 3). =A0Then the Routing Directorate Coordinator
> =A0 confirms with the Routing Directorate members about their
> =A0 availability and willingness to mentor this particular draft. Once=
> =A0 one is selected, the Routing Directorate Coordinator updates the > =A0 wiki and notifies the WG chairs and draft authors.
>
> =A0 =A0 =A0a) With the agreement of the ADs, a Document Mentor who is = not a
> =A0 =A0 =A0member of the Routing Directorate may be selected.
>
> =A0 =A0 =A0b) The WG chairs can, after consulting with the draft autho= rs,
> =A0 =A0 =A0decline to have a Document Mentor.
>
> =A0 =A0 =A0c) The Document Mentor should coordinate with the Document<= br> > =A0 =A0 =A0Shepherd for hand-off after WGLC.
>
>
>


--e89a8f646df353d45004f5e907b5-- From nobody Mon Mar 31 09:02:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C0C1A6F0C; Mon, 31 Mar 2014 09:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-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 oyUSEw5EAVgn; Mon, 31 Mar 2014 09:02:21 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) by ietfa.amsl.com (Postfix) with ESMTP id 1744A1A088C; Mon, 31 Mar 2014 09:02:21 -0700 (PDT) Received: from cpe-098-122-144-218.nc.res.rr.com ([98.122.144.218]:62114 helo=RussPC) by server.riw.us with esmtpsa (UNKNOWN:AES128-SHA256:128) (Exim 4.82) (envelope-from ) id 1WUef5-0000f0-WB; Mon, 31 Mar 2014 16:02:12 +0000 From: "Russ White" To: "'Thomas Clausen'" References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <02c701cf4ceb$af62d870$0e288950$@riw.us> <04c101cf4cf5$5dce8db0$196ba910$@riw.us> <02E6CC26-D9AC-4ACE-BA7C-949B011EF47E@thomasclausen.org> In-Reply-To: <02E6CC26-D9AC-4ACE-BA7C-949B011EF47E@thomasclausen.org> Date: Mon, 31 Mar 2014 12:02:10 -0400 Message-ID: <057101cf4cfa$939b30b0$bad19210$@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: AQLRW8MC2jlgo4YShVQKqZSaQzM51wDaXBXyAmj3F30Bsi0auAH32ulCAquNUdQC5qlsJQKFbujmmH8VYpA= 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/rtg-dir/Wkj-7oDq-68E2IOSo6f7hIwX6Vw Cc: "'Carlos Pignataro \(cpignata\)'" , rtg-chairs@ietf.org, 'Adrian Farrel' , rtg-dir@ietf.org, 'Jamal Hadi Salim' Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:02:22 -0000 > I think that I have vague memories of a section in some documents, titled > "Acknowledgements". Might that be a place for the authors to express > gratitude (at their leisure) to the mentor? Okay -- point taken... I'm fine with asking that an ack be included in the ack's section. :-) Russ From nobody Mon Mar 31 09:18:17 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FAF1A0892 for ; Mon, 31 Mar 2014 09:18:14 -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_52=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 pkFNmF2RxIMo for ; Mon, 31 Mar 2014 09:18:12 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 453CE1A0884 for ; Mon, 31 Mar 2014 09:18:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 61A3D6A01DD; Mon, 31 Mar 2014 09:18:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0877D6A01D5; Mon, 31 Mar 2014 09:18:06 -0700 (PDT) From: Thomas Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Mar 2014 18:18:04 +0200 Message-Id: <9C91CB2D-CD30-420A-AB2A-17D0BD9E0271@thomasclausen.org> To: rtg-ads@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/wEOxj3SvZqV1VfB7c3bHF3C3Yuk Cc: rtg-dir@ietf.org, draft-avula-shwmp.all@tools.ietf.org Subject: [RTG-DIR] RtgDir Review: draft-avula-shwmp-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:18:15 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-avula-shwmp-01 Reviewer: Thomas Heide Clausen Review Date: 2014/03/31 IETF LC End Date: Unknown Intended Status: Experimental Summary: o I have significant concerns about this document and = recommend that the=20 Routing ADs discuss these issues further with the = authors. Comments: The document is actually hard to review. I happen to know HWMP = and IEEE802.11s better than I am proud to admit in public, which helps a little - but, = setting this aside, it is clear that this specification is written for somebody knowing at least as much = about IEEE 802.11s as the authors. The document was briefly discussed in the MANET working group, = the=20 relevant thread can be found here: = http://www.ietf.org/mail-archive/web/manet/current/msg15943.html The document could do with an editorial pass to clean up some = language-related issues which, occasionally, renders the text ambiguous. I am not a native = English speaker myself, so far be it for me to be overly critical, but I had a hard time parsing = every other sentence in section 3, for=20 example. Finally, I am not a security expert; I am raising things that I = encounter and according to my understanding of security, but it probably would be wise to have = a careful review from security folks also. I do believe that the approach chosen is = certainly not evolutive, and that - to me - is a show-stopper. The status of this document is "experimental" and, as such, it = should encourage "experiments". The RTG ADs generally request a section documenting "what is the = experiments that this=20 document is supposed to enable?", and I see none. This document relates to an IEEE developed L2 protocol, and is = an independent stream submission. =09 At the very least, given that we do not know what the = interaction between this protocol, and other IEEE 802.11 protocol components, some text in an applicability = statement should disclaim that=20 this protocol should operate only in a well-defined and confined = area on the edge of the Internet. Major Issues: o This document proposes a security mechanism for HWMP, = the mesh-under routing protocol developed by the IEEE for IEEE 802.11 networks. I see several issues = with this: - The IETF does not, typically, design or publish = L2 protocols. I wonder if=20 it is not more beneficial to bring this work to = the relevant groups of the IEEE? I do not believe that it is the mandate of the = IETF or the RFC series to maintain and update IEEE specifications. - In case there is an explicit reason why the = authors have brought this to the IETF, such as heavy reliance on L3 or higher = mechanisms/protocols, this should be called out explicitly in the = document. While I do not want to be a "pedant for formalities", I'd have expected an = "applicability section" or something in the document, which explained this. o The IEEE 802 suite of specifications already contains a = sizeable amount of efforts on security, and IEEE 802.11s (from which = HWMP originates) did work on security. It is actually unclear what exactly the = extension to HWMP, presented in this specification, brings that is not already = covered. In other words, it is not convincing in which way an IEEE 802.11s deployment with HWMP is = vulnerable, but where SHWMP is invulnerable. o Continuing on from that, "external attacks", apparently, = are something that end-to-end encryption schemes can prevent, and this is what = (according to the authors) IEEE 802.1x=20 offers (section 2.1). It is not clear what an "external = attack" is...is this a matter of a (non-participating) device being able to intercept = data traffic, or is this a matter of a (not-participating) device being able to inject HWMP = control traffic into the network, and to thereby disrupt it? o This document is not including the usual = RFC2119-terminology disclaimer; in addition, it leaves many - if not most - of the used = terminology undefined. To give an example "internal attack" vs "external attack".=20 o Section 2 states: HWMP is the basic routing protocol of a WMN and this paper = discusses the protection of HWMP routing messages but not the data = messages. Which is materially wrong. HWMP is the basic routing = protocol in IEEE 802.11s;=20 there're many other mesh routing protocols out there, = many of which are widely=20 deployed. Also, this is not a "paper", but a protocol = specification. o As with "external attacks", it is not clear either what = the "internal attacks" that the authors=20 assert that SHWMP protects against are. Section 2.1: The major problem that is plaguing the WMNs = is the detection of internal attacks. Internal attacks might = involve modification of contents of the HWMP frame such as hop count = and air time metric. I am not sure that wireless mesh networks are "plagued" = by this, but that aside...would that not imply that somehow admission to the network has been = granted (cryptographic material/key provided) to somebody, who then turns around and then = "attacks" the network? If so, then my initial reaction would be that if detected, the right = approach would be to revoke the keys issued to the "badly behaving device". It is not clear = how SHWMP interacts with any key=20 management and revocation functions in an IEEE 802.11 = network. o Continuing through section 2.1, essentially what this = document is saying is: o It's easy to protect protocol signals = which are immutable, or to protect immutable fields in protocol = signals, against tampering o It's problematic to protect mutable = fields in protocol signals, against=20 tampering o ....but, it's important to do so. While one might not take huge issues with the first = two, the third doesn't follow.=20 What is missing, IMO, is some sort of problem = statement, including a security=20 analysis. If a mutable field is tampered with, how does = that hurt? Will the system break down? Perform a little worse? A lot worse?=20 This section ends by saying: However, the fields that get changed is quite = important to provide link-to- link based security so that every = node along the journey should authenticate the frame before passing = it on. This ensures that the contents of the frame are not = modified and the frames can get dropped if they are modified. Three things. 1) The language is ambiguous: "The fields = that get changed [by whom?=20 intentionally or the attacker] is = [should be are] quite important to provide=20 link-to-link based security [so, is the = important bit that "The value of the fields=20 is what HWMP uses fir providing = link-to-link based security"? Or, is the important=20 bit that these fields are not changed, = and the security mechanism should prevent=20 this] [also, what is link-to-link base = security]? 2) OK, so I understand: the goal is to = provide hop-by-hop authentication of a frame. That implies a specific trust model of = the form "I trust my neighbor to only trust=20 neighbors that I would also have = trusted", which is not documented. Is that model valid in this type of networks? 3) If 3) is indeed is a valid trust model, = what does the solution proposed actually do? If my neighbor has the right = cryptographic material to generate the signatures needed, then he can tamper = with any and all fields, unchallenged and undetected. In other words, is this = approach protecting against the "internal attacks" intended? o But then I read on to section 2.2, and to my surprise = see that what I had identified in 2.1=20 was not at all true - at least, it doesn't read that = way. Section 2.2 is entitled "Security features of Secure HWMP", but reading that - after = having read 2.1 - I still want to understand the (at least, abstract) answers to four simple = questions: a) What are the identified vulnerabilities = of HWMP, which SHWMP patches? b) What is the trust model assumed? c) How does that trust model match actual = deployments? d) How does SHWMP integrate with IEEE 802 = security mechanisms, key mgmt, ...? o Section 3, I believe that before starting to discuss the = extension, a presentation of HWMP would be in order, at least the necessary details = for the reader to understand the rest of the document. As it is, it is understandable to = those who have a pretty good idea=20 of the functioning of HWMP only. As it is, and after = reading section 3, I would suggest that the reader is as confused as to what HWMP is, what = SHWMP does, and how. o Section 3, 4 I believe that the bulk of the HWMP = terminology used should actually, be defined in the terminology section - and that the = terminology section therefore belongs before Section 3. o Section 3, and section 6.1: o what does it mean that the "source node = signs the non-mutable fields"? =09 How are the signatures generated, how are mutable fields = treated (Zeroed out? Removed? Something else?) o Section 5 is missing definition of which byte-order, = bit-order is used, as well as for=20 each field what format (unsigned integer, ...) the = values are in. o Section 5 is missing some discussion as to how these = messages are intended to be included in the frame format of IEEE 802.11. Does that format already = have a mechanism for protocol extensions? If so, does the format for these extensions "fit in"? = How? Are there any requirements for code-point reservations = with the IEEE? Have those been made? How will those be made? Will experimental code-points = from IEEE maintained registries be used? o I am not sure if the last sentence on page 10 in section = 5.5 should/does not mark the start of a new paragraph. It seems to talk about "all the = message types" and not just the GANN message type described immediately previously. o Generally, and specifically to section 6, it might be = good to provide a reference to HWMP,=20 which SHWMP is extending; it is not enough to simply cite the IEEE standard. If I = was to implement this, I would want to know more, including: o Which specific parts of the (voluminous) = 802.11 standard need I study? o Which specific processing steps need I = to interface with, iow., the operations described in this specification are to = be done before/after which steps in which process in which section of IEEE 802.11 As it is, I could not implement this proposed extension = to SHWMP in a fashion where I would be sure to (i) do it right, and (ii) do it in a way that = would be interoperable with somebody elses' implementation. o As this is a security document, I would expect a = complete and strong security considerations section.=20 As indicated in the above, I believe that - at least - = what is missing is: o Relationship to 802.1x and other 802 = security mechanisms o Trust model o Protections offered o Specifically, protections not offered o Limits of cryptographic methods = recommended o Ability to evolve - threats on networks = tend to not be static o I have a MAJOR-MAJOR issue related to the cryptological = tools used. I am not enough of an=20 expert in crypto to know which exact parameters are = required to be carried around for each algorithm, but.....for example, key indices, which = parameters of a curve, or a function, are to be used, ..... -- all of which seems to be not = specified, and perhaps should not be specified as it is part of some 802 security framework....but, in = that case, it most certainly should be discussed. What I know, however, is that a cryptographic method = that's "good" today is "worthless"=20 a few years, or even months, hence. I see no codepoints = allowing identifying which (say) of RSA, DES, HMAC, ECDSA, AES, .... and whatever = the future brings, is used?=20 Same for hash functions....not long ago md5 was used, = today it's definitely not.... At the very least, I would expect an IANA registry set = up (or, references to an 802 registry) recording code-points for different algorithms - and the = messages to contain fields for indicating which hash/crypto function to use. Minor Issues: =09 Nits: o I believe that it would behove the document if the = abstract called out where HWMP has=20 come from, especially as it is not an IETF protocol, or = even a L3 protocol o References are not split up in Normative and Informative = references, and (FWIW) are not formatted in the usual fashion. o Section 3, 2nd paragraph: I believe that it would be = beneficial to split this up in several independent paragraphs or, perhaps, an enumerated list. I ended up = making the latter on a piece of paper to not get lost in the description. Respectfully, Thomas From nobody Mon Mar 31 09:20:22 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622011A6EFE for ; Mon, 31 Mar 2014 09:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 dDBRNr6rMYnh for ; Mon, 31 Mar 2014 09:20:03 -0700 (PDT) Received: from mail-pb0-f52.google.com (mail-pb0-f52.google.com [209.85.160.52]) by ietfa.amsl.com (Postfix) with ESMTP id C548E1A0892 for ; Mon, 31 Mar 2014 09:20:03 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so8468898pbb.11 for ; Mon, 31 Mar 2014 09:20:00 -0700 (PDT) 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=yPmvPDVKqBFMmXB8gcxAQHvCIAb+P9JcHLDOVpjl8gY=; b=XDs2CKtSx6pnPV3L2wWIe43FZwPmR26V9pZHL8krZO2LQKorlFTo5h+D7+KsPKfSB4 2v3M4JtMKt07HoHBOhaJhW8xwXp5Qt7tP9sDFIJ7W4IkUUBLdHXPFahGrwVcJiRxUHJO b1/0/MhPXNKwDoQt5BQNUWozual5eVmk/kGLn0Pgh0uoccWYJ+wfrS1E/8sTFAZ3KtOh q9r+FsepQUuISvmmQPpF5Zk4K+BBgZCzvCin+UApQWnd2tIqNM8AdVBQMsnpNk1swXEi r7Vc6857ZndskDGsl4Sn522I7veUKd4DhKwGFzJgt/TYjTN8YUBGvaHrciFogAMFKnkG QehQ== X-Gm-Message-State: ALoCoQk0ziGkTeC7qHJ1hCEZ+GCMzSfhYIh5ZzIl5DgwsLmw5Xhq7SELuACqlMAHtErR7BJK5xsq X-Received: by 10.68.37.42 with SMTP id v10mr7795510pbj.127.1396282800686; Mon, 31 Mar 2014 09:20:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.11.234 with HTTP; Mon, 31 Mar 2014 09:19:40 -0700 (PDT) In-Reply-To: <0246663B-D112-489E-B060-5686253C98E7@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <0246663B-D112-489E-B060-5686253C98E7@thomasclausen.org> From: Jamal Hadi Salim Date: Mon, 31 Mar 2014 12:19:40 -0400 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/aj86zOsNRNv-216qxl9nLkbHXXU Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:20:09 -0000 Hi Thomas, On Mon, Mar 31, 2014 at 10:18 AM, Thomas Clausen wrote: > Personally, I am grateful enough for the work that was done by others in building the Internet, and the help I got from elder IETFers when I started in the IETF, to want to "pay it forward" a bit, as best I can. > I understand and empathize. [sorry, snipping through rest of text] > > Essentially, you say that you prefer "spending time evaluating and rejecting a kernel-patch on submission" than >"spending time making sure that submitted kernel-patches are good". > Yes, because it has been proven to scale better. I realize this approach is open to abuse as well - but thats a different socio-economic discussion. > Well, I disagree there, I think at WG adoption is the right time. Just before shepherding step is (for > all intents and purposes) the same as during IETF LC. > Ok, i will agree to disagree ;-> cheers, jamal From nobody Mon Mar 31 09:22:15 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CE01A6F0E for ; Mon, 31 Mar 2014 09:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 DhFX47zV7S2Z for ; Mon, 31 Mar 2014 09:21:48 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id CFACB1A0893 for ; Mon, 31 Mar 2014 09:21:44 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id uo5so8400034pbc.18 for ; Mon, 31 Mar 2014 09:21:41 -0700 (PDT) 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:content-transfer-encoding; bh=oVB2C/wH58pXnrmIlTohsKk60ZkvH3XbpBElvULyPm8=; b=c1Tcz/JGcO+aO/iSEX+Zq9w7fw9JjirNnmY02xQ0UcnSCMTNORUuLiMVGAMzMeUf67 RipzsFR2rjD0fAECMFwwS1LfcgD0hdCvMqMotj2pKc43seCp6No31FIqipW01ZTRCZUC /E1b2EQgxqLnYb/MlNGfI7OijJRNx54yYRLsT5zK5uGIptA+60hdvzMNi6sKNwDa672a QeW4MgtYXtDYz1n5YTPvsG+IHDt254uwloObvay27ZGgQ5bnu3PiZ8k8vECEFdOGADwZ VxCpg8HQLS9DwtJW+bDLlpCrLdlL1uzCjKjzfjHFZlwieYS1TPxXKjZ9OErqN0T/DFaf Xfdg== X-Gm-Message-State: ALoCoQmLN1X17YsnhAIJJOxdJ4vC5ksw7d0sKQhWnUk6j5ghzdkw17VE4gjWy213kJRLwWPVOsnv X-Received: by 10.68.37.42 with SMTP id v10mr7804126pbj.127.1396282901747; Mon, 31 Mar 2014 09:21:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.11.234 with HTTP; Mon, 31 Mar 2014 09:21:21 -0700 (PDT) In-Reply-To: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> From: Jamal Hadi Salim Date: Mon, 31 Mar 2014 12:21:21 -0400 Message-ID: To: "Les Ginsberg (ginsberg)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/jFxYC_xM7ehGz5IthBr6rDHHFBs Cc: "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:21:53 -0000 Resubmit after mentoring may scale better. But i think you hit the nail on the head with: "But I think what we are trying to address may go beyond simply editorial/grammatical issues" Often the bad drafts require a total rewrite. cheers, jamal On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (ginsberg) wrote: > The way I read what is proposed below is that all documents will be assig= ned a mentor. Perhaps that is not what you intended - but it does seem to r= ead that way. And as others who have replied to this have suggested that do= esn't make sense for all documents and doesn't scale well. Also, the stated= process introduces mentoring AFTER a document is adopted as a WG item. IMH= O this is too late. > > What I would suggest is that there become three options available for a W= G to choose when a document is proposed as a WG item: > > 1)Accept > 2)Reject > 3)Resubmit after mentoring > > The third category is reserved for documents which the WG feels have an i= dea/solution which might be worth the WG group's time, but the current "qua= lity" of the document is such that meaningful discussion would be hindered. > The authors are free to reject the offer of mentoring in which case the d= ocument is rejected. > > This limits the time/effort on the part of the mentors to a smaller numbe= r of documents and only for ones that are actually worth the time. Also, it= means the time of the entire WG is not wasted on discussions that might be= unnecessary if the draft presentation were improved. > > That said, the danger I see here is that in some cases it will be very ha= rd for a mentor to provide meaningful feedback without also commenting on t= he guts of the solution. If the only issue is "grammar", then not a concern= . But I think what we are trying to address may go beyond simply editorial/= grammatical issues in some cases and then it is not clear to me how one sep= arates "mentoring" from "authorship". > > Les > > >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farr= el >> Sent: Monday, March 31, 2014 5:12 AM >> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: [RTG-DIR] Document Mentors >> >> Hi, >> >> One of the ideas to come out of the recent discussions is appointing a m= entor >> per document from the time it is adopted by a Routing Area working group >> until >> it completes WG last call. >> >> This would be voluntary in two dimensions: >> - the WG chairs would need to deem that one would be beneficial >> - we would have to find someone from the Directorate willing to >> take on the document. >> >> We don't think that technology expertise is as useful in this as IETF cl= ue >> and >> general routing experience. >> >> So, to take this forward we would need: >> - WG chairs to say "Yes, we can see that that would have >> potential benefit >> - Directorate members to say "Yes, we could take on that >> additional work. >> >> Alia and I have put together some preliminary notes on how this would al= l >> hang >> together. >> >> Your opinions and rotten fruit are solicited. >> >> Thanks, >> Adrian and Alia >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Document Mentors in the Routing Area >> >> The Problems: >> >> a) Drafts get little review outside the working group and sometimes in= side >> the working group until after working group last call. At that point i= t is >> often >> painful and costly to make meaningful improvements to the drafts. >> >> b) Authors may not know how or whom to ask for assistance or review >> (e.g., IANA section, Security Section, Operational and Management >> considerations, details of a protocol, etc. ). >> >> The Goals: >> >> a) Excellent and consistent review at WG adoption and before WG last >> call. >> >> b) Ability for prolonged discussion and problem-solving when the >> draft can still be easily enhanced. >> >> c) Reduced time to delivery of RFCs. >> >> d) Quality documents. >> >> The Solution: >> >> A per-document mentor who is a known neutral party to whom the >> authors can go for advice on: >> - how to write a section >> - specific issues that arise >> - ways to resolve conflicts. >> >> The document mentor also watches the progress of the document >> and gives advice and steerage. >> >> It is not assumed that every document will need or benefit from >> having a mentor. >> >> The Expected Workload: >> >> The routing directorate has approximately 40 people. If we assume >> that approximately 50 drafts pass WG adoption and a similar number >> pass WGLC each year, then the load is 2.5 documents per person >> per year. If we assume that there are about 200 WG drafts in the >> Routing Area and that they all have mentors, then each Routing >> Directorate member will have 5 drafts that she or he is mentoring. >> >> The Supporting Data Artefacts: >> >> a) As part of the Routing Area wiki, the areas of knowledge for >> each member of the Routing Directorate will be publicly specified. >> This is added to the wiki by the Routing Area Coordinators (or AD) >> when the member joins the Routing Directorate, updated by the >> member while he or she is on the Directorate, and updated by the >> Routing Area Coordinators (or AD) if and when the member's term >> renews. >> >> b) Document Mentor Availability and Assignments: As part of the >> Routing Area wiki, each Directorate member will specify the maximum >> number of documents that he or she is able to mentor. Also listed >> will be the list of mentored documents (and a count). >> >> i) When a Directorate member is assigned as the Document >> mentor, the Routing Directorate Coordinator will update the >> wiki page and create a wiki page for the draft. >> >> ii) When a Document Mentor provides a review, that should be >> stored in the draft's wiki page along with the resolutions. >> >> iii) When the Document Mentor's final review at WGLC is done, >> the Document Mentor should move the draft to a list of >> "previously mentored documents" associated with their name. >> It is ideal to write up a summary of the document mentoring >> experience. >> >> c) Unmentored Documents: Drafts which have declined a document >> mentor should be listed on a wiki page. >> >> d) For each WG's wiki, it'd be useful to have the list of drafts >> with their associated Document Mentors (or lack thereof) and the >> link to the draft's wiki page. >> >> The Basic Process: >> >> When a new WG draft is adopted, the WG chairs and the Routing >> Directorate Coordinators discuss and agree on possible Document >> Mentors (up to 3). Then the Routing Directorate Coordinator >> confirms with the Routing Directorate members about their >> availability and willingness to mentor this particular draft. Once >> one is selected, the Routing Directorate Coordinator updates the >> wiki and notifies the WG chairs and draft authors. >> >> a) With the agreement of the ADs, a Document Mentor who is not a >> member of the Routing Directorate may be selected. >> >> b) The WG chairs can, after consulting with the draft authors, >> decline to have a Document Mentor. >> >> c) The Document Mentor should coordinate with the Document >> Shepherd for hand-off after WGLC. >> >> >> > From nobody Mon Mar 31 09:22:16 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CE91A0893; Mon, 31 Mar 2014 09:22:00 -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 VSkJ0Ex9zxe9; Mon, 31 Mar 2014 09:21:53 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 666931A0892; Mon, 31 Mar 2014 09:21:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 889B42412A7; Mon, 31 Mar 2014 09:21:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 82DE62411D1; Mon, 31 Mar 2014 09:21:41 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 31 Mar 2014 18:21:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <0246663B-D112-489E-B060-5686253C98E7@thomasclausen.org> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/8jCUuVyN4lnMnNulGt_1--W98bY Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:22:01 -0000 On 31 Mar 2014, at 18:19, Jamal Hadi Salim wrote: > Hi Thomas, >=20 > On Mon, Mar 31, 2014 at 10:18 AM, Thomas Clausen > wrote: >=20 >=20 >> Personally, I am grateful enough for the work that was done by others = in building the Internet, and the help I got from elder IETFers when I = started in the IETF, to want to "pay it forward" a bit, as best I can. >>=20 >=20 > I understand and empathize. >=20 > [sorry, snipping through rest of text] >=20 >>=20 >> Essentially, you say that you prefer "spending time evaluating and = rejecting a kernel-patch on submission" than >"spending time making sure = that submitted kernel-patches are good". >>=20 >=20 > Yes, because it has been proven to scale better. > I realize this approach is open to abuse as well - but thats a > different socio-economic > discussion. >=20 >=20 >> Well, I disagree there, I think at WG adoption is the right time. = Just before shepherding step is (for >> all intents and purposes) the same as during IETF LC. >>=20 >=20 > Ok, i will agree to disagree ;-> >=20 Fair enough, and perhaps we're both needed: I'll volunteer for the early = mentoring, and you get to be the showstopper? :) Cheers, Thomas > cheers, > jamal From nobody Mon Mar 31 09:27:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E41A6F22; Mon, 31 Mar 2014 09:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.783 X-Spam-Level: X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 co0Zv1jlF-1d; Mon, 31 Mar 2014 09:27:51 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8CE1A6F14; Mon, 31 Mar 2014 09:27:51 -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 s2VGRjLo023476; Mon, 31 Mar 2014 17:27:45 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VGRhOb023448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 17:27:44 +0100 From: "Adrian Farrel" To: Date: Mon, 31 Mar 2014 17:27:44 +0100 Message-ID: <022001cf4cfe$25fd5fc0$71f81f40$@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: Ac9M/iD4IE2H4j8CQBCtnHo5w4RK/w== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20602.000 X-TM-AS-Result: No--10.511-10.0-31-10 X-imss-scan-details: No--10.511-10.0-31-10 X-TMASE-MatchedRID: mVgEJzmU0frzLVZFOZrw3hes/RxhysDbFJFr2qlKix9V84HrPxCfbDMB KS/l5ik348guxdxp7TNRS7xjEb+dxBDuooXos5VesyNb+yeIRApK0YCCYqpa5WrhyhOS2sZfH4K EMeoXL42pwFIHOgOkued3pyPFrS5NDPcQ8d9u8CjPmshbRFtLmKlLUhyBHY5VpdltGKiWi0X/89 8ll77v0FARYuGRJCWsZglrOek4r3enL17LOfosqtPNaYYJeRf5mGSSol4Uei3kMnUVL5d0E5BC/ Jexu7qkctp4k2S63CH6XP0KNPsN+8g10rLpRC19jWe5HOFKvuMKajiKVoihqU+0uGVOF08Qsfhy a0bmQlnOUluAtapGmFWZ0OFrtGDS7vfqpNCsVOri3aa5wOREEQ9EjwhJIvFicmvfzvLIdjARj9Y /8jRVH2vPPHhz/E48jenw2507tJ9Nfs8n85Te8v7E6GNqs6ce3QfwsVk0UbtuRXh7bFKB7pK/5o 0YiKu9dr3SxN4ays+A0n+XPU8CJs9JcXGZZeHOHIV02d1rpG8= Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/3ZfiOnSI8CP3sh1mcz4D7yRJ-Jw Cc: rtg-dir@ietf.org, pwe3@ietf.org Subject: [RTG-DIR] Danny McPherson's Rtg-Dir review of draft-ietf-pwe3-p2mp-pw-requirements X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:27:53 -0000 draft-ietf-pwe3-p2mp-pw-requirements Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other comments that you receive, and strive to resolve them through discussion or by updating the draft as appropriate. Document: http://tools.ietf.org/html/draft-ietf-pwe3-p2mp-pw-requirements-07 Reviewer: Danny McPherson Review Date: March 31, 2014 Intended Status: Informational Document Overview: This document presents a set of requirements and a framework for providing a P2MP PWs over MPLS PSNs. A P2MP PW is a mechanism that emulates the essential attributes of a P2MP telecommunications service such as a P2MP ATM VC over a PSN. The I-D describes the general architecture for P2MP PWs with a reference model, discusses data encapsulation, and outlines specific requirements for setup and maintenance of P2MP PWs, with a focus only on Single-Segment PWs. This version was lasted updated in February of 2014, although it has existed as a PWE3 WG document since March 2009, and as an individual contribution (draft-jounay-pwe3-p2mp-pw-requirements) since February of 2007. Among other applications, it provides primitives that can be employed for Virtual Private LAN and Virtual Private Multicast services, such as those specified in the L2VPN WG. I have no substantial concerns with this document. There are several comments and nits below. 1. I am not sure if from an IPR perspective the claims regarding IPR that apparently no longer apply to this version of the document need to be explicitly acknowledged as such by the relevant co-authors? Nits === General: 1. Only single-segment PWs are addressed, not multi-segment PWs. I understand why this is the case currently although I wonder if the requirement akin to "a single NMS" such as provided in S.4 should be conveyed forward? I suppose it should simply be out of scope. 2. In order to align with descriptive text in S3.1 it might be useful if the Reference Model in Figure 1 depicted where root and leaf PEs reside in the topology, and perhaps also that multiple CEs could be downstream from a single leaf PE (the latter point Farrel made in his AD review as well, IIRC). --- S 3.2: - A single P2MP PSN tunnel MUST be able to serve more than one P2MP PW traffic in an aggregated way, i.e., multiplexing - "not destined to Leaf PE at the service layer." reads a bit odd and ambiguous, might use a bit of expansion. --- S 3.4.6: - "In the example depicted below, a standby P2MP PW is used to protect the active P2MP." -- might consider adding a "PW" after the last P2MP in this sentence. - It might be useful to identify the "leaf" and "root" layer in Figure 3 & 4 as well. From nobody Mon Mar 31 09:30:13 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D41A6F20 for ; Mon, 31 Mar 2014 09:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 aNcaypVqg9aG for ; Mon, 31 Mar 2014 09:30:07 -0700 (PDT) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id D06201A6EFE for ; Mon, 31 Mar 2014 09:30:07 -0700 (PDT) Received: by mail-pa0-f46.google.com with SMTP id kx10so2929871pab.19 for ; Mon, 31 Mar 2014 09:30:04 -0700 (PDT) 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=tu8mRMGTOw0VgA4bctWbPl5WBCkHMVpLWlk9onaZYg8=; b=cZ/tWNPyJ7NnVaUaCt8leQXtBl9RPkolF6yGROeHvVdUVfdtmtZEHsi3tHNrYDZtYZ SXlal7EsfzwnpxMF3/TBq/rNux9kOpcZ8N7Ssfj4UHPTBSTBp32gnoYmV8qVy2evNT0l onYzYbWSCn+hImtEv+hnDzlURIvnyXBC3GIxzG03SVXmcilaPd9YRT2/tFCLtcUq0Q6U HuY9giyDQbx7Ee298d8npr/lOi7EByMyWPl2eZuH8aCAfhv3bXjCtBbp8LbYFJXAjGWi Bp+qjTguurYn0nOi2/TX4SMuypNSrOK7VAL8jkK8bzlAZlacYc8/6vRlcEAS7jvE3Qcx JfMA== X-Gm-Message-State: ALoCoQkUVR0Oxq77k8O9KwlxjGEnfrqmmg+R6Im9MrnQ4UwG7qBYBgvUZ1zPlKRv+EwRQlYYW5bm X-Received: by 10.66.136.103 with SMTP id pz7mr4767561pab.140.1396283404725; Mon, 31 Mar 2014 09:30:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.11.234 with HTTP; Mon, 31 Mar 2014 09:29:44 -0700 (PDT) In-Reply-To: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <0246663B-D112-489E-B060-5686253C98E7@thomasclausen.org> From: Jamal Hadi Salim Date: Mon, 31 Mar 2014 12:29:44 -0400 Message-ID: To: Thomas Clausen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/KKG8BFlXwmIjkV-938zs04aDdoc Cc: Adrian Farrel , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:30:09 -0000 On Mon, Mar 31, 2014 at 12:21 PM, Thomas Clausen wrote: > Fair enough, and perhaps we're both needed: I'll volunteer for the early mentoring, and you get to > be the showstopper? :) > We are making progress and I dont want to be a showstopper for this discussion ;-> cheers, jamal From nobody Mon Mar 31 09:34:07 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD491A6F22; Mon, 31 Mar 2014 09:34:06 -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 rVTbxFapFnt1; Mon, 31 Mar 2014 09:34:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1EA1A6F11; Mon, 31 Mar 2014 09:34:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 571C02459E2; Mon, 31 Mar 2014 09:33:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A02C82403C5; Mon, 31 Mar 2014 09:33:56 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 31 Mar 2014 18:33:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/2Pv5Y3XXy6_Dhzl1czKd6FJz_Ng Cc: "Les Ginsberg \(ginsberg\)" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:34:06 -0000 On 31 Mar 2014, at 18:21, Jamal Hadi Salim wrote: > Resubmit after mentoring may scale better. But i think you hit the > nail on the head with: > "But I think what we are trying to address may go beyond simply > editorial/grammatical issues" >=20 > Often the bad drafts require a total rewrite. >=20 In which case, that may *exactly* be what the WG chairs need to have an = outsider to say in public: "I've read this I-D as part of I find the ideas to be interesting, but the use of FOO to do = BAR violates all known architectural principles, and the laws of physics. Also, language issues renders the document really, really hard = to read for non-klingons I would recommend that the authors discuss how they intend to = do BAR without violating the laws of physics and, if successful, that = we look at if the WG has somebody willing to help out with the language = issues" Short and easy and helpful.=20 Of course, it may turn out that it is such a great idea that you'll = *want* to be the person helping out with the language issues, to be able = to claim contribution to it later - excellent, also, that WG just gained = a very experienced participant. I'm known as a chronic pessimist, and I really can't see any downsides = here. Thomas > cheers, > jamal >=20 > On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (ginsberg) > wrote: >> The way I read what is proposed below is that all documents will be = assigned a mentor. Perhaps that is not what you intended - but it does = seem to read that way. And as others who have replied to this have = suggested that doesn't make sense for all documents and doesn't scale = well. Also, the stated process introduces mentoring AFTER a document is = adopted as a WG item. IMHO this is too late. >>=20 >> What I would suggest is that there become three options available for = a WG to choose when a document is proposed as a WG item: >>=20 >> 1)Accept >> 2)Reject >> 3)Resubmit after mentoring >>=20 >> The third category is reserved for documents which the WG feels have = an idea/solution which might be worth the WG group's time, but the = current "quality" of the document is such that meaningful discussion = would be hindered. >> The authors are free to reject the offer of mentoring in which case = the document is rejected. >>=20 >> This limits the time/effort on the part of the mentors to a smaller = number of documents and only for ones that are actually worth the time. = Also, it means the time of the entire WG is not wasted on discussions = that might be unnecessary if the draft presentation were improved. >>=20 >> That said, the danger I see here is that in some cases it will be = very hard for a mentor to provide meaningful feedback without also = commenting on the guts of the solution. If the only issue is "grammar", = then not a concern. But I think what we are trying to address may go = beyond simply editorial/grammatical issues in some cases and then it is = not clear to me how one separates "mentoring" from "authorship". >>=20 >> Les >>=20 >>=20 >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian = Farrel >>> Sent: Monday, March 31, 2014 5:12 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Subject: [RTG-DIR] Document Mentors >>>=20 >>> Hi, >>>=20 >>> One of the ideas to come out of the recent discussions is appointing = a mentor >>> per document from the time it is adopted by a Routing Area working = group >>> until >>> it completes WG last call. >>>=20 >>> This would be voluntary in two dimensions: >>> - the WG chairs would need to deem that one would be beneficial >>> - we would have to find someone from the Directorate willing to >>> take on the document. >>>=20 >>> We don't think that technology expertise is as useful in this as = IETF clue >>> and >>> general routing experience. >>>=20 >>> So, to take this forward we would need: >>> - WG chairs to say "Yes, we can see that that would have >>> potential benefit >>> - Directorate members to say "Yes, we could take on that >>> additional work. >>>=20 >>> Alia and I have put together some preliminary notes on how this = would all >>> hang >>> together. >>>=20 >>> Your opinions and rotten fruit are solicited. >>>=20 >>> Thanks, >>> Adrian and Alia >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Document Mentors in the Routing Area >>>=20 >>> The Problems: >>>=20 >>> a) Drafts get little review outside the working group and sometimes = inside >>> the working group until after working group last call. At that = point it is >>> often >>> painful and costly to make meaningful improvements to the drafts. >>>=20 >>> b) Authors may not know how or whom to ask for assistance or = review >>> (e.g., IANA section, Security Section, Operational and Management >>> considerations, details of a protocol, etc. ). >>>=20 >>> The Goals: >>>=20 >>> a) Excellent and consistent review at WG adoption and before WG = last >>> call. >>>=20 >>> b) Ability for prolonged discussion and problem-solving when the >>> draft can still be easily enhanced. >>>=20 >>> c) Reduced time to delivery of RFCs. >>>=20 >>> d) Quality documents. >>>=20 >>> The Solution: >>>=20 >>> A per-document mentor who is a known neutral party to whom the >>> authors can go for advice on: >>> - how to write a section >>> - specific issues that arise >>> - ways to resolve conflicts. >>>=20 >>> The document mentor also watches the progress of the document >>> and gives advice and steerage. >>>=20 >>> It is not assumed that every document will need or benefit from >>> having a mentor. >>>=20 >>> The Expected Workload: >>>=20 >>> The routing directorate has approximately 40 people. If we assume >>> that approximately 50 drafts pass WG adoption and a similar number >>> pass WGLC each year, then the load is 2.5 documents per person >>> per year. If we assume that there are about 200 WG drafts in the >>> Routing Area and that they all have mentors, then each Routing >>> Directorate member will have 5 drafts that she or he is mentoring. >>>=20 >>> The Supporting Data Artefacts: >>>=20 >>> a) As part of the Routing Area wiki, the areas of knowledge for >>> each member of the Routing Directorate will be publicly specified. >>> This is added to the wiki by the Routing Area Coordinators (or AD) >>> when the member joins the Routing Directorate, updated by the >>> member while he or she is on the Directorate, and updated by the >>> Routing Area Coordinators (or AD) if and when the member's term >>> renews. >>>=20 >>> b) Document Mentor Availability and Assignments: As part of the >>> Routing Area wiki, each Directorate member will specify the = maximum >>> number of documents that he or she is able to mentor. Also listed >>> will be the list of mentored documents (and a count). >>>=20 >>> i) When a Directorate member is assigned as the Document >>> mentor, the Routing Directorate Coordinator will update the >>> wiki page and create a wiki page for the draft. >>>=20 >>> ii) When a Document Mentor provides a review, that should be >>> stored in the draft's wiki page along with the resolutions. >>>=20 >>> iii) When the Document Mentor's final review at WGLC is done, >>> the Document Mentor should move the draft to a list of >>> "previously mentored documents" associated with their name. >>> It is ideal to write up a summary of the document mentoring >>> experience. >>>=20 >>> c) Unmentored Documents: Drafts which have declined a document >>> mentor should be listed on a wiki page. >>>=20 >>> d) For each WG's wiki, it'd be useful to have the list of drafts >>> with their associated Document Mentors (or lack thereof) and the >>> link to the draft's wiki page. >>>=20 >>> The Basic Process: >>>=20 >>> When a new WG draft is adopted, the WG chairs and the Routing >>> Directorate Coordinators discuss and agree on possible Document >>> Mentors (up to 3). Then the Routing Directorate Coordinator >>> confirms with the Routing Directorate members about their >>> availability and willingness to mentor this particular draft. Once >>> one is selected, the Routing Directorate Coordinator updates the >>> wiki and notifies the WG chairs and draft authors. >>>=20 >>> a) With the agreement of the ADs, a Document Mentor who is not a >>> member of the Routing Directorate may be selected. >>>=20 >>> b) The WG chairs can, after consulting with the draft authors, >>> decline to have a Document Mentor. >>>=20 >>> c) The Document Mentor should coordinate with the Document >>> Shepherd for hand-off after WGLC. >>>=20 >>>=20 >>>=20 >>=20 >=20 From nobody Mon Mar 31 09:35:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37941A088C; Mon, 31 Mar 2014 09:35:08 -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 qrskOnXF5vWu; Mon, 31 Mar 2014 09:35:07 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id A95B71A6F11; Mon, 31 Mar 2014 09:35:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id CB3E0240462; Mon, 31 Mar 2014 09:35:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 5CA83245AB3; Mon, 31 Mar 2014 09:35:01 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: Date: Mon, 31 Mar 2014 18:34:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8536B946-B1CC-4A6C-BF37-F7B4307921C0@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <0246663B-D112-489E-B060-5686253C98E7@thomasclausen.org> To: Jamal Hadi Salim X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/20o3n4cXU6XMJi8cNgpb0QL4ZMA Cc: Russ White , Adrian Farrel , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:35:09 -0000 On 31 Mar 2014, at 18:29, Jamal Hadi Salim wrote: > On Mon, Mar 31, 2014 at 12:21 PM, Thomas Clausen > wrote: >=20 >> Fair enough, and perhaps we're both needed: I'll volunteer for the = early mentoring, and you get to >> be the showstopper? :) >>=20 >=20 > We are making progress and I dont want to be a showstopper for this > discussion ;-> >=20 Alright, and I will add an acknowledgement to Russ White - I think that = we're all winners. So, ADs, when do we get our documents assigned? ;) Thomas >=20 > cheers, > jamal >=20 From nobody Mon Mar 31 09:36:03 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DFB1A6F21 for ; Mon, 31 Mar 2014 09:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.284 X-Spam-Level: X-Spam-Status: No, score=-97.284 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_52=0.6, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 SJTYgq18iPjN for ; Mon, 31 Mar 2014 09:35:56 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C01A31A088C for ; Mon, 31 Mar 2014 09:35: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 s2VGZpnP011464; Mon, 31 Mar 2014 17:35:51 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VGZnlh011450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 17:35:50 +0100 From: "Adrian Farrel" To: "'Thomas Clausen'" , References: <9C91CB2D-CD30-420A-AB2A-17D0BD9E0271@thomasclausen.org> In-Reply-To: <9C91CB2D-CD30-420A-AB2A-17D0BD9E0271@thomasclausen.org> Date: Mon, 31 Mar 2014 17:35:49 +0100 Message-ID: <022d01cf4cff$479d8230$d6d88690$@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: AQHQzjRdmW9SzxufXeddYVAIkmQn0Zr4YN6A Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.0.0.1014-20602.000 X-TM-AS-Result: No--25.542-10.0-31-10 X-imss-scan-details: No--25.542-10.0-31-10 X-TMASE-MatchedRID: IeZYkn8zfFqnykMun0J1wpmug812qIbzQKuv8uQBDjrjsTquy0JRiwNZ o8cTWaabqQrLlzcBA6ZY03RiAPqCiGLlyFKFb1usV6uR7UoeQuQyGiaSs0n67HoZ5YK74mUQwua niM9QXy3njmT3vqmhOSU5tQITRM6/7K35r0y1/55T46Ow+EhYONm8AwVxRR82a0TOsL14A2nrsK EHnvlV0d9J2PHe9WriiFiCrpKl7hhjDV//SvkH3u9VsdrlGzy3QZXZg2I8JaaQxjD98JXG43L8G 4Ulnt0YHSsQg5H6KdNr1BESThbQntaSgJLPelTmw69AIwXJn0b1ahp4ynaXP+QydRUvl3QTyxDK WChexUQgLwFg0TFmLtVFNAHkCCVeGTxeaHT3DFIItCy6ZX/lL7PksiHb4g58cmvfzvLIdjDdrNG eD0EJ6+0rBXwkT03SCUcmcggLHVADvBbgGUUkWDIHIyLCTr7eJPNIV6GF8muVEMx1gSjhQOvcUJ 70Xg3x1JrkdG2EFRVIZBLkJWJVT3CDdBTw31/Ih2VzUlo4HVOC7C2rJeUToVmmz7LVVfOpCP8Qw 3pU8EBlqZcf9RkvX4YOeJHX61tVqm7tdfUNKffhuXUWQoMQtx1BLI8ZvqYInit3Tv6ke8AAP1kZ z+gB2pDikXX1HWizHvdtNsROZVLaMekfo32NI//q7MbXs5JTTJDl9FKHbrn9Ez/5IpHqpx8+XHE TeZCzLtwgfoBNF47TqOkW1KaAKRaTj8lkRWbAkPoFsM336M4h9mNF8ZPJ2IfAYSb4KlgZgwP1sc Wk/OFnAnjpwtXsHysBf2BUI+4rCmQ5C5CWatSeAiCmPx4NwJXxsKTUj1Z+vqq8s2MNhPDPPeN6H N6d7Ku6xVHLhqfxvECLuM+h4RB+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/2kHF20XZlIFFQQs2Awv2IPCqolw Cc: rtg-dir@ietf.org, draft-avula-shwmp.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-avula-shwmp-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:35:59 -0000 Thanks Thomas for a thorough job. I read your review as not saying that there is any conflict with existing IETF Rtg Area work, or that this document would damage Internet routing per se. But I also see a lot of substantial technical work that the authors could pay attention to, and a strong question that I should put to the ISE about why he would publish this instead of referring it to the IEEE. Is that a fair summary? Cheers, Adrian > -----Original Message----- > From: Thomas Clausen [mailto:thomas@thomasclausen.org] > Sent: 31 March 2014 17:18 > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org; draft-avula-shwmp.all@tools.ietf.org > Subject: RtgDir Review: draft-avula-shwmp-01 > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. The > Routing Directorate seeks to review all routing or routing-related drafts as they > pass through IETF last call and IESG review, and sometimes on special request. > The purpose of the review is to provide assistance to the Routing ADs. For more > information about the Routing Directorate, please see > http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion or by > updating the draft. > > Document: draft-avula-shwmp-01 > Reviewer: Thomas Heide Clausen > Review Date: 2014/03/31 > IETF LC End Date: Unknown > Intended Status: Experimental > > Summary: > > o I have significant concerns about this document and recommend > that the > Routing ADs discuss these issues further with the authors. > > Comments: > > The document is actually hard to review. I happen to know HWMP and > IEEE802.11s better than > I am proud to admit in public, which helps a little - but, setting this aside, it > is clear that this > specification is written for somebody knowing at least as much about IEEE > 802.11s as the authors. > > The document was briefly discussed in the MANET working group, the > relevant thread can be found here: > > http://www.ietf.org/mail- > archive/web/manet/current/msg15943.html > > > The document could do with an editorial pass to clean up some language- > related issues which, > occasionally, renders the text ambiguous. I am not a native English > speaker myself, so far be > it for me to be overly critical, but I had a hard time parsing every other > sentence in section 3, for > example. > > Finally, I am not a security expert; I am raising things that I encounter and > according to my > understanding of security, but it probably would be wise to have a careful > review from > security folks also. I do believe that the approach chosen is certainly not > evolutive, and > that - to me - is a show-stopper. > > The status of this document is "experimental" and, as such, it should > encourage "experiments". > The RTG ADs generally request a section documenting "what is the > experiments that this > document is supposed to enable?", and I see none. > > This document relates to an IEEE developed L2 protocol, and is an > independent stream submission. > > At the very least, given that we do not know what the interaction > between this protocol, and other > IEEE 802.11 protocol components, some text in an applicability statement > should disclaim that > this protocol should operate only in a well-defined and confined area on > the edge of the Internet. > > > Major Issues: > > o This document proposes a security mechanism for HWMP, the > mesh-under routing protocol developed by > the IEEE for IEEE 802.11 networks. I see several issues with this: > > - The IETF does not, typically, design or publish L2 > protocols. I wonder if > it is not more beneficial to bring this work to the relevant > groups of the IEEE? > I do not believe that it is the mandate of the IETF or the > RFC series to > maintain and update IEEE specifications. > > - In case there is an explicit reason why the authors have > brought this to > the IETF, such as heavy reliance on L3 or higher > mechanisms/protocols, > this should be called out explicitly in the document. While > I do not want to be > a "pedant for formalities", I'd have expected an > "applicability section" or something > in the document, which explained this. > > o The IEEE 802 suite of specifications already contains a sizeable > amount > of efforts on security, and IEEE 802.11s (from which HWMP > originates) did work > on security. It is actually unclear what exactly the extension to > HWMP, presented > in this specification, brings that is not already covered. In other > words, it is not convincing > in which way an IEEE 802.11s deployment with HWMP is > vulnerable, but where SHWMP > is invulnerable. > > o Continuing on from that, "external attacks", apparently, are > something that end-to-end > encryption schemes can prevent, and this is what (according to > the authors) IEEE 802.1x > offers (section 2.1). It is not clear what an "external attack" is...is > this a matter of > a (non-participating) device being able to intercept data traffic, or > is this a matter of a > (not-participating) device being able to inject HWMP control > traffic into the network, and > to thereby disrupt it? > > o This document is not including the usual RFC2119-terminology > disclaimer; in > addition, it leaves many - if not most - of the used terminology > undefined. To give an > example "internal attack" vs "external attack". > > o Section 2 states: > HWMP is the basic > routing protocol of a WMN and this paper discusses the > protection of > HWMP routing messages but not the data messages. > > Which is materially wrong. HWMP is the basic routing protocol in > IEEE 802.11s; > there're many other mesh routing protocols out there, many of > which are widely > deployed. > Also, this is not a "paper", but a protocol specification. > > o As with "external attacks", it is not clear either what the "internal > attacks" that the authors > assert that SHWMP protects against are. Section 2.1: > > The major problem that is plaguing the WMNs is the > detection of > internal attacks. Internal attacks might involve > modification of > contents of the HWMP frame such as hop count and air > time metric. > > I am not sure that wireless mesh networks are "plagued" by this, > but that aside...would that > not imply that somehow admission to the network has been > granted (cryptographic material/key > provided) to somebody, who then turns around and then > "attacks" the network? If so, then > my initial reaction would be that if detected, the right approach > would be to revoke the keys > issued to the "badly behaving device". It is not clear how SHWMP > interacts with any key > management and revocation functions in an IEEE 802.11 network. > > o Continuing through section 2.1, essentially what this document is > saying is: > > o It's easy to protect protocol signals which are > immutable, or to > protect immutable fields in protocol signals, > against tampering > > o It's problematic to protect mutable fields in > protocol signals, against > tampering > > o ....but, it's important to do so. > > While one might not take huge issues with the first two, the third > doesn't follow. > What is missing, IMO, is some sort of problem statement, > including a security > analysis. If a mutable field is tampered with, how does that hurt? > Will the system > break down? Perform a little worse? A lot worse? > > This section ends by saying: > > However, > the fields that get changed is quite important to > provide link-to- > link based security so that every node along the > journey should > authenticate the frame before passing it on. > This ensures that the > contents of the frame are not modified and the > frames can get dropped > if they are modified. > > Three things. > > 1) The language is ambiguous: "The fields that get > changed [by whom? > intentionally or the attacker] is [should be are] > quite important to provide > link-to-link based security [so, is the important bit > that "The value of the fields > is what HWMP uses fir providing link-to-link based > security"? Or, is the important > bit that these fields are not changed, and the > security mechanism should prevent > this] [also, what is link-to-link base security]? > > 2) OK, so I understand: the goal is to provide hop- > by-hop authentication of a frame. > That implies a specific trust model of the form "I > trust my neighbor to only trust > neighbors that I would also have trusted", which > is not documented. Is that model > valid in this type of networks? > > 3) If 3) is indeed is a valid trust model, what does the > solution proposed actually > do? If my neighbor has the right cryptographic > material to generate the > signatures needed, then he can tamper with any > and all fields, unchallenged and > undetected. In other words, is this approach > protecting against the "internal > attacks" intended? > > o But then I read on to section 2.2, and to my surprise see that > what I had identified in 2.1 > was not at all true - at least, it doesn't read that way. Section 2.2 is > entitled "Security > features of Secure HWMP", but reading that - after having read > 2.1 - I still want to understand > the (at least, abstract) answers to four simple questions: > > a) What are the identified vulnerabilities of HWMP, > which SHWMP patches? > b) What is the trust model assumed? > c) How does that trust model match actual > deployments? > d) How does SHWMP integrate with IEEE 802 > security mechanisms, key mgmt, ...? > > > o Section 3, I believe that before starting to discuss the extension, a > presentation of > HWMP would be in order, at least the necessary details for the > reader to understand the > rest of the document. As it is, it is understandable to those who > have a pretty good idea > of the functioning of HWMP only. As it is, and after reading > section 3, I would suggest > that the reader is as confused as to what HWMP is, what SHWMP > does, and how. > > o Section 3, 4 I believe that the bulk of the HWMP terminology > used should actually, > be defined in the terminology section - and that the terminology > section therefore > belongs before Section 3. > > o Section 3, and section 6.1: > > o what does it mean that the "source node signs > the non-mutable fields"? > > How are the signatures generated, how are mutable fields > treated (Zeroed out? Removed? Something else?) > > o Section 5 is missing definition of which byte-order, bit-order is > used, as well as for > each field what format (unsigned integer, ...) the values are in. > > o Section 5 is missing some discussion as to how these messages > are intended to be included in the > frame format of IEEE 802.11. Does that format already have a > mechanism for protocol extensions? > If so, does the format for these extensions "fit in"? How? > Are there any requirements for code-point reservations with the > IEEE? Have those been made? > How will those be made? Will experimental code-points from IEEE > maintained registries be used? > > o I am not sure if the last sentence on page 10 in section 5.5 > should/does not mark the start > of a new paragraph. It seems to talk about "all the message > types" and not just the GANN message type > described immediately previously. > > o Generally, and specifically to section 6, it might be good to > provide a reference to HWMP, > which SHWMP is extending; > it is not enough to simply cite the IEEE standard. If I was to > implement this, I would want > to know more, including: > o Which specific parts of the (voluminous) 802.11 > standard need I study? > o Which specific processing steps need I to > interface with, iow., the operations > described in this specification are to be done > before/after which steps in which > process in which section of IEEE 802.11 > > As it is, I could not implement this proposed extension to SHWMP > in a fashion where I would > be sure to (i) do it right, and (ii) do it in a way that would be > interoperable with somebody elses' > implementation. > > o As this is a security document, I would expect a complete and > strong security considerations section. > As indicated in the above, I believe that - at least - what is missing > is: > > o Relationship to 802.1x and other 802 security > mechanisms > o Trust model > o Protections offered > o Specifically, protections not offered > o Limits of cryptographic methods recommended > o Ability to evolve - threats on networks tend to > not be static > > o I have a MAJOR-MAJOR issue related to the cryptological tools > used. I am not enough of an > expert in crypto to know which exact parameters are required to > be carried around for each > algorithm, but.....for example, key indices, which parameters of a > curve, or a function, are to > be used, ..... -- all of which seems to be not specified, and > perhaps should not be specified > as it is part of some 802 security framework....but, in that case, it > most certainly should be > discussed. > > What I know, however, is that a cryptographic method that's > "good" today is "worthless" > a few years, or even months, hence. I see no codepoints allowing > identifying which > (say) of RSA, DES, HMAC, ECDSA, AES, .... and whatever the > future brings, is used? > Same for hash functions....not long ago md5 was used, today it's > definitely not.... > > At the very least, I would expect an IANA registry set up (or, > references to an 802 registry) > recording code-points for different algorithms - and the > messages to contain fields for > indicating which hash/crypto function to use. > > Minor Issues: > > > > Nits: > > o I believe that it would behove the document if the abstract called > out where HWMP has > come from, especially as it is not an IETF protocol, or even a L3 > protocol > > o References are not split up in Normative and Informative > references, and (FWIW) are not formatted > in the usual fashion. > > > o Section 3, 2nd paragraph: I believe that it would be beneficial to > split this up in several independent > paragraphs or, perhaps, an enumerated list. I ended up making > the latter on a piece of paper to not > get lost in the description. > > Respectfully, > > Thomas From nobody Mon Mar 31 09:42:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A273B1A6F28 for ; Mon, 31 Mar 2014 09:41:57 -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_52=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 Rro8Ro1I9vRh for ; Mon, 31 Mar 2014 09:41:54 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id E6A741A088C for ; Mon, 31 Mar 2014 09:41:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 12E04245AB5; Mon, 31 Mar 2014 09:41:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 91B4B245AB3; Mon, 31 Mar 2014 09:41:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <022d01cf4cff$479d8230$d6d88690$@olddog.co.uk> Date: Mon, 31 Mar 2014 18:41:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3D644A71-1C56-4759-B983-C9AEDD391478@thomasclausen.org> References: <9C91CB2D-CD30-420A-AB2A-17D0BD9E0271@thomasclausen.org> <022d01cf4cff$479d8230$d6d88690$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/OTQs-b-u2zWb259IUdvY_JZUdx8 Cc: "" , draft-avula-shwmp.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir Review: draft-avula-shwmp-01 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:41:57 -0000 Adrian, Your summary is fair. Essentially, this is an extension to a L2 protocol. By definition, = there's therefore no conflict with existing IETF RTG Area work. I would = vividly recommend the ISE to refer the work to the IEEE. Thomas On 31 Mar 2014, at 18:35, Adrian Farrel wrote: > Thanks Thomas for a thorough job. >=20 > I read your review as not saying that there is any conflict with = existing IETF > Rtg Area work, or that this document would damage Internet routing per = se. But I > also see a lot of substantial technical work that the authors could = pay > attention to, and a strong question that I should put to the ISE about = why he > would publish this instead of referring it to the IEEE. >=20 > Is that a fair summary? >=20 > Cheers, > Adrian >=20 >> -----Original Message----- >> From: Thomas Clausen [mailto:thomas@thomasclausen.org] >> Sent: 31 March 2014 17:18 >> To: rtg-ads@tools.ietf.org >> Cc: rtg-dir@ietf.org; draft-avula-shwmp.all@tools.ietf.org >> Subject: RtgDir Review: draft-avula-shwmp-01 >>=20 >> Hello, >>=20 >> I have been selected as the Routing Directorate reviewer for this = draft. The >> Routing Directorate seeks to review all routing or routing-related = drafts as > they >> pass through IETF last call and IESG review, and sometimes on special = request. >> The purpose of the review is to provide assistance to the Routing = ADs. For > more >> information about the Routing Directorate, please see >> http://www.ietf.org/iesg/directorate/routing.html >>=20 >> Although these comments are primarily for the use of the Routing ADs, = it would >> be helpful if you could consider them along with any other IETF Last = Call >> comments that you receive, and strive to resolve them through = discussion or by >> updating the draft. >>=20 >> Document: draft-avula-shwmp-01 >> Reviewer: Thomas Heide Clausen >> Review Date: 2014/03/31 >> IETF LC End Date: Unknown >> Intended Status: Experimental >>=20 >> Summary: >>=20 >> o I have significant concerns about this document and = recommend >> that the >> Routing ADs discuss these issues further with the = authors. >>=20 >> Comments: >>=20 >> The document is actually hard to review. I happen to know HWMP = and >> IEEE802.11s better than >> I am proud to admit in public, which helps a little - but, = setting this > aside, it >> is clear that this >> specification is written for somebody knowing at least as much = about > IEEE >> 802.11s as the authors. >>=20 >> The document was briefly discussed in the MANET working group, = the >> relevant thread can be found here: >>=20 >> http://www.ietf.org/mail- >> archive/web/manet/current/msg15943.html >>=20 >>=20 >> The document could do with an editorial pass to clean up some = language- >> related issues which, >> occasionally, renders the text ambiguous. I am not a native = English >> speaker myself, so far be >> it for me to be overly critical, but I had a hard time parsing = every > other >> sentence in section 3, for >> example. >>=20 >> Finally, I am not a security expert; I am raising things that I > encounter and >> according to my >> understanding of security, but it probably would be wise to have = a > careful >> review from >> security folks also. I do believe that the approach chosen is = certainly > not >> evolutive, and >> that - to me - is a show-stopper. >>=20 >> The status of this document is "experimental" and, as such, it = should >> encourage "experiments". >> The RTG ADs generally request a section documenting "what is the >> experiments that this >> document is supposed to enable?", and I see none. >>=20 >> This document relates to an IEEE developed L2 protocol, and is = an >> independent stream submission. >>=20 >> At the very least, given that we do not know what the = interaction >> between this protocol, and other >> IEEE 802.11 protocol components, some text in an applicability = statement >> should disclaim that >> this protocol should operate only in a well-defined and confined = area on >> the edge of the Internet. >>=20 >>=20 >> Major Issues: >>=20 >> o This document proposes a security mechanism for HWMP, = the >> mesh-under routing protocol developed by >> the IEEE for IEEE 802.11 networks. I see several issues = with > this: >>=20 >> - The IETF does not, typically, design or publish = L2 >> protocols. I wonder if >> it is not more beneficial to bring this work to = the > relevant >> groups of the IEEE? >> I do not believe that it is the mandate of the = IETF or > the >> RFC series to >> maintain and update IEEE specifications. >>=20 >> - In case there is an explicit reason why the = authors have >> brought this to >> the IETF, such as heavy reliance on L3 or higher >> mechanisms/protocols, >> this should be called out explicitly in the = document. > While >> I do not want to be >> a "pedant for formalities", I'd have expected an >> "applicability section" or something >> in the document, which explained this. >>=20 >> o The IEEE 802 suite of specifications already contains a = sizeable >> amount >> of efforts on security, and IEEE 802.11s (from which = HWMP >> originates) did work >> on security. It is actually unclear what exactly the = extension > to >> HWMP, presented >> in this specification, brings that is not already = covered. In > other >> words, it is not convincing >> in which way an IEEE 802.11s deployment with HWMP is >> vulnerable, but where SHWMP >> is invulnerable. >>=20 >> o Continuing on from that, "external attacks", apparently, = are >> something that end-to-end >> encryption schemes can prevent, and this is what = (according to >> the authors) IEEE 802.1x >> offers (section 2.1). It is not clear what an "external = attack" > is...is >> this a matter of >> a (non-participating) device being able to intercept = data > traffic, or >> is this a matter of a >> (not-participating) device being able to inject HWMP = control >> traffic into the network, and >> to thereby disrupt it? >>=20 >> o This document is not including the usual = RFC2119-terminology >> disclaimer; in >> addition, it leaves many - if not most - of the used = terminology >> undefined. To give an >> example "internal attack" vs "external attack". >>=20 >> o Section 2 states: >> HWMP is the basic >> routing protocol of a WMN and this paper = discusses > the >> protection of >> HWMP routing messages but not the data = messages. >>=20 >> Which is materially wrong. HWMP is the basic routing = protocol in >> IEEE 802.11s; >> there're many other mesh routing protocols out there, = many of >> which are widely >> deployed. >> Also, this is not a "paper", but a protocol = specification. >>=20 >> o As with "external attacks", it is not clear either what = the > "internal >> attacks" that the authors >> assert that SHWMP protects against are. Section 2.1: >>=20 >> The major problem that is plaguing the WMNs = is the >> detection of >> internal attacks. Internal attacks might = involve >> modification of >> contents of the HWMP frame such as hop count = and air >> time metric. >>=20 >> I am not sure that wireless mesh networks are "plagued" = by this, >> but that aside...would that >> not imply that somehow admission to the network has been >> granted (cryptographic material/key >> provided) to somebody, who then turns around and then >> "attacks" the network? If so, then >> my initial reaction would be that if detected, the right > approach >> would be to revoke the keys >> issued to the "badly behaving device". It is not clear = how SHWMP >> interacts with any key >> management and revocation functions in an IEEE 802.11 = network. >>=20 >> o Continuing through section 2.1, essentially what this = document > is >> saying is: >>=20 >> o It's easy to protect protocol signals = which are >> immutable, or to >> protect immutable fields in protocol = signals, >> against tampering >>=20 >> o It's problematic to protect mutable = fields in >> protocol signals, against >> tampering >>=20 >> o ....but, it's important to do so. >>=20 >> While one might not take huge issues with the first = two, the > third >> doesn't follow. >> What is missing, IMO, is some sort of problem = statement, >> including a security >> analysis. If a mutable field is tampered with, how does = that > hurt? >> Will the system >> break down? Perform a little worse? A lot worse? >>=20 >> This section ends by saying: >>=20 >> However, >> the fields that get changed is quite > important to >> provide link-to- >> link based security so that every = node along > the >> journey should >> authenticate the frame before passing = it on. >> This ensures that the >> contents of the frame are not = modified and > the >> frames can get dropped >> if they are modified. >>=20 >> Three things. >>=20 >> 1) The language is ambiguous: "The fields = that get >> changed [by whom? >> intentionally or the attacker] is = [should be > are] >> quite important to provide >> link-to-link based security [so, is the > important bit >> that "The value of the fields >> is what HWMP uses fir providing = link-to-link > based >> security"? Or, is the important >> bit that these fields are not changed, = and the >> security mechanism should prevent >> this] [also, what is link-to-link base > security]? >>=20 >> 2) OK, so I understand: the goal is to = provide hop- >> by-hop authentication of a frame. >> That implies a specific trust model of = the form > "I >> trust my neighbor to only trust >> neighbors that I would also have = trusted", which >> is not documented. Is that model >> valid in this type of networks? >>=20 >> 3) If 3) is indeed is a valid trust model, = what > does the >> solution proposed actually >> do? If my neighbor has the right = cryptographic >> material to generate the >> signatures needed, then he can tamper = with any >> and all fields, unchallenged and >> undetected. In other words, is this = approach >> protecting against the "internal >> attacks" intended? >>=20 >> o But then I read on to section 2.2, and to my surprise = see that >> what I had identified in 2.1 >> was not at all true - at least, it doesn't read that = way. > Section 2.2 is >> entitled "Security >> features of Secure HWMP", but reading that - after = having read >> 2.1 - I still want to understand >> the (at least, abstract) answers to four simple = questions: >>=20 >> a) What are the identified vulnerabilities = of HWMP, >> which SHWMP patches? >> b) What is the trust model assumed? >> c) How does that trust model match actual >> deployments? >> d) How does SHWMP integrate with IEEE 802 >> security mechanisms, key mgmt, ...? >>=20 >>=20 >> o Section 3, I believe that before starting to discuss the > extension, a >> presentation of >> HWMP would be in order, at least the necessary details = for the >> reader to understand the >> rest of the document. As it is, it is understandable to = those > who >> have a pretty good idea >> of the functioning of HWMP only. As it is, and after = reading >> section 3, I would suggest >> that the reader is as confused as to what HWMP is, what = SHWMP >> does, and how. >>=20 >> o Section 3, 4 I believe that the bulk of the HWMP = terminology >> used should actually, >> be defined in the terminology section - and that the = terminology >> section therefore >> belongs before Section 3. >>=20 >> o Section 3, and section 6.1: >>=20 >> o what does it mean that the "source node = signs >> the non-mutable fields"? >>=20 >> How are the signatures generated, how are mutable fields >> treated (Zeroed out? Removed? Something else?) >>=20 >> o Section 5 is missing definition of which byte-order, = bit-order > is >> used, as well as for >> each field what format (unsigned integer, ...) the = values are > in. >>=20 >> o Section 5 is missing some discussion as to how these = messages >> are intended to be included in the >> frame format of IEEE 802.11. Does that format already = have a >> mechanism for protocol extensions? >> If so, does the format for these extensions "fit in"? = How? >> Are there any requirements for code-point reservations = with the >> IEEE? Have those been made? >> How will those be made? Will experimental code-points = from IEEE >> maintained registries be used? >>=20 >> o I am not sure if the last sentence on page 10 in section = 5.5 >> should/does not mark the start >> of a new paragraph. It seems to talk about "all the = message >> types" and not just the GANN message type >> described immediately previously. >>=20 >> o Generally, and specifically to section 6, it might be = good to >> provide a reference to HWMP, >> which SHWMP is extending; >> it is not enough to simply cite the IEEE standard. If I = was to >> implement this, I would want >> to know more, including: >> o Which specific parts of the (voluminous) = 802.11 >> standard need I study? >> o Which specific processing steps need I = to >> interface with, iow., the operations >> described in this specification are to = be done >> before/after which steps in which >> process in which section of IEEE 802.11 >>=20 >> As it is, I could not implement this proposed extension = to SHWMP >> in a fashion where I would >> be sure to (i) do it right, and (ii) do it in a way that = would > be >> interoperable with somebody elses' >> implementation. >>=20 >> o As this is a security document, I would expect a = complete and >> strong security considerations section. >> As indicated in the above, I believe that - at least - = what is > missing >> is: >>=20 >> o Relationship to 802.1x and other 802 = security >> mechanisms >> o Trust model >> o Protections offered >> o Specifically, protections not offered >> o Limits of cryptographic methods = recommended >> o Ability to evolve - threats on networks = tend to >> not be static >>=20 >> o I have a MAJOR-MAJOR issue related to the cryptological = tools >> used. I am not enough of an >> expert in crypto to know which exact parameters are = required to >> be carried around for each >> algorithm, but.....for example, key indices, which = parameters of > a >> curve, or a function, are to >> be used, ..... -- all of which seems to be not = specified, and >> perhaps should not be specified >> as it is part of some 802 security framework....but, in = that > case, it >> most certainly should be >> discussed. >>=20 >> What I know, however, is that a cryptographic method = that's >> "good" today is "worthless" >> a few years, or even months, hence. I see no codepoints = allowing >> identifying which >> (say) of RSA, DES, HMAC, ECDSA, AES, .... and whatever = the >> future brings, is used? >> Same for hash functions....not long ago md5 was used, = today it's >> definitely not.... >>=20 >> At the very least, I would expect an IANA registry set = up (or, >> references to an 802 registry) >> recording code-points for different algorithms - and the >> messages to contain fields for >> indicating which hash/crypto function to use. >>=20 >> Minor Issues: >>=20 >>=20 >>=20 >> Nits: >>=20 >> o I believe that it would behove the document if the = abstract > called >> out where HWMP has >> come from, especially as it is not an IETF protocol, or = even a > L3 >> protocol >>=20 >> o References are not split up in Normative and Informative >> references, and (FWIW) are not formatted >> in the usual fashion. >>=20 >>=20 >> o Section 3, 2nd paragraph: I believe that it would be = beneficial > to >> split this up in several independent >> paragraphs or, perhaps, an enumerated list. I ended up = making >> the latter on a piece of paper to not >> get lost in the description. >>=20 >> Respectfully, >>=20 >> Thomas >=20 From nobody Mon Mar 31 10:07:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C911A089D; Mon, 31 Mar 2014 10:07:50 -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 LpM6AR3rYpWy; Mon, 31 Mar 2014 10:07:48 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5D10C1A0897; Mon, 31 Mar 2014 10:07:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 77640245AB2; Mon, 31 Mar 2014 10:07:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [12.204.99.168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4F56C24121C; Mon, 31 Mar 2014 10:07:45 -0700 (PDT) Message-ID: <5339A0E3.8080301@joelhalpern.com> Date: Mon, 31 Mar 2014 13:07:47 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Alia Atlas References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> 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/rtg-dir/WGTcOO7AelLSCSpDQX_W9t9omho Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Jamal Hadi Salim Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:07:50 -0000 This reply raises explicitly a question that confused me reading Adrian's first note. Is the target of this work drafts inside the routing area, or drafts from outside the routing area that have routing implications or concerns. I had assumed that the target was the later. Those are the ones that would not normally receive routing clue. I had, possibly erroneously, assumed that most routing area work received sufficient routing assistance during its development. To pick on my own routing area WG, if the KARP work is not receiving sufficient routing review, then that is my 9and my co-chair's) problem. And we might ask for help. But I would not expect us to ask for life-cycle assistance on our documents. also, for many working groups, the drafts assume knowledge of other drafts. And if the mentor needs to be that involved, they become a routing advisor. Having said all that, I do agree that the directorate is lightly loaded, and I am happy to help by accepting more load. Yours, Joel On 3/31/14, 10:18 AM, Alia Atlas wrote: > Acee, > > Absolutely, this would be doing more work. It would be doing it earlier > in the draft life-cycle when there is a chance of improving or killing > bad drafts that did make it past working group adoption. Having better > drafts coming out out of WGLC seems to me to be a clear win - easier to > understand, better technology, common issues and nits addressed, faster > to process through the endgame (IETF Last Call, IESG, IANA, etc). > > As for current scale, there are 187 WG drafts in routing plus 27 is IESG > processing. At the moment, the routing directorate is not highly loaded. > > Alia > From nobody Mon Mar 31 10:08:58 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25211A6F0C; Mon, 31 Mar 2014 10:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SN4PBdILRu9v; Mon, 31 Mar 2014 10:04:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 10A971A6F20; Mon, 31 Mar 2014 10:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2646; q=dns/txt; s=iport; t=1396285456; x=1397495056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qZsvVQLVmea+OZBLdjKbuBE+0Akl+qUcTNqN2yfP+uQ=; b=EePH4yw31/ZONgt2sRYravH17vTk7MSgVNOb8JMpoyrsTaWEWdzMausv gA5LawFU0rPOkAawVxzoVUYXB4UQm2rXTj0ticLOS27uwFzRgGXBfWJem GtKCDV6SE03XfiR3CF2YczbumyzD2JLhI73TjkQR7UEiD2F8kPzV1vxbC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAOKeOVOtJV2b/2dsb2JhbABZgwaBEsMYgSAWdIIlAQEBAwFuCwULAgEIRjIlAQEEDgWHcQjQMxeOHREBHTMHgySBFASYTpI1gzCBcjk X-IronPort-AV: E=Sophos;i="4.97,766,1389744000"; d="scan'208";a="314121692" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 31 Mar 2014 17:04:15 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2VH4F3h006321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 17:04:15 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 12:04:15 -0500 From: "Stan Ratliff (sratliff)" To: "" Thread-Topic: Scaling, Rewards and Process Rules : Document mentors Thread-Index: Ac9M93UmFPa+gFhmQEeWzCw9poDduAANbE+A Date: Mon, 31 Mar 2014 17:04:14 +0000 Message-ID: <5E44B32C-64D5-4048-AA7F-CA3679D12F29@cisco.com> References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> In-Reply-To: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.117] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2A3E9F508FEC5541B3FB2A63A0D3F2DA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ozwNx0JABgaHCogPY3YDvUPPJpA X-Mailman-Approved-At: Mon, 31 Mar 2014 10:08:55 -0700 Cc: "" , "" Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:04:22 -0000 On Mar 31, 2014, at 11:39 AM, Adrian Farrel wrote: > To answer two concerns in one email: >=20 > Yes, we might have the scaling numbers wrong. >=20 > I suspect that only about half of the documents would end up with a mento= r.=20 > Alia (I think - but she can comment) would like a higher number. >=20 > The number of documents we need to worry about is the number of WG docume= nts > across the Routing Area at any one time. Alia has counted this as 187+27.= I make > that 200 :-) >=20 > The Directorate is currently 40 people.=20 > That means between 2.5 and 5 documents per person. > 5 seems too many, but some people might want to take on that sort of load= while > others will not. >=20 > We do not know how much effort will be involved. > I would guess 3 detailed reviews over the course of the document, reviews= of a > few diffs, and some email exchanges. >=20 > As the load ramps up, and according to people's willingness to participat= e we > might: > - declare the project a failure > - increase the size of the Directorate > - see that everything is cool. >=20 > I do note that several Directorate members said that they wished they got= more > work from the Directorate, so at least some of you want something else to= do. Then, it seems to me that those members of the directorate should already b= e swinging in, and looking at a document or two to review. ;-) IMO, this s= eems like a great thing to do - I just don't believe it needs all of the at= tendant process wrapped around it that is being outlined. > Not sure if this is it :-) >=20 > Which takes me to "rewards". > What reward does a Directorate member get today? > I think that anyone in the Directorate who participates in this scheme co= uld > easily expect to double the reward. Got'cha. It's pretty much like the "reward" I'm receiving for being a worki= ng group co-chair: bruises, a scar (or two), and an increased pain threshol= d. That and the ability to work on some pretty cool stuff=85 ;-) Regards, Stan =20 >=20 > And lastly, is this new process and rules? Absolutely not. > This is just a way to inject resource into documents and help the authors= /WGs to > deliver stuff that is useful and works.=20 > Does a WG have to halt processing while a mentor is found? No. > A mentor is just something that might happen in parallel. > Does a WG have to pay attention to what a mentor says? Yes. > But only in the same way that they would pay attention to the same person > commenting on the mailing list in the normal course of events. >=20 > A >=20 From nobody Mon Mar 31 10:20:49 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503841A6F26; Mon, 31 Mar 2014 10:20:46 -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 IIgu9RnvxDqX; Mon, 31 Mar 2014 10:20:43 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC81A6F74; Mon, 31 Mar 2014 10:20:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C1DA8245AB7; Mon, 31 Mar 2014 10:20:18 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.111] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 82B5A2412A7; Mon, 31 Mar 2014 10:20:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_845692FA-1B8A-4920-AEDC-BFB64D78C8CF" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thomas Clausen In-Reply-To: <5E44B32C-64D5-4048-AA7F-CA3679D12F29@cisco.com> Date: Mon, 31 Mar 2014 19:20:13 +0200 Message-Id: <4676E392-E2AA-42D4-AE4E-A23AB03BA296@thomasclausen.org> References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> <5E44B32C-64D5-4048-AA7F-CA3679D12F29@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/7JlEXxzUhE92NaHJOr5g-Gwx-2s Cc: Adrian Farrel , "" , "" Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:20:46 -0000 --Apple-Mail=_845692FA-1B8A-4920-AEDC-BFB64D78C8CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 31 Mar 2014, at 19:04, Stan Ratliff (sratliff) = wrote: >=20 > On Mar 31, 2014, at 11:39 AM, Adrian Farrel > wrote: >=20 >> To answer two concerns in one email: >>=20 >> Yes, we might have the scaling numbers wrong. >>=20 >> I suspect that only about half of the documents would end up with a = mentor.=20 >> Alia (I think - but she can comment) would like a higher number. >>=20 >> The number of documents we need to worry about is the number of WG = documents >> across the Routing Area at any one time. Alia has counted this as = 187+27. I make >> that 200 :-) >>=20 >> The Directorate is currently 40 people.=20 >> That means between 2.5 and 5 documents per person. >> 5 seems too many, but some people might want to take on that sort of = load while >> others will not. >>=20 >> We do not know how much effort will be involved. >> I would guess 3 detailed reviews over the course of the document, = reviews of a >> few diffs, and some email exchanges. >>=20 >> As the load ramps up, and according to people's willingness to = participate we >> might: >> - declare the project a failure >> - increase the size of the Directorate >> - see that everything is cool. >>=20 >> I do note that several Directorate members said that they wished they = got more >> work from the Directorate, so at least some of you want something = else to do. >=20 > Then, it seems to me that those members of the directorate should = already be swinging in, and looking at a document or two to review. ;-) = IMO, this seems like a great thing to do - I just don't believe it needs = all of the attendant process wrapped around it that is being outlined. >=20 Believe me, Stan, we already do - to some degree, picked at random, = according to personal interests, or to "who catches us in the hallways = first" or "who's on jabber" or something. All we ask is that somebody points us to the documents that are most in = need for reviews.... ....where "in need for review" can be interpreted as "will decrease the = workload on the ADs so that they may spend their time doing more = important things" and, ultimately "will mean better end results".... >> Not sure if this is it :-) >>=20 >> Which takes me to "rewards". >> What reward does a Directorate member get today? >> I think that anyone in the Directorate who participates in this = scheme could >> easily expect to double the reward. >=20 > Got'cha. It's pretty much like the "reward" I'm receiving for being a = working group co-chair: bruises, a scar (or two), and an increased pain = threshold. That and the ability to work on some pretty cool stuff=85 ;-) One thing that an AD with a decreased workload may have time for, is to = pound harder on WG chairs that so request ;) Thomas >=20 > Regards, > Stan >=20 >=20 >>=20 >> And lastly, is this new process and rules? Absolutely not. >> This is just a way to inject resource into documents and help the = authors/WGs to >> deliver stuff that is useful and works.=20 >> Does a WG have to halt processing while a mentor is found? No. >> A mentor is just something that might happen in parallel. >> Does a WG have to pay attention to what a mentor says? Yes. >> But only in the same way that they would pay attention to the same = person >> commenting on the mailing list in the normal course of events. >>=20 >> A --Apple-Mail=_845692FA-1B8A-4920-AEDC-BFB64D78C8CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 31 Mar 2014, at 19:04, Stan Ratliff = (sratliff) <sratliff@cisco.com> = wrote:


On Mar 31, 2014, at 11:39 AM, = Adrian Farrel <adrian@olddog.co.uk>
wrote:<= br>
To answer two concerns in one = email:

Yes, we might have the scaling numbers wrong.

I = suspect that only about half of the documents would end up with a = mentor. 
Alia (I = think - but she can comment) would like a higher number.

The = number of documents we need to worry about is the number of WG = documents
across the Routing Area at any one time. Alia has counted = this as 187+27. I make
that 200 :-)

The Directorate is = currently 40 people. 
That means between 2.5 = and 5 documents per person.
5 seems too many, but some people might = want to take on that sort of load while
others will not.

We do = not know how much effort will be involved.
I would guess 3 detailed = reviews over the course of the document, reviews of a
few diffs, and = some email exchanges.

As the load ramps up, and according to = people's willingness to participate we
might:
- declare the = project a failure
- increase the size of the Directorate
- see = that everything is cool.

I do note that several Directorate = members said that they wished they got more
work from the = Directorate, so at least some of you want something else to = do.

Then, it seems to me that those members of the = directorate should already be swinging in, and looking at a document or = two to review. ;-)  IMO, this seems like a great thing to do - I = just don't believe it needs all of the attendant process wrapped around = it that is being = outlined.


Believe me, = Stan, we already do - to some degree, picked at random, according to = personal interests, or to "who catches us in the hallways first" or = "who's on jabber" or something.

All we ask is that = somebody points us to the documents that are most in need for = reviews....

....where "in need for review" can = be interpreted as "will decrease the workload on the ADs so that they = may spend their time doing more important things" and, ultimately "will = mean better end results"....


Not sure = if this is it :-)

Which takes me to "rewards".
What reward = does a Directorate member get today?
I think that anyone in the = Directorate who participates in this scheme could
easily expect to = double the reward.

Got'cha. It's pretty much like = the "reward" I'm receiving for being a working group co-chair: bruises, = a scar (or two), and an increased pain threshold. That and the ability = to work on some pretty cool stuff=85 = ;-)

One thing that an AD with a = decreased workload may have time for, is to pound harder on WG chairs = that so request = ;)

Thomas


Regards,
Stan



And = lastly, is this new process and rules? Absolutely not.
This is just a = way to inject resource into documents and help the authors/WGs = to
deliver stuff that is useful and works. 
Does a WG have to halt = processing while a mentor is found? No.
A mentor is just something = that might happen in parallel.
Does a WG have to pay attention to = what a mentor says? Yes.
But only in the same way that they would pay = attention to the same person
commenting on the mailing list in the = normal course of = events.

A

= --Apple-Mail=_845692FA-1B8A-4920-AEDC-BFB64D78C8CF-- From nobody Mon Mar 31 10:39:15 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2411A6F0C; Mon, 31 Mar 2014 10:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 44r266p0iBmC; Mon, 31 Mar 2014 10:31:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7666F1A089B; Mon, 31 Mar 2014 10:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10128; q=dns/txt; s=iport; t=1396287083; x=1397496683; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lJ1q9e2ISyUKZ4pag9Ng4k/6RCNecfNF1Cu4zZ8G8lo=; b=TU8QPaM+bX4SOD7YRK+Vw8oQ+wlYY4qq32TWhgBz4QHWTzkso4NjDznC Oun/ONhqB7OIfETiHiJKQvseN7dlcz7834okoJFaLRMXJU+cwQjMi3GuT pYAJ8iKTqdtT2PAAWz7gyLh9FOGgutKFL/E2GYUhPTw5n4Yw8BDh9ZhD9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAOmlOVOtJV2a/2dsb2JhbABZgkJEgRLDGIEgFnSCJgEBBG4LEAIBCD8HMhQRAQEEDgWHedA9F4lQhE0RAVAHgySBFASYTpI1gzCBcjk X-IronPort-AV: E=Sophos;i="4.97,766,1389744000"; d="scan'208,217";a="313914745" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 31 Mar 2014 17:31:23 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2VHVNX0030638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 17:31:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 12:31:22 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Clausen Thread-Topic: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors Thread-Index: Ac9M93UmFPa+gFhmQEeWzCw9poDduAANbE+AAACPDYAAAGOwAA== Date: Mon, 31 Mar 2014 17:31:22 +0000 Message-ID: References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> <5E44B32C-64D5-4048-AA7F-CA3679D12F29@cisco.com> <4676E392-E2AA-42D4-AE4E-A23AB03BA296@thomasclausen.org> In-Reply-To: <4676E392-E2AA-42D4-AE4E-A23AB03BA296@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.41.117] Content-Type: multipart/alternative; boundary="_000_EC378408F5EB45C581164C592C5F6766ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/gsReIh2BdSpA2Y2kG4Bn4vW18yw X-Mailman-Approved-At: Mon, 31 Mar 2014 10:39:11 -0700 Cc: Adrian Farrel , "" , "" Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:31:29 -0000 --_000_EC378408F5EB45C581164C592C5F6766ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 31, 2014, at 1:20 PM, Thomas Clausen > wrote: On 31 Mar 2014, at 19:04, Stan Ratliff (sratliff) > wrote: On Mar 31, 2014, at 11:39 AM, Adrian Farrel > wrote: To answer two concerns in one email: Yes, we might have the scaling numbers wrong. I suspect that only about half of the documents would end up with a mentor. Alia (I think - but she can comment) would like a higher number. The number of documents we need to worry about is the number of WG document= s across the Routing Area at any one time. Alia has counted this as 187+27. I= make that 200 :-) The Directorate is currently 40 people. That means between 2.5 and 5 documents per person. 5 seems too many, but some people might want to take on that sort of load w= hile others will not. We do not know how much effort will be involved. I would guess 3 detailed reviews over the course of the document, reviews o= f a few diffs, and some email exchanges. As the load ramps up, and according to people's willingness to participate = we might: - declare the project a failure - increase the size of the Directorate - see that everything is cool. I do note that several Directorate members said that they wished they got m= ore work from the Directorate, so at least some of you want something else to d= o. Then, it seems to me that those members of the directorate should already b= e swinging in, and looking at a document or two to review. ;-) IMO, this s= eems like a great thing to do - I just don't believe it needs all of the at= tendant process wrapped around it that is being outlined. Believe me, Stan, we already do - to some degree, picked at random, accordi= ng to personal interests, or to "who catches us in the hallways first" or "= who's on jabber" or something. All we ask is that somebody points us to the documents that are most in nee= d for reviews=85. Then perhaps an ordered list, picked by the ADs, would suffice? Regards, Stan ....where "in need for review" can be interpreted as "will decrease the wor= kload on the ADs so that they may spend their time doing more important thi= ngs" and, ultimately "will mean better end results".... Not sure if this is it :-) Which takes me to "rewards". What reward does a Directorate member get today? I think that anyone in the Directorate who participates in this scheme coul= d easily expect to double the reward. Got'cha. It's pretty much like the "reward" I'm receiving for being a worki= ng group co-chair: bruises, a scar (or two), and an increased pain threshol= d. That and the ability to work on some pretty cool stuff=85 ;-) One thing that an AD with a decreased workload may have time for, is to pou= nd harder on WG chairs that so request ;) Thomas Regards, Stan And lastly, is this new process and rules? Absolutely not. This is just a way to inject resource into documents and help the authors/W= Gs to deliver stuff that is useful and works. Does a WG have to halt processing while a mentor is found? No. A mentor is just something that might happen in parallel. Does a WG have to pay attention to what a mentor says? Yes. But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events. A --_000_EC378408F5EB45C581164C592C5F6766ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 31, 2014, at 1:20 PM, Thomas Clausen <thomas@thomasclausen.org> wrote:


On 31 Mar 2014, at 19:04, Stan Ratliff (sratliff) <sratliff@cisco.com> wrote:


On Mar 31, 2014, at 11:39 AM, Adrian Farrel <adrian@olddog.co.uk>
wrote:

To answer two concerns in one email:

Yes, we might have the scaling numbers wrong.

I suspect that only about half of the documents would end up with a mentor.=  
Alia (I think - but she can comment) would like a higher number.

The number of documents we need to worry about is the number of WG document= s
across the Routing Area at any one time. Alia has counted this as 187+2= 7. I make
that 200 :-)

The Directorate is currently 40 people. 
That means between 2.5 and 5 documents per person.
5 seems too many, but some people might want to take on that sort of load w= hile
others will not.

We do not know how much effort will be involved.
I would guess 3 detailed reviews over the course of the document, reviews o= f a
few diffs, and some email exchanges.

As the load ramps up, and according to people's willingness to participate = we
might:
- declare the project a failure
- increase the size of the Directorate
- see that everything is cool.

I do note that several Directorate members said that they wished they got m= ore
work from the Directorate, so at least some of you want something else to d= o.

Then, it seems to me that those members of the directorate should already b= e swinging in, and looking at a document or two to review. ;-)  IMO, t= his seems like a great thing to do - I just don't believe it needs all of t= he attendant process wrapped around it that is being outlined.


Believe me, Stan, we already do - to some degree, picked at random, ac= cording to personal interests, or to "who catches us in the hallways f= irst" or "who's on jabber" or something.

All we ask is that somebody points us to the documents that are most in nee= d for reviews=85.

Then perhaps an ordered list, picked by the ADs, would suffice?

Regards,
Stan


....where "in need for review" can be interpreted as "w= ill decrease the workload on the ADs so that they may spend their time doin= g more important things" and, ultimately "will mean better end re= sults"....


Not sure if this is it :-)

Which takes me to "rewards".
What reward does a Directorate member get today?
I think that anyone in the Directorate who participates in this scheme coul= d
easily expect to double the reward.

Got'cha. It's pretty much like the "reward" I'm receiving for bei= ng a working group co-chair: bruises, a scar (or two), and an increased pai= n threshold. That and the ability to work on some pretty cool stuff=85 ;-)<= br>

One thing that an AD with a decreased workload may have time for, is to pou= nd harder on WG chairs that so request ;)

Thomas


Regards,
Stan



And lastly, is this new process and rules? Absolutely not.
This is just a way to inject resource into documents and help the authors/W= Gs to
deliver stuff that is useful and works. 
Does a WG have to halt processing while a mentor is found? No.
A mentor is just something that might happen in parallel.
Does a WG have to pay attention to what a mentor says? Yes.
But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events.

A


--_000_EC378408F5EB45C581164C592C5F6766ciscocom_-- From nobody Mon Mar 31 10:58:55 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CC11A6F5D for ; Mon, 31 Mar 2014 10:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kFa0-i3NHyPM for ; Mon, 31 Mar 2014 10:56:25 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD571A6F56 for ; Mon, 31 Mar 2014 10:56:25 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so5213534wes.30 for ; Mon, 31 Mar 2014 10:56:21 -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=LTFBadA7NkcZ9HB4x+VhKtx86wmrckPfHpfEM0OMPMY=; b=nqC003emngROOMw+/sZeBo5C+n4OL3o53akSLwSdIAlGnobjiI9bS9aToRLdBtr0Sl KWq0xvw95m3Gnq7YUpIb6Xgh0nZyvF3PrHQKV84ef8hF6sicb2gCDnQT1Qg1y1anBxO8 +NP9eNSov8i+yjPVx7T7hhuWi8nQWKC+vdyTIbGuQkVhDB4/roXVH5uCTBqK9C9OPMj1 rCpwSQicxyhM43ExD6+1akurAe0nkxqDbD8IAbjwCAcl2I6Ad8d/z4gGuLmOhIlFZyBY QHJF7seDrk5M6KfpXqoj1q5Vm6GAdmYMm6seFtB0GnaI2CPPa5WEai9+dd0F5wEIltd3 SdvQ== 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=LTFBadA7NkcZ9HB4x+VhKtx86wmrckPfHpfEM0OMPMY=; b=GjRQ0x51KPPZsTW257woSXMQAA4Y3E5TDVSa1YMRK/ciLfGTZf6N00BH1WxnlNVvhn Ig1so78RAMqYPvVueKidajI8Y+ahkT4WqNj5hW+vnaRdmupjVLoWR98yzt2c1B1cDt3k JyyxLa46F4m4C3kc9A70629/ZIfTS0z1+fhLbAk04E2zwJKV36XnYWjXxAfp7SALHYHy YRR3NwBbRfoc9ejDsNf5ZGKs2eJqentIQ1HKYPjP4LgAoIieBSC5dIBU0LuW5CCEx4JS Tds0AvnCyFzaPenvbZJOe/xO5wxVn1vYGILY3SXBKleVhK1hVr1Bu1+zlUKRoGhLpNOS 0Z3g== X-Gm-Message-State: ALoCoQmtQGrpfdDlOdi2Hb2KvlbhEdWT6SZjadxdG6fbr5+HBeh0axz9hQTIwR4F1px0Yh2aEUlZ85ywcBNCxCG3z4j6tuoNkQnvYQingBg0cgCFm506fgVWEiy4CPgiENEBAZD7doO3NbHNmUY5TkKHzNojvOhH0nFUh7VtWOyES7dcbrk210C7x4VXX+Qzo+54tpSXzKt9 X-Received: by 10.194.191.195 with SMTP id ha3mr6260381wjc.69.1396288581396; Mon, 31 Mar 2014 10:56:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.124.65 with HTTP; Mon, 31 Mar 2014 10:55:40 -0700 (PDT) In-Reply-To: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> From: Edward Crabbe Date: Mon, 31 Mar 2014 10:55:40 -0700 Message-ID: To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=047d7ba970bce6071e04f5eac46b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/W-XABWEeEYvtLXuHDT5LpOa0T7Q X-Mailman-Approved-At: Mon, 31 Mar 2014 10:58:54 -0700 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:56:27 -0000 --047d7ba970bce6071e04f5eac46b Content-Type: text/plain; charset=ISO-8859-1 Is it mandatory for the group to wait for mentor feedback? (If so, this may slow document development and iteration unless a specific deadline is provided and review happens in parallel to existing wg review - I'm assuming this is the intention.) On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel wrote: > To answer two concerns in one email: > > Yes, we might have the scaling numbers wrong. > > I suspect that only about half of the documents would end up with a mentor. > Alia (I think - but she can comment) would like a higher number. > > The number of documents we need to worry about is the number of WG > documents > across the Routing Area at any one time. Alia has counted this as 187+27. > I make > that 200 :-) > > The Directorate is currently 40 people. > That means between 2.5 and 5 documents per person. > 5 seems too many, but some people might want to take on that sort of load > while > others will not. > > We do not know how much effort will be involved. > I would guess 3 detailed reviews over the course of the document, reviews > of a > few diffs, and some email exchanges. > > As the load ramps up, and according to people's willingness to participate > we > might: > - declare the project a failure > - increase the size of the Directorate > - see that everything is cool. > > I do note that several Directorate members said that they wished they got > more > work from the Directorate, so at least some of you want something else to > do. > Not sure if this is it :-) > > Which takes me to "rewards". > What reward does a Directorate member get today? > I think that anyone in the Directorate who participates in this scheme > could > easily expect to double the reward. > > And lastly, is this new process and rules? Absolutely not. > This is just a way to inject resource into documents and help the > authors/WGs to > deliver stuff that is useful and works. > Does a WG have to halt processing while a mentor is found? No. > A mentor is just something that might happen in parallel. > Does a WG have to pay attention to what a mentor says? Yes. > But only in the same way that they would pay attention to the same person > commenting on the mailing list in the normal course of events. > > A > > --047d7ba970bce6071e04f5eac46b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Is it mandatory for the group to wait = for mentor feedback? =A0(If so, this may slow document development and iter= ation unless a specific deadline is provided and review happens in parallel= to existing wg review - I'm assuming this is the intention.)



On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel &l= t;adrian@olddog.co= .uk> wrote:
To answer two concerns in one email:

Yes, we might have the scaling numbers wrong.

I suspect that only about half of the documents would end up with a mentor.=
Alia (I think - but she can comment) would like a higher number.

The number of documents we need to worry about is the number of WG document= s
across the Routing Area at any one time. Alia has counted this as 187+27. I= make
that 200 :-)

The Directorate is currently 40 people.
That means between 2.5 and 5 documents per person.
5 seems too many, but some people might want to take on that sort of load w= hile
others will not.

We do not know how much effort will be involved.
I would guess 3 detailed reviews over the course of the document, reviews o= f a
few diffs, and some email exchanges.

As the load ramps up, and according to people's willingness to particip= ate we
might:
- declare the project a failure
- increase the size of the Directorate
- see that everything is cool.

I do note that several Directorate members said that they wished they got m= ore
work from the Directorate, so at least some of you want something else to d= o.
Not sure if this is it :-)

Which takes me to "rewards".
What reward does a Directorate member get today?
I think that anyone in the Directorate who participates in this scheme coul= d
easily expect to double the reward.

And lastly, is this new process and rules? Absolutely not.
This is just a way to inject resource into documents and help the authors/W= Gs to
deliver stuff that is useful and works.
Does a WG have to halt processing while a mentor is found? No.
A mentor is just something that might happen in parallel.
Does a WG have to pay attention to what a mentor says? Yes.
But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events.

A


--047d7ba970bce6071e04f5eac46b-- From nobody Mon Mar 31 11:25:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D65C1A6F58; Mon, 31 Mar 2014 11:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.782 X-Spam-Level: X-Spam-Status: No, score=-99.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, 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 1ikR9qd3MS2F; Mon, 31 Mar 2014 11:24:52 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 76D6A1A089A; Mon, 31 Mar 2014 11:24:51 -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 s2VIOkFB024312; Mon, 31 Mar 2014 19:24:46 +0100 Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2VIOhKP024281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 Mar 2014 19:24:45 +0100 From: "Adrian Farrel" To: "'Edward Crabbe'" References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> In-Reply-To: Date: Mon, 31 Mar 2014 19:24:44 +0100 Message-ID: <029c01cf4d0e$7e5f00f0$7b1d02d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_029D_01CF4D16.E025B2E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJJ/TQYqpxs30dKclrB3/NjLqASyQIoVthdmfTfliA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20602.001 X-TM-AS-Result: No--18.988-10.0-31-10 X-imss-scan-details: No--18.988-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCUTHcBIlpNjQlojktAVaJIF2pUb6YRYK61eX0jEQ9c6nFD 0I0jlEDdr6AF0Zb5A1L0PkiZJq1tvsrvFqEHnukVfJfrSYxpv0j2v20RxLDyN/H1JpQV0A268G7 V1v8bvlHUGg9YYC0r3V07JUJWGZeOyIWPBL1eyh9IOSHptb5tx3f+77ZvcQ0nOFlLAOQNtyHrO1 Ejot0hyv8ZOgXC7HPxnZu1x1KF2dznpy6Tj8doIXvBWikXzNqDJDAZBInjo2YUtdRZTmEaIfeFW pn1QgQORPJ9twEk1OaxSC5hsb6e6MOhCENlpEmE/c0+LJTMrN3DHSNFHFxB8xT++WnU8gyJp2Jc M7f0xpcDHNWD2dfDH2GM+s+r821TYuXIUoVvW6wM+FbAnNWFvkjKSotpBhgVydovWuL+KVfv/72 zC4hJFZ3woJ2UeuYF6HMoliKXreiqDvek35mqXJ3bt4XlQMWj4L7b7oFFzFe13HaVceMXUiL8Ha C6OsQfMHoR0KY0MZVVsQM/S7OiNfJMF6pylZNWVF7yOiu4q2kgVvZV3BB2QNE6Er5EVajmW2E6A 0VjBlqQ0Ir9EHtCMQJIccaMDcUCF/JN69C1+RCR1ykkpfknCvwGVtfL479acq4vxILn2XdgKjAp K+kj73lDN61qsyzESAXq66IdDvrh0C+9/Lq59rqQyAveNtg60zEP/d7xPF1G2qlFbyxbIpqRVZh gNetOzAxLg4NeYKwNunoWbihTV/4zNVp6ir9FpYQ/SMviFcMiBAf19LYIBpU4cC9nAOhdUdfEKc 10rU44RDGbByRvWxESBRJlSEUWU6L1rmVqlpGeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vXkguuQorcgMASjXQZMkBLguNLKeoleeaU6RbUuzEd0wuVRb8orSPEx+3BndfXUhXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/kjMM1buwMPohqh8T_r_Ko-wCBI8 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:24:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_029D_01CF4D16.E025B2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ed, That's a good question. How would you like that to work? I can guess! Can you propose changes to the text that do what you want? A From: Edward Crabbe [mailto:edc@google.com] Sent: 31 March 2014 18:56 To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: Scaling, Rewards and Process Rules : Document mentors Is it mandatory for the group to wait for mentor feedback? (If so, this may slow document development and iteration unless a specific deadline is provided and review happens in parallel to existing wg review - I'm assuming this is the intention.) On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel wrote: To answer two concerns in one email: Yes, we might have the scaling numbers wrong. I suspect that only about half of the documents would end up with a mentor. Alia (I think - but she can comment) would like a higher number. The number of documents we need to worry about is the number of WG documents across the Routing Area at any one time. Alia has counted this as 187+27. I make that 200 :-) The Directorate is currently 40 people. That means between 2.5 and 5 documents per person. 5 seems too many, but some people might want to take on that sort of load while others will not. We do not know how much effort will be involved. I would guess 3 detailed reviews over the course of the document, reviews of a few diffs, and some email exchanges. As the load ramps up, and according to people's willingness to participate we might: - declare the project a failure - increase the size of the Directorate - see that everything is cool. I do note that several Directorate members said that they wished they got more work from the Directorate, so at least some of you want something else to do. Not sure if this is it :-) Which takes me to "rewards". What reward does a Directorate member get today? I think that anyone in the Directorate who participates in this scheme could easily expect to double the reward. And lastly, is this new process and rules? Absolutely not. This is just a way to inject resource into documents and help the authors/WGs to deliver stuff that is useful and works. Does a WG have to halt processing while a mentor is found? No. A mentor is just something that might happen in parallel. Does a WG have to pay attention to what a mentor says? Yes. But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events. A ------=_NextPart_000_029D_01CF4D16.E025B2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ed,

 

That's a good question. How = would you like that to work? I can guess!

 

Can you propose changes to the = text that do what you want?

 

A

 

From: Edward Crabbe = [mailto:edc@google.com]
Sent: 31 March 2014 = 18:56
To: adrian@olddog.co.uk
Cc: rtg-dir@ietf.org; = rtg-chairs@ietf.org
Subject: Re: Scaling, Rewards and Process = Rules : Document mentors

 

 

Is it mandatory for the group to wait for mentor = feedback?  (If so, this may slow document development and iteration = unless a specific deadline is provided and review happens in parallel to = existing wg review - I'm assuming this is the = intention.)

 

 

On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

To answer two concerns = in one email:

Yes, we might have the scaling numbers = wrong.

I suspect that only about half of the documents would end = up with a mentor.
Alia (I think - but she can comment) would like a = higher number.

The number of documents we need to worry about is = the number of WG documents
across the Routing Area at any one time. = Alia has counted this as 187+27. I make
that 200 :-)

The = Directorate is currently 40 people.
That means between 2.5 and 5 = documents per person.
5 seems too many, but some people might want to = take on that sort of load while
others will not.

We do not = know how much effort will be involved.
I would guess 3 detailed = reviews over the course of the document, reviews of a
few diffs, and = some email exchanges.

As the load ramps up, and according to = people's willingness to participate we
might:
- declare the = project a failure
- increase the size of the Directorate
- see = that everything is cool.

I do note that several Directorate = members said that they wished they got more
work from the = Directorate, so at least some of you want something else to do.
Not = sure if this is it :-)

Which takes me to = "rewards".
What reward does a Directorate member get = today?
I think that anyone in the Directorate who participates in = this scheme could
easily expect to double the reward.

And = lastly, is this new process and rules? Absolutely not.
This is just a = way to inject resource into documents and help the authors/WGs = to
deliver stuff that is useful and works.
Does a WG have to halt = processing while a mentor is found? No.
A mentor is just something = that might happen in parallel.
Does a WG have to pay attention to = what a mentor says? Yes.
But only in the same way that they would pay = attention to the same person
commenting on the mailing list in the = normal course of events.

A

 

------=_NextPart_000_029D_01CF4D16.E025B2E0-- From nobody Mon Mar 31 11:40:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F241A08BA; Mon, 31 Mar 2014 11:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jTHZTtrWwCGM; Mon, 31 Mar 2014 11:40:22 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE2F1A06D9; Mon, 31 Mar 2014 11:40:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 061E6C23D; Mon, 31 Mar 2014 14:40:19 -0400 (EDT) Date: Mon, 31 Mar 2014 14:40:18 -0400 From: Jeffrey Haas To: Alia Atlas Message-ID: <20140331184018.GA22966@pfrc> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> 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/rtg-dir/E4qLF6kns7nBLl4dWz_1ycsjYLs Cc: "Les Ginsberg \(ginsberg\)" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:40:23 -0000 On Mon, Mar 31, 2014 at 11:51:45AM -0400, Alia Atlas wrote: > The process involves discussing having a document mentor. If the WG chairs > and authors agree that there is no need, then no document mentor is > required. It is intended to be expressly a check and decide against rather > than requiring an ask. As for scaling, which aspect is the concern? > There are really about 200 WG drafts in the state where they'd have > document mentors and many of those wouldn't need them. I am happy to > address scaling concerns - but I need to understand the parameters of > concern. I'm wondering if a full-out mentor is really what is needed. A significant amount of the work I think we're hoping to save can be caught by competent technical editing even by persons somewhat unfamiliar with the topic at hand: - Is the document written in clear English? - Are the concepts clearly explained? ... - and *then*, are the concepts sound for the proposal for the technical work at hand? Part of the pain each reader is expected to go through until the first two points are satisfied is that their brains are having to work around the editing. The third point, when it's missing the "every person working in the IETF should know" kind of points, is appropriate for a WG-neutral mentor. Beyond that, it's the work of the working group, IMO. Thus, I think what's needed is more the ability to punch a button next to the draft and say "this needs technical editing help" and potentially let parties who are willing to volunteer be able to pick up the work. Compensation beyond egoboo[1] for such dirty work is the subject of a different thread. (Although I did poke IAOC about some sort of public "karma" system over a year ago.) -- Jeff [1] http://en.wikipedia.org/wiki/Egoboo From nobody Mon Mar 31 11:44:41 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F651A6F32; Mon, 31 Mar 2014 11:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 f6H6tJ0EhIDs; Mon, 31 Mar 2014 11:44:29 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3A87B1A6F2A; Mon, 31 Mar 2014 11:44:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35413; q=dns/txt; s=iport; t=1396291466; x=1397501066; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hsHDmBEGgLwbaLzI+dOTpS5Oqpq3PRGmE4t98Op8Y+Y=; b=ip2I6QczeTNezSb/kDCo36wbJO4OoPJaso/tjshzZLYcZoWbqBAt3yoA TwxgA/OauuCUcOurYGNV1gxI7kNOAcgECGggNdHN4G+lArccbdGdFxprZ OAriLDOGdPdejS6kRpYr5B2yUwA62X2mq2LFR5sbGRi/E5JNFuPMaNSt4 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAPm2OVOtJV2d/2dsb2JhbABZgkJEO1fDHYEhFnSCJQEBAQMBGhM+BwcFBwQCAQgOAwQBAQsWAQYHIREUCQgBAQQOBQgTh0oDCQjJUg2GXxeMY4FrMQYBBoMegRQElGKBf45YhUqDMIIr X-IronPort-AV: E=Sophos; i="4.97,767,1389744000"; d="scan'208,217"; a="31770209" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 31 Mar 2014 18:44:22 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2VIiMFs029077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 18:44:22 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.99]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 13:44:22 -0500 From: "Les Ginsberg (ginsberg)" To: Alia Atlas Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QAFwtIQAAxjOoAABjoUIA== Date: Mon, 31 Mar 2014 18:44:22 +0000 Message-ID: References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.228] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F23D5442Axmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/exzmeXyWTKh-43YlGe9gZ1qvBR0 Cc: "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:44:37 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F23D5442Axmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alia - Thanx for the reply. Inline. From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Monday, March 31, 2014 8:52 AM To: Les Ginsberg (ginsberg) Cc: adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Document Mentors Hi Les, Thanks for your thoughts, On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (ginsberg) > wrote: The way I read what is proposed below is that all documents will be assigne= d a mentor. Perhaps that is not what you intended - but it does seem to rea= d that way. And as others who have replied to this have suggested that does= n't make sense for all documents and doesn't scale well. Also, the stated p= rocess introduces mentoring AFTER a document is adopted as a WG item. IMHO = this is too late. The process involves discussing having a document mentor. If the WG chairs= and authors agree that there is no need, then no document mentor is requir= ed. It is intended to be expressly a check and decide against rather than = requiring an ask. As for scaling, which aspect is the concern? There are= really about 200 WG drafts in the state where they'd have document mentors= and many of those wouldn't need them. I am happy to address scaling conc= erns - but I need to understand the parameters of concern. LES: Documents that only need "a little bit of help" don't require mentorin= g. A comment from anyone on the list likely suffices. Any document which r= equires mentoring wil demand a significant effort. Since the thread has ope= nly discussed how many documents there are in routing I took that (perhaps= mistakenly) to mean mentoring was a new part of the process for all docume= nts. If that is NOT the case and the percentage of documents which we think= will require mentoring is small then I don't think scale is an issue - but= the estimates here still seem to be vague. What I would suggest is that there become three options available for a WG = to choose when a document is proposed as a WG item: 1)Accept 2)Reject 3)Resubmit after mentoring The third category is reserved for documents which the WG feels have an ide= a/solution which might be worth the WG group's time, but the current "quali= ty" of the document is such that meaningful discussion would be hindered. The authors are free to reject the offer of mentoring in which case the doc= ument is rejected. This limits the time/effort on the part of the mentors to a smaller number = of documents and only for ones that are actually worth the time. Also, it m= eans the time of the entire WG is not wasted on discussions that might be u= nnecessary if the draft presentation were improved. You are assuming that there is never any need for external review or to imp= rove drafts by review (outside the standard WG members) before WGLC. The = goal of the document mentor is to do early review and suggest improvements = and changes once the draft is under control of the IETF - which individual = drafts aren't. LES:No - I make no such assumption. Nor am I suggesting that individual con= tributions get mentoring. I am suggesting that if someone asks for a docume= nt to become a WG document then at that time the WG should have an option t= o say "Your document is addressing an area of interest to the WG but the current = presentation/solution needs work in order to have a productive discussion. = If you wish a mentor can be assigned to assist you in providing a document = which is worthy of discussing in the WG." Frankly I think this is the point where we can get the most return. Discuss= ing documents which are seriously flawed (editorially or technically) is a = waste of the WG time - as well as the authors. But if there is a good reaso= n to move from individual contribution to WG document it makes a lot of sen= se to me to get the document into good shape BEFORE the entire WG spends cy= cles on it. That makes better use of the WG time. Mentoring can continue du= ring WG review of course, but I like to think that if we start w WG-00 that= is in good shape the version that passes last call is much more likely (an= d with much less additional effort) also going to be in good shape. This do= es not preclude or censure any WG comments post WG-00 submission of course = - but hopefully we will all at least have a common understanding of what we= are reviewing. For the case that you are suggesting, I feel like that belongs to the WG ch= air to figure out getting the reviews and improvement needed. It is useful= - of course! - but not the problem that this idea is trying to solve. LES: So you think WG review of a document that is in poor shape is not a pr= oblem? If the flaws of the document are only addressed AFTER the WG would h= ave approved a last call what makes you think the WG understood what they w= ere approving? That said, the danger I see here is that in some cases it will be very hard= for a mentor to provide meaningful feedback without also commenting on the= guts of the solution. If the only issue is "grammar", then not a concern. = But I think what we are trying to address may go beyond simply editorial/gr= ammatical issues in some cases and then it is not clear to me how one separ= ates "mentoring" from "authorship". This isn't a language review or an editing relationship! This is technica= l mentoring of the document - which includes making suggestions during a re= view of how it can be improved. Done well, I'd expect it to go to acknowle= dgements. I certainly review drafts and make significant comments without = expecting or needing to become an author. LES: This is NOT about getting credit. ASIDE: Speaking just for myself I don't give a damn whether I get credit for mento= ring or not. If I wanted to become famous I would have chosen a different p= rofession. :) END ASIDE I am saying that once you start discussing changes to thet technical soluti= on the line between reviewer and author gets quite blurred. What then is th= e role difference between a mentor and a WG member who suggests a different= way of solving the problem? One difference of course is that the mentor is= specifically assigned to this document. But what makes the mentor's techni= cal comments any more or less valid that that of of any other IETF member? = (Answer: Nothing) So how then do you define the role of the mentor and why = should the authors be bound to listen to the mentor any more than they woul= d anyone else? Les Alia Les > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, March 31, 2014 5:12 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: [RTG-DIR] Document Mentors > > Hi, > > One of the ideas to come out of the recent discussions is appointing a me= ntor > per document from the time it is adopted by a Routing Area working group > until > it completes WG last call. > > This would be voluntary in two dimensions: > - the WG chairs would need to deem that one would be beneficial > - we would have to find someone from the Directorate willing to > take on the document. > > We don't think that technology expertise is as useful in this as IETF clu= e > and > general routing experience. > > So, to take this forward we would need: > - WG chairs to say "Yes, we can see that that would have > potential benefit > - Directorate members to say "Yes, we could take on that > additional work. > > Alia and I have put together some preliminary notes on how this would all > hang > together. > > Your opinions and rotten fruit are solicited. > > Thanks, > Adrian and Alia > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Document Mentors in the Routing Area > > The Problems: > > a) Drafts get little review outside the working group and sometimes ins= ide > the working group until after working group last call. At that point it= is > often > painful and costly to make meaningful improvements to the drafts. > > b) Authors may not know how or whom to ask for assistance or review > (e.g., IANA section, Security Section, Operational and Management > considerations, details of a protocol, etc. ). > > The Goals: > > a) Excellent and consistent review at WG adoption and before WG last > call. > > b) Ability for prolonged discussion and problem-solving when the > draft can still be easily enhanced. > > c) Reduced time to delivery of RFCs. > > d) Quality documents. > > The Solution: > > A per-document mentor who is a known neutral party to whom the > authors can go for advice on: > - how to write a section > - specific issues that arise > - ways to resolve conflicts. > > The document mentor also watches the progress of the document > and gives advice and steerage. > > It is not assumed that every document will need or benefit from > having a mentor. > > The Expected Workload: > > The routing directorate has approximately 40 people. If we assume > that approximately 50 drafts pass WG adoption and a similar number > pass WGLC each year, then the load is 2.5 documents per person > per year. If we assume that there are about 200 WG drafts in the > Routing Area and that they all have mentors, then each Routing > Directorate member will have 5 drafts that she or he is mentoring. > > The Supporting Data Artefacts: > > a) As part of the Routing Area wiki, the areas of knowledge for > each member of the Routing Directorate will be publicly specified. > This is added to the wiki by the Routing Area Coordinators (or AD) > when the member joins the Routing Directorate, updated by the > member while he or she is on the Directorate, and updated by the > Routing Area Coordinators (or AD) if and when the member's term > renews. > > b) Document Mentor Availability and Assignments: As part of the > Routing Area wiki, each Directorate member will specify the maximum > number of documents that he or she is able to mentor. Also listed > will be the list of mentored documents (and a count). > > i) When a Directorate member is assigned as the Document > mentor, the Routing Directorate Coordinator will update the > wiki page and create a wiki page for the draft. > > ii) When a Document Mentor provides a review, that should be > stored in the draft's wiki page along with the resolutions. > > iii) When the Document Mentor's final review at WGLC is done, > the Document Mentor should move the draft to a list of > "previously mentored documents" associated with their name. > It is ideal to write up a summary of the document mentoring > experience. > > c) Unmentored Documents: Drafts which have declined a document > mentor should be listed on a wiki page. > > d) For each WG's wiki, it'd be useful to have the list of drafts > with their associated Document Mentors (or lack thereof) and the > link to the draft's wiki page. > > The Basic Process: > > When a new WG draft is adopted, the WG chairs and the Routing > Directorate Coordinators discuss and agree on possible Document > Mentors (up to 3). Then the Routing Directorate Coordinator > confirms with the Routing Directorate members about their > availability and willingness to mentor this particular draft. Once > one is selected, the Routing Directorate Coordinator updates the > wiki and notifies the WG chairs and draft authors. > > a) With the agreement of the ADs, a Document Mentor who is not a > member of the Routing Directorate may be selected. > > b) The WG chairs can, after consulting with the draft authors, > decline to have a Document Mentor. > > c) The Document Mentor should coordinate with the Document > Shepherd for hand-off after WGLC. > > > --_000_F3ADE4747C9E124B89F0ED2180CC814F23D5442Axmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alia –

 <= /p>

Thanx for the reply.=

Inline.=

 <= /p>

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Monday, March 31, 2014 8:52 AM
To: Les Ginsberg (ginsberg)
Cc: adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] Document Mentors

 

Hi Les,

 

Thanks for your thoughts,

 

On Mon, Mar 31, 2014 at 11:39 AM, Les Ginsberg (gins= berg) <ginsberg@= cisco.com> wrote:

The way I read what is proposed below is that all do= cuments will be assigned a mentor. Perhaps that is not what you intended - = but it does seem to read that way. And as others who have replied to this h= ave suggested that doesn't make sense for all documents and doesn't scale well. Also, the stated process introdu= ces mentoring AFTER a document is adopted as a WG item. IMHO this is too la= te.

 

The process involves discussing having a document me= ntor.  If the WG chairs and authors agree that there is no need, then = no document mentor is required.  It is intended to be expressly a chec= k and decide against rather than requiring an ask.  As for scaling, which aspect is the concern?   There are r= eally about 200 WG drafts in the state where they'd have document mentors a= nd many of those wouldn't need them.   I am happy to address scaling c= oncerns - but I need to understand the parameters of concern.

 <= /p>

LES: Documents that only = need “a little bit of help” don’t require mentoring. A co= mment from anyone on the list likely suffices.  Any document which req= uires mentoring wil demand a significant effort. Since the thread has openly dis= cussed how many documents there are in routing  I took that (perhaps m= istakenly) to mean mentoring was a new part of the process for all document= s. If that is NOT the case and the percentage of documents which we think will require mentoring is small then I donR= 17;t think scale is an issue – but the estimates here still seem to b= e vague.

 

What I would suggest is that there become three opti= ons available for a WG to choose when a document is proposed as a WG item:<= br>
1)Accept
2)Reject
3)Resubmit after mentoring

The third category is reserved for documents which the WG feels have an ide= a/solution which might be worth the WG group's time, but the current "= quality" of the document is such that meaningful discussion would be h= indered.
The authors are free to reject the offer of mentoring in which case the doc= ument is rejected.

This limits the time/effort on the part of the mentors to a smaller number = of documents and only for ones that are actually worth the time. Also, it m= eans the time of the entire WG is not wasted on discussions that might be u= nnecessary if the draft presentation were improved.

 

You are assuming that there is never any need for ex= ternal review or to improve drafts by review (outside the standard WG membe= rs) before WGLC.   The goal of the document mentor is to do early revi= ew and suggest improvements and changes once the draft is under control of the IETF - which individual drafts aren= 't.

 

LES:No – I make no = such assumption. Nor am I suggesting that individual contributions get ment= oring. I am suggesting that if someone asks for a document to become a WG document then at that time the WG should have an option to say=

 <= /p>

“Your document is addressing an area of interest to the WG but t= he current presentation/solution needs work in order to have a productive discussion. If you wish a mentor can be assigned to assist you in providin= g a document which is worthy of discussing in the WG.”

 <= /p>

Frankly I think this is t= he point where we can get the most return. Discussing documents which are s= eriously flawed (editorially or technically) is a waste of the WG time – as well as the authors. But if there is a good reas= on to move from individual contribution to WG document it makes a lot of se= nse to me to get the document into good shape BEFORE the entire WG spends c= ycles on it. That makes better use of the WG time. Mentoring can continue during WG review of course, but I like= to think that if we start w WG-00 that is in good shape the version that p= asses last call is much more likely (and with much less additional effort) = also going to be in good shape. This does not preclude or censure any WG comments post WG-00 submission of= course – but hopefully we will all at least have a common understand= ing of what we are reviewing.

 <= /p>

For the case that you are suggesting, I feel like th= at belongs to the WG chair to figure out getting the reviews and improvemen= t needed.  It is useful - of course! - but not the problem that this i= dea is trying to solve.

 <= /p>

LES: So you think WG revi= ew of a document that is in poor shape is not a problem? If the flaws of th= e document are only addressed AFTER the WG would have approved a last call what makes you think the WG understood what they were approvin= g?

 

That said, the danger I see here is that in some cas= es it will be very hard for a mentor to provide meaningful feedback without= also commenting on the guts of the solution. If the only issue is "gr= ammar", then not a concern. But I think what we are trying to address may go beyond simply editorial/grammatical i= ssues in some cases and then it is not clear to me how one separates "= mentoring" from "authorship".

 

This isn't a language review or an editing relations= hip!   This is technical mentoring of the document - which includes ma= king suggestions during a review of how it can be improved.  Done well= , I'd expect it to go to acknowledgements.  I certainly review drafts and make significant comments without expecting or= needing to become an author.

 <= /p>

LES: This is NOT about ge= tting credit.

 <= /p>

ASIDE:<= /p>

Speaking just for myself = I don’t give a damn whether I get credit for mentoring or not. If I w= anted to become famous I would have chosen a different profession. J

END ASIDE

 <= /p>

I am saying that once you= start discussing changes to thet technical solution the line between revie= wer and author gets quite blurred. What then is the role difference between a mentor and a WG member who suggests a different way o= f solving the problem? One difference of course is that the mentor is speci= fically assigned to this document. But what makes the mentor’s techni= cal comments any more or less valid that that of of any other IETF member? (Answer: Nothing) So how then do you def= ine the role of the mentor and why should the authors be bound to listen to= the mentor any more than they would anyone else?

 

   Les

 <= /p>

Alia

 


   Les



> -----Original Message-----
> From: rtg-dir [mailto:rtg-= dir-bounces@ietf.org] On Behalf Of Adrian Farrel
> Sent: Monday, March 31, 2014 5:12 AM
> To: rtg-dir@ietf.org; rtg-chairs@ietf.org
> Subject: [RTG-DIR] Document Mentors
>
> Hi,
>
> One of the ideas to come out of the recent discussions is appointing a= mentor
> per document from the time it is adopted by a Routing Area working gro= up
> until
> it completes WG last call.
>
> This would be voluntary in two dimensions:
> - the WG chairs would need to deem that one would be beneficial
> - we would have to find someone from the Directorate willing to
>    take on the document.
>
> We don't think that technology expertise is as useful in this as IETF = clue
> and
> general routing experience.
>
> So, to take this forward we would need:
> - WG chairs to say "Yes, we can see that that would have
>    potential benefit
> - Directorate members to say "Yes, we could take on that
>   additional work.
>
> Alia and I have put together some preliminary notes on how this would = all
> hang
> together.
>
> Your opinions and rotten fruit are solicited.
>
> Thanks,
> Adrian and Alia
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> Document Mentors in the Routing Area
>
> The Problems:
>
>   a) Drafts get little review outside the working group and somet= imes inside
>   the working group until after working group last call. At that = point it is
> often
>   painful and costly to make meaningful improvements to the draft= s.
>
>   b) Authors may not know how or whom to ask for assistance  = ;or review
>   (e.g., IANA section, Security Section, Operational and Manageme= nt
>   considerations, details of a protocol, etc. ).
>
> The Goals:
>
>   a) Excellent and consistent review at WG adoption and before WG= last
>   call.
>
>   b) Ability for prolonged discussion and problem-solving when th= e
>   draft can still be easily enhanced.
>
>   c) Reduced time to delivery of RFCs.
>
>   d) Quality documents.
>
> The Solution:
>
>   A per-document mentor who is a known neutral party to whom the<= br> >   authors can go for advice on:
>   - how to write a section
>   - specific issues that arise
>   - ways to resolve conflicts.
>
>   The document mentor also watches the progress of the document >   and gives advice and steerage.
>
>   It is not assumed that every document will need or benefit from=
>   having a mentor.
>
> The Expected Workload:
>
>    The routing directorate has approximately 40 people. &nbs= p;If we assume
>    that approximately 50 drafts pass WG adoption and a simil= ar number
>    pass WGLC each year, then the load is 2.5 documents per p= erson
>    per year.  If we assume that there are about 200 WG = drafts in the
>    Routing Area and that they all have mentors, then each Ro= uting
>    Directorate member will have 5 drafts that she or he is m= entoring.
>
> The Supporting Data Artefacts:
>
>    a) As part of the Routing Area wiki, the areas of knowled= ge for
>    each member of the Routing Directorate will be publicly s= pecified.
>    This is added to the wiki by the Routing Area Coordinator= s (or AD)
>    when the member joins the Routing Directorate, updated by= the
>    member while he or she is on the Directorate, and updated= by the
>    Routing Area Coordinators (or AD) if and when the member'= s term
>    renews.
>
>    b) Document Mentor Availability and Assignments: As part = of the
>    Routing Area wiki, each Directorate member will specify t= he maximum
>    number of documents that he or she is able to mentor. &nb= sp;Also listed
>    will be the list of mentored documents (and a count).
>
>         i) When a Directorate member is assigned a= s the Document
>         mentor, the Routing Directorate Coordinato= r will update the
>         wiki page and create a wiki page for the d= raft.
>
>         ii) When a Document Mentor provides a revi= ew, that should be
>         stored in the draft's wiki page along with= the resolutions.
>
>         iii) When the Document Mentor's final revi= ew at WGLC is done,
>         the Document Mentor should move the draft = to a list of
>         "previously mentored documents" = associated with their name.
>         It is ideal to write up a summary of the d= ocument mentoring
> experience.
>
>    c) Unmentored Documents: Drafts which have declined a doc= ument
>    mentor should be listed on a wiki page.
>
>    d) For each WG's wiki, it'd be useful to have the list of= drafts
>    with their associated Document Mentors (or lack thereof) = and the
>    link to the draft's wiki page.
>
> The Basic Process:
>
>   When a new WG draft is adopted, the WG chairs and the Routing >   Directorate Coordinators discuss and agree on possible Document=
>   Mentors (up to 3).  Then the Routing Directorate Coordinat= or
>   confirms with the Routing Directorate members about their
>   availability and willingness to mentor this particular draft. O= nce
>   one is selected, the Routing Directorate Coordinator updates th= e
>   wiki and notifies the WG chairs and draft authors.
>
>      a) With the agreement of the ADs, a Document Mento= r who is not a
>      member of the Routing Directorate may be selected.=
>
>      b) The WG chairs can, after consulting with the dr= aft authors,
>      decline to have a Document Mentor.
>
>      c) The Document Mentor should coordinate with the = Document
>      Shepherd for hand-off after WGLC.
>
>
>

 

--_000_F3ADE4747C9E124B89F0ED2180CC814F23D5442Axmbalnx02ciscoc_-- From nobody Mon Mar 31 11:48:28 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB721A6F3B; Mon, 31 Mar 2014 11:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 5nEyCnLcmtb1; Mon, 31 Mar 2014 11:48:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D061E1A071B; Mon, 31 Mar 2014 11:48:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCP44613; Mon, 31 Mar 2014 18:48:17 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 19:47:38 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 31 Mar 2014 19:48:17 +0100 Received: from DFWEML706-CHM.china.huawei.com ([169.254.8.2]) by dfweml704-chm.china.huawei.com ([169.254.6.56]) with mapi id 14.03.0158.001; Mon, 31 Mar 2014 11:48:08 -0700 From: Leeyoung To: Edward Crabbe , "adrian@olddog.co.uk" Thread-Topic: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors Thread-Index: Ac9M93UmFPa+gFhmQEeWzCw9poDduAATaTEAAA07TKA= Date: Mon, 31 Mar 2014 18:48:08 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729BDB4A6@dfweml706-chm.china.huawei.com> References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.238] Content-Type: multipart/alternative; boundary="_000_7AEB3D6833318045B4AE71C2C87E8E1729BDB4A6dfweml706chmchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/fCgW9j9ZxZfil_ECMyWSEl42D_A Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 18:48:26 -0000 --_000_7AEB3D6833318045B4AE71C2C87E8E1729BDB4A6dfweml706chmchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Related to Ed's comment, I am wondering if this additional mentor feedback = could potentially slow down the progress of standardization. Good document = quality should never get compromised, but the time to standardization shoul= d not be compromised. General perception is that it takes too long to stand= ardize in IETF. I would support mentor feedback if this is only selectively applied to some= documents per WG chair's call and is done in parallel to WG review. Young From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Edward Crabbe Sent: Monday, March 31, 2014 12:56 PM To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentor= s Is it mandatory for the group to wait for mentor feedback? (If so, this ma= y slow document development and iteration unless a specific deadline is pro= vided and review happens in parallel to existing wg review - I'm assuming t= his is the intention.) On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel > wrote: To answer two concerns in one email: Yes, we might have the scaling numbers wrong. I suspect that only about half of the documents would end up with a mentor. Alia (I think - but she can comment) would like a higher number. The number of documents we need to worry about is the number of WG document= s across the Routing Area at any one time. Alia has counted this as 187+27. I= make that 200 :-) The Directorate is currently 40 people. That means between 2.5 and 5 documents per person. 5 seems too many, but some people might want to take on that sort of load w= hile others will not. We do not know how much effort will be involved. I would guess 3 detailed reviews over the course of the document, reviews o= f a few diffs, and some email exchanges. As the load ramps up, and according to people's willingness to participate = we might: - declare the project a failure - increase the size of the Directorate - see that everything is cool. I do note that several Directorate members said that they wished they got m= ore work from the Directorate, so at least some of you want something else to d= o. Not sure if this is it :-) Which takes me to "rewards". What reward does a Directorate member get today? I think that anyone in the Directorate who participates in this scheme coul= d easily expect to double the reward. And lastly, is this new process and rules? Absolutely not. This is just a way to inject resource into documents and help the authors/W= Gs to deliver stuff that is useful and works. Does a WG have to halt processing while a mentor is found? No. A mentor is just something that might happen in parallel. Does a WG have to pay attention to what a mentor says? Yes. But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events. A --_000_7AEB3D6833318045B4AE71C2C87E8E1729BDB4A6dfweml706chmchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Related to Ed’s com= ment, I am wondering if this additional mentor feedback could potentially s= low down the progress of standardization. Good document quality should never get compromised, but the time to standardization should not b= e compromised. General perception is that it takes too long to standardize = in IETF.

 <= /p>

I would support mentor fe= edback if this is only selectively applied to some documents per WG chair&#= 8217;s call and is done in parallel to WG review.

 <= /p>

Young

 <= /p>

From: rtg-dir = [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Edward Crabbe
Sent: Monday, March 31, 2014 12:56 PM
To: adrian@olddog.co.uk
Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document= mentors

 

 

Is it mandatory for the group to wait for mentor fee= dback?  (If so, this may slow document development and iteration unles= s a specific deadline is provided and review happens in parallel to existin= g wg review - I'm assuming this is the intention.)

 

 

On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel <<= a href=3D"mailto:adrian@olddog.co.uk" target=3D"_blank">adrian@olddog.co.uk= > wrote:

To answer two concern= s in one email:

Yes, we might have the scaling numbers wrong.

I suspect that only about half of the documents would end up with a mentor.=
Alia (I think - but she can comment) would like a higher number.

The number of documents we need to worry about is the number of WG document= s
across the Routing Area at any one time. Alia has counted this as 187+2= 7. I make
that 200 :-)

The Directorate is currently 40 people.
That means between 2.5 and 5 documents per person.
5 seems too many, but some people might want to take on that sort of load w= hile
others will not.

We do not know how much effort will be involved.
I would guess 3 detailed reviews over the course of the document, reviews o= f a
few diffs, and some email exchanges.

As the load ramps up, and according to people's willingness to participate = we
might:
- declare the project a failure
- increase the size of the Directorate
- see that everything is cool.

I do note that several Directorate members said that they wished they got m= ore
work from the Directorate, so at least some of you want something else to d= o.
Not sure if this is it :-)

Which takes me to "rewards".
What reward does a Directorate member get today?
I think that anyone in the Directorate who participates in this scheme coul= d
easily expect to double the reward.

And lastly, is this new process and rules? Absolutely not.
This is just a way to inject resource into documents and help the authors/W= Gs to
deliver stuff that is useful and works.
Does a WG have to halt processing while a mentor is found? No.
A mentor is just something that might happen in parallel.
Does a WG have to pay attention to what a mentor says? Yes.
But only in the same way that they would pay attention to the same person commenting on the mailing list in the normal course of events.

A

 

--_000_7AEB3D6833318045B4AE71C2C87E8E1729BDB4A6dfweml706chmchi_-- From nobody Mon Mar 31 12:15:04 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF41F1A08BE; Mon, 31 Mar 2014 12:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 x61W53r_rG3k; Mon, 31 Mar 2014 12:14:55 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id A13461A08B4; Mon, 31 Mar 2014 12:14:55 -0700 (PDT) Received: from mail217-ch1-R.bigfish.com (10.43.68.254) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Mar 2014 19:14:51 +0000 Received: from mail217-ch1 (localhost [127.0.0.1]) by mail217-ch1-R.bigfish.com (Postfix) with ESMTP id 5317C1E078E; Mon, 31 Mar 2014 19:14:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic85fh1432I1418I4015Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h9a9j1155h) Received-SPF: pass (mail217-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(24454002)(51444003)(189002)(377454003)(164054003)(51704005)(199002)(50986001)(97336001)(74316001)(81816001)(81686001)(54356001)(47736001)(77982001)(56776001)(76796001)(4396001)(85306002)(31966008)(54316002)(53806001)(66066001)(47976001)(95416001)(74706001)(74366001)(59766001)(49866001)(19609705001)(33646001)(94316002)(83072002)(63696002)(46102001)(15975445006)(94946001)(76576001)(76786001)(87266001)(18717965001)(51856001)(19300405004)(86362001)(561944002)(93136001)(80976001)(15202345003)(16236675002)(20776003)(65816001)(81542001)(80022001)(83322001)(19580395003)(69226001)(90146001)(47446002)(56816005)(79102001)(74662001)(2656002)(92566001)(19580405001)(74876001)(98676001)(97186001)(85852003)(93516002)(81342001)(95666003)(74502001)(99286001)(87936001)(76482001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:FF7F0D5.A3FA91F1.F3D33D77.9AE96979.20807; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail217-ch1 (localhost.localdomain [127.0.0.1]) by mail217-ch1 (MessageSwitch) id 139629328887337_11291; Mon, 31 Mar 2014 19:14:48 +0000 (UTC) Received: from CH1EHSMHS038.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248]) by mail217-ch1.bigfish.com (Postfix) with ESMTP id 0E4153C00E1; Mon, 31 Mar 2014 19:14:48 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS038.bigfish.com (10.43.69.247) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 31 Mar 2014 19:14:47 +0000 Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.435.0; Mon, 31 Mar 2014 19:14:46 +0000 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.898.11; Mon, 31 Mar 2014 19:14: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.0898.005; Mon, 31 Mar 2014 19:14:45 +0000 From: Ross Callon To: Alia Atlas , Acee Lindem Thread-Topic: killing bad drafts, RE: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QABSS6AAADXBgAAAPJxgAABW8uAAAn9PBA= Date: Mon, 31 Mar 2014 19:14:43 +0000 Message-ID: <1829c5ba591e4156af3c386266d7d25e@CO2PR05MB636.namprd05.prod.outlook.com> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> 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-forefront-prvs: 0167DB5752 Content-Type: multipart/alternative; boundary="_000_1829c5ba591e4156af3c386266d7d25eCO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/7UcLFfSzbzOXKImqtXR3-XdguiQ Cc: Adrian Farrel , Thomas Heide Clausen , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , Jamal Hadi Salim Subject: [RTG-DIR] killing bad drafts, RE: Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:15:02 -0000 --_000_1829c5ba591e4156af3c386266d7d25eCO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding Alia's comment: > It would be doing it earlier in the draft life-cycle when there is a chan= ce of improving or killing bad drafts that did make it past working group a= doption... I had been thinking of this "mentoring idea" as being distinct from a "one = time review" role that the directorate allegedly already plays, and involve= s having mentors be helpful to inexperienced authors writing drafts about w= orthy ideas. There are of course also some documents in the routing area that I might pe= rsonally prefer to see die or quietly go away. However, having a mentor ass= igned to a document for an extended period of time and specifically try to = kill a bad draft seems like a way to spend a lot of time and make people un= happy. Also, I doubt that the authors would be thrilled to have a mentor as= signed who is hostile to their work (there must be *someone* active in the = area who likes the work if it was adopted as a WG draft). I am skeptical re= garding whether this proposal is a good way to kill bad drafts. Thus I think that at least for the initial experiment if someone agrees to = be a mentor for a document then they are sort of implicitly implying that t= here is a germ of value there that they would like to see go forward. Ross From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Monday, March 31, 2014 10:19 AM To: Acee Lindem Cc: Adrian Farrel; Jamal Hadi Salim; Thomas Heide Clausen; rtg-dir@ietf.org= ; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Document Mentors Acee, Absolutely, this would be doing more work. It would be doing it earlier in= the draft life-cycle when there is a chance of improving or killing bad dr= afts that did make it past working group adoption. Having better drafts c= oming out out of WGLC seems to me to be a clear win - easier to understand,= better technology, common issues and nits addressed, faster to process thr= ough the endgame (IETF Last Call, IESG, IANA, etc). As for current scale, there are 187 WG drafts in routing plus 27 is IESG pr= ocessing. At the moment, the routing directorate is not highly loaded. Alia On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem > wrote: Hi Thomas, Jamal, and Adrian, I agree with Jamal on scaling. There may not be an order of magnitude diffe= rence between the number of drafts accepted as WG documents and those that = make it through WG last call but it is certainly some power of 2. Hence, we= 'd be increasing our workload by 2 to 4 times just in shear numbers without= even taking into account the fact that the bad drafts will take much more = time than the ones making it through WG last call. Thanks, Acee On Mar 31, 2014, at 9:12 AM, Thomas Clausen > wrote: > Jamal, > > On 31 Mar 2014, at 14:48, Jamal Hadi Salim > wrote: > >> The only hole i see is your scale/workload numbers dont take into >> consideration the fact that there could be a lot more spread than 200 ac= tive >> documents per year that are in between WG adoption to publication. >> And that at times that process takes a little longer. >> Jari's tools could provide some stats (and i could be therefore off), bu= t >> to make my point i will handwave and say it is a magnitude more docs, >> some of which a mentor is responsible for and some which are making >> progress. >> This means each of the 40 people is actively mentoring about 25 document= s >> per year. And lets say 60 over 3 years. You will need a large number of = people >> in the directorate to scale. > > Scalability is an issue in whatever we are designing in the IETF, to be s= ure. But I think that various documents are very heterogenous in nature. > > Some documents would be written by people who really do not need a mentor= ("Come here, Ross Callon, so that this whippersnapper can tell you how the= IETF works - and Adrian, now, let me explain to you what a good RFC looks = like" -- that just doesn't seem plausible to happen). > > Other documents would probably need the occasional review, but mostly be = consensual and developed by a well engaged WG, so the "mentor" would be mos= tly redundant, and just "be there" without doing much. > > A few documents would likely benefit from more continuing mentoring - une= xperienced IETFers as authors, but eager to learn the ropes. That's actuall= y the "good kind of effort" to spend, that's working on renewing the future= stock of RTG-DIR members and WG Chairs. I know that when I put pen to pape= r for the first time in the IETF decades ago, I'd have appreciated having h= ad a mentor. > > Further, I predict that many documents would likely be rather bursty in t= he efforts required. If I was to mentor a document, I'd probably want to sp= end a good chunk of effort around WG adoption on reviews, discussions with = the authors, commenting, learning what the WG wants with it - but, hopefull= y then it will drop to an occasional review (ideally, at least, looking at = the diff at each release), discussions on precise points and potential pitf= alls, and likely with another burst when the authors start preparing for WG= LC. > > I think that as long as the ADs are not mechanically dooling out document= s, but there's a human in the loop to whom we can say "Well, gee, I may men= tor just one document, but right now it's a full-time job to work with the = authors, could you ask Jamal to take thisone instead?" we'll do alright. > >> And then there's handoff challenges. If i am mentoring a doc that is >> not complete >> before i let go ... >> > > Worst case: think of the document taking over as "having just been called= for WG adoption", so provide a review, chat with the authors. Best case, y= ou have notes to hand over, or even sit down and have a beer with whoever t= akes over after you. > > Anything more complicated than that? > > Thomas > >> >> cheers, >> jamal >> >> >> >> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel > wrote: >>> Hi, >>> >>> One of the ideas to come out of the recent discussions is appointing a = mentor >>> per document from the time it is adopted by a Routing Area working grou= p until >>> it completes WG last call. >>> >>> This would be voluntary in two dimensions: >>> - the WG chairs would need to deem that one would be beneficial >>> - we would have to find someone from the Directorate willing to >>> take on the document. >>> >>> We don't think that technology expertise is as useful in this as IETF c= lue and >>> general routing experience. >>> >>> So, to take this forward we would need: >>> - WG chairs to say "Yes, we can see that that would have >>> potential benefit >>> - Directorate members to say "Yes, we could take on that >>> additional work. >>> >>> Alia and I have put together some preliminary notes on how this would a= ll hang >>> together. >>> >>> Your opinions and rotten fruit are solicited. >>> >>> Thanks, >>> Adrian and Alia >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Document Mentors in the Routing Area >>> >>> The Problems: >>> >>> a) Drafts get little review outside the working group and sometimes ins= ide >>> the working group until after working group last call. At that point it= is >>> often >>> painful and costly to make meaningful improvements to the drafts. >>> >>> b) Authors may not know how or whom to ask for assistance or review >>> (e.g., IANA section, Security Section, Operational and Management >>> considerations, details of a protocol, etc. ). >>> >>> The Goals: >>> >>> a) Excellent and consistent review at WG adoption and before WG last >>> call. >>> >>> b) Ability for prolonged discussion and problem-solving when the >>> draft can still be easily enhanced. >>> >>> c) Reduced time to delivery of RFCs. >>> >>> d) Quality documents. >>> >>> The Solution: >>> >>> A per-document mentor who is a known neutral party to whom the >>> authors can go for advice on: >>> - how to write a section >>> - specific issues that arise >>> - ways to resolve conflicts. >>> >>> The document mentor also watches the progress of the document >>> and gives advice and steerage. >>> >>> It is not assumed that every document will need or benefit from >>> having a mentor. >>> >>> The Expected Workload: >>> >>> The routing directorate has approximately 40 people. If we assume >>> that approximately 50 drafts pass WG adoption and a similar number >>> pass WGLC each year, then the load is 2.5 documents per person >>> per year. If we assume that there are about 200 WG drafts in the >>> Routing Area and that they all have mentors, then each Routing >>> Directorate member will have 5 drafts that she or he is mentoring. >>> >>> The Supporting Data Artefacts: >>> >>> a) As part of the Routing Area wiki, the areas of knowledge for >>> each member of the Routing Directorate will be publicly specified. >>> This is added to the wiki by the Routing Area Coordinators (or AD) >>> when the member joins the Routing Directorate, updated by the >>> member while he or she is on the Directorate, and updated by the >>> Routing Area Coordinators (or AD) if and when the member's term >>> renews. >>> >>> b) Document Mentor Availability and Assignments: As part of the >>> Routing Area wiki, each Directorate member will specify the maximum >>> number of documents that he or she is able to mentor. Also listed >>> will be the list of mentored documents (and a count). >>> >>> i) When a Directorate member is assigned as the Document >>> mentor, the Routing Directorate Coordinator will update the >>> wiki page and create a wiki page for the draft. >>> >>> ii) When a Document Mentor provides a review, that should be >>> stored in the draft's wiki page along with the resolutions. >>> >>> iii) When the Document Mentor's final review at WGLC is done, >>> the Document Mentor should move the draft to a list of >>> "previously mentored documents" associated with their name. >>> It is ideal to write up a summary of the document mentoring exper= ience. >>> >>> c) Unmentored Documents: Drafts which have declined a document >>> mentor should be listed on a wiki page. >>> >>> d) For each WG's wiki, it'd be useful to have the list of drafts >>> with their associated Document Mentors (or lack thereof) and the >>> link to the draft's wiki page. >>> >>> The Basic Process: >>> >>> When a new WG draft is adopted, the WG chairs and the Routing >>> Directorate Coordinators discuss and agree on possible Document >>> Mentors (up to 3). Then the Routing Directorate Coordinator >>> confirms with the Routing Directorate members about their >>> availability and willingness to mentor this particular draft. Once >>> one is selected, the Routing Directorate Coordinator updates the >>> wiki and notifies the WG chairs and draft authors. >>> >>> a) With the agreement of the ADs, a Document Mentor who is not a >>> member of the Routing Directorate may be selected. >>> >>> b) The WG chairs can, after consulting with the draft authors, >>> decline to have a Document Mentor. >>> >>> c) The Document Mentor should coordinate with the Document >>> Shepherd for hand-off after WGLC. >>> >>> >>> >>> >> > --_000_1829c5ba591e4156af3c386266d7d25eCO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding Alia’s co= mment:

 <= /p>

> It would be doing it= earlier in the draft life-cycle when there is a chance of improving or kil= ling bad drafts that did make it past working group adoption…

 <= /p>

I had been thinking of th= is “mentoring idea” as being distinct from a “one time re= view” role that the directorate allegedly already plays, and involves= having mentors be helpful to inexperienced authors writing drafts about worthy id= eas.

 <= /p>

There are of course also = some documents in the routing area that I might personally prefer to see di= e or quietly go away. However, having a mentor assigned to a document for an extended period of time and specifically try to kill = a bad draft seems like a way to spend a lot of time and make people unhappy= . Also, I doubt that the authors would be thrilled to have a mentor assigne= d who is hostile to their work (there must be *someone* active in the area who likes the work if it was a= dopted as a WG draft). I am skeptical regarding whether this proposal is a = good way to kill bad drafts.

 <= /p>

Thus I think that at leas= t for the initial experiment if someone agrees to be a mentor for a documen= t then they are sort of implicitly implying that there is a germ of value there that they would like to see go forward. <= /span>

 <= /p>

Ross

 <= /p>

From: rtg-dir = [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Monday, March 31, 2014 10:19 AM
To: Acee Lindem
Cc: Adrian Farrel; Jamal Hadi Salim; Thomas Heide Clausen; rtg-dir@i= etf.org; rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] Document Mentors

 

Acee,

 

Absolutely, this would be doing more work.  It = would be doing it earlier in the draft life-cycle when there is a chance of= improving or killing bad drafts that did make it past working group adopti= on.   Having better drafts coming out out of WGLC seems to me to be a clear win - easier to understand, better techn= ology, common issues and nits addressed, faster to process through the endg= ame (IETF Last Call, IESG, IANA, etc).

 

As for current scale, there are 187 WG drafts in rou= ting plus 27 is IESG processing.  At the moment, the routing directora= te is not highly loaded.   

 

Alia

 

On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem <acee.lindem@eric= sson.com> wrote:

Hi Thomas, Jamal, and Adrian,
I agree with Jamal on scaling. There may not be an order of magnitude diffe= rence between the number of drafts accepted as WG documents and those that = make it through WG last call but it is certainly some power of 2. Hence, we= ’d be increasing our workload by 2 to 4 times just in shear numbers without even taking into account the fa= ct that the bad drafts will take much more time than the ones making it thr= ough WG last call.
Thanks,
Acee



On Mar 31, 2014, at 9:12 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:

> Jamal,
>
> On 31 Mar 2014, at 14:48, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>
>> The only hole i see is your scale/workload numbers dont take into<= br> >> consideration the fact that there could be a lot more spread than = 200 active
>> documents per year that are in between WG adoption to publication.=
>> And that at times that process takes a little longer.
>> Jari's tools could provide some stats (and i could be therefore of= f), but
>> to make my point  i will handwave and say it is a magnitude m= ore docs,
>> some of which a mentor is responsible for and some which are makin= g
>> progress.
>> This means each of the 40 people is actively mentoring about 25 do= cuments
>> per year. And lets say 60 over 3 years. You will need a large numb= er of people
>> in the directorate to scale.
>
> Scalability is an issue in whatever we are designing in the IETF, to b= e sure. But I think that various documents are very heterogenous in nature.=
>
> Some documents would be written by people who really do not need a men= tor ("Come here, Ross Callon, so that this whippersnapper can tell you= how the IETF works - and Adrian, now, let me explain to you what a good RF= C looks like" -- that just doesn't seem plausible to happen).
>
> Other documents would probably need the occasional review, but mostly = be consensual and developed by a well engaged WG, so the "mentor"= would be mostly redundant, and just "be there" without doing muc= h.
>
> A few documents would likely benefit from more continuing mentoring - = unexperienced IETFers as authors, but eager to learn the ropes. That's actu= ally the "good kind of effort" to spend, that's working on renewi= ng the future stock of RTG-DIR members and WG Chairs. I know that when I put pen to paper for the first time in the IETF= decades ago, I'd have appreciated having had a mentor.
>
> Further, I predict that many documents would likely be rather bursty i= n the efforts required. If I was to mentor a document, I'd probably want to= spend a good chunk of effort around WG adoption on reviews, discussions wi= th the authors, commenting, learning what the WG wants with it - but, hopefully then it will drop to an occasio= nal review (ideally, at least, looking at the diff at each release), discus= sions on precise points and potential pitfalls, and likely with another bur= st when the authors start preparing for WGLC.
>
> I think that as long as the ADs are not mechanically dooling out docum= ents, but there's a human in the loop to whom we can say "Well, gee, I= may mentor just one document, but right now it's a full-time job to work w= ith the authors, could you ask Jamal to take thisone instead?" we'll do alright.
>
>> And then there's handoff challenges. If i am mentoring a doc that = is
>> not complete
>> before i let go ...
>>
>
> Worst case: think of the document taking over as "having just bee= n called for WG adoption", so provide a review, chat with the authors.= Best case, you have notes to hand over, or even sit down and have a beer w= ith whoever takes over after you.
>
> Anything more complicated than that?
>
> Thomas
>
>>
>> cheers,
>> jamal
>>
>>
>>
>> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
>>> Hi,
>>>
>>> One of the ideas to come out of the recent discussions is appo= inting a mentor
>>> per document from the time it is adopted by a Routing Area wor= king group until
>>> it completes WG last call.
>>>
>>> This would be voluntary in two dimensions:
>>> - the WG chairs would need to deem that one would be beneficia= l
>>> - we would have to find someone from the Directorate willing t= o
>>>  take on the document.
>>>
>>> We don't think that technology expertise is as useful in this = as IETF clue and
>>> general routing experience.
>>>
>>> So, to take this forward we would need:
>>> - WG chairs to say "Yes, we can see that that would have<= br> >>>  potential benefit
>>> - Directorate members to say "Yes, we could take on that<= br> >>> additional work.
>>>
>>> Alia and I have put together some preliminary notes on how thi= s would all hang
>>> together.
>>>
>>> Your opinions and rotten fruit are solicited.
>>>
>>> Thanks,
>>> Adrian and Alia
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> Document Mentors in the Routing Area
>>>
>>> The Problems:
>>>
>>> a) Drafts get little review outside the working group and some= times inside
>>> the working group until after working group last call. At that= point it is
>>> often
>>> painful and costly to make meaningful improvements to the draf= ts.
>>>
>>> b) Authors may not know how or whom to ask for assistance &nbs= p;or review
>>> (e.g., IANA section, Security Section, Operational and Managem= ent
>>> considerations, details of a protocol, etc. ).
>>>
>>> The Goals:
>>>
>>> a) Excellent and consistent review at WG adoption and before W= G last
>>> call.
>>>
>>> b) Ability for prolonged discussion and problem-solving when t= he
>>> draft can still be easily enhanced.
>>>
>>> c) Reduced time to delivery of RFCs.
>>>
>>> d) Quality documents.
>>>
>>> The Solution:
>>>
>>> A per-document mentor who is a known neutral party to whom the=
>>> authors can go for advice on:
>>> - how to write a section
>>> - specific issues that arise
>>> - ways to resolve conflicts.
>>>
>>> The document mentor also watches the progress of the document<= br> >>> and gives advice and steerage.
>>>
>>> It is not assumed that every document will need or benefit fro= m
>>> having a mentor.
>>>
>>> The Expected Workload:
>>>
>>>  The routing directorate has approximately 40 people. &nb= sp;If we assume
>>>  that approximately 50 drafts pass WG adoption and a simi= lar number
>>>  pass WGLC each year, then the load is 2.5 documents per = person
>>>  per year.  If we assume that there are about 200 WG= drafts in the
>>>  Routing Area and that they all have mentors, then each R= outing
>>>  Directorate member will have 5 drafts that she or he is = mentoring.
>>>
>>> The Supporting Data Artefacts:
>>>
>>>  a) As part of the Routing Area wiki, the areas of knowle= dge for
>>>  each member of the Routing Directorate will be publicly = specified.
>>>  This is added to the wiki by the Routing Area Coordinato= rs (or AD)
>>>  when the member joins the Routing Directorate, updated b= y the
>>>  member while he or she is on the Directorate, and update= d by the
>>>  Routing Area Coordinators (or AD) if and when the member= 's term
>>>  renews.
>>>
>>>  b) Document Mentor Availability and Assignments: As part= of the
>>>  Routing Area wiki, each Directorate member will specify = the maximum
>>>  number of documents that he or she is able to mentor. &n= bsp;Also listed
>>>  will be the list of mentored documents (and a count). >>>
>>>       i) When a Directorate member is assigned = as the Document
>>>       mentor, the Routing Directorate Coordinat= or will update the
>>>       wiki page and create a wiki page for the = draft.
>>>
>>>       ii) When a Document Mentor provides a rev= iew, that should be
>>>       stored in the draft's wiki page along wit= h the resolutions.
>>>
>>>       iii) When the Document Mentor's final rev= iew at WGLC is done,
>>>       the Document Mentor should move the draft= to a list of
>>>       "previously mentored documents"= associated with their name.
>>>       It is ideal to write up a summary of the = document mentoring experience.
>>>
>>>  c) Unmentored Documents: Drafts which have declined a do= cument
>>>  mentor should be listed on a wiki page.
>>>
>>>  d) For each WG's wiki, it'd be useful to have the list o= f drafts
>>>  with their associated Document Mentors (or lack thereof)= and the
>>>  link to the draft's wiki page.
>>>
>>> The Basic Process:
>>>
>>> When a new WG draft is adopted, the WG chairs and the Routing<= br> >>> Directorate Coordinators discuss and agree on possible Documen= t
>>> Mentors (up to 3).  Then the Routing Directorate Coordina= tor
>>> confirms with the Routing Directorate members about their
>>> availability and willingness to mentor this particular draft. = Once
>>> one is selected, the Routing Directorate Coordinator updates t= he
>>> wiki and notifies the WG chairs and draft authors.
>>>
>>>    a) With the agreement of the ADs, a Document Ment= or who is not a
>>>    member of the Routing Directorate may be selected= .
>>>
>>>    b) The WG chairs can, after consulting with the d= raft authors,
>>>    decline to have a Document Mentor.
>>>
>>>    c) The Document Mentor should coordinate with the= Document
>>>    Shepherd for hand-off after WGLC.
>>>
>>>
>>>
>>>
>>
>

 

--_000_1829c5ba591e4156af3c386266d7d25eCO2PR05MB636namprd05pro_-- From nobody Mon Mar 31 12:20:09 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F09D1A6F6C; Mon, 31 Mar 2014 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 scpWO5-kj2Ox; Mon, 31 Mar 2014 12:20:03 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id D8E3A1A08BE; Mon, 31 Mar 2014 12:20:02 -0700 (PDT) Received: from mail131-va3-R.bigfish.com (10.7.14.225) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Mar 2014 19:19:58 +0000 Received: from mail131-va3 (localhost [127.0.0.1]) by mail131-va3-R.bigfish.com (Postfix) with ESMTP id 15F4F801A4; Mon, 31 Mar 2014 19:19:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(zz9371I542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzdchz1de098h1033IL8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh26c8h9a9j1155h) Received-SPF: pass (mail131-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(13464003)(199002)(377454003)(164054003)(189002)(81542001)(80976001)(20776003)(65816001)(79102001)(56816005)(90146001)(47446002)(69226001)(19580395003)(80022001)(83322001)(87266001)(76576001)(76786001)(93136001)(2201001)(86362001)(51856001)(74502001)(99286001)(81342001)(95666003)(76482001)(87936001)(2656002)(92566001)(74662001)(19580405001)(97186001)(93516002)(85852003)(74876001)(98676001)(4396001)(76796001)(85306002)(31966008)(56776001)(54356001)(81686001)(47736001)(77982001)(53806001)(66066001)(54316002)(97336001)(50986001)(74316001)(81816001)(83072002)(63696002)(94316002)(46102001)(94946001)(95416001)(47976001)(74706001)(49866001)(59766001)(33646001)(74366001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:2FFCF25D.ABDA97F1.70D3BDBB.8AED6971.20538; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail131-va3 (localhost.localdomain [127.0.0.1]) by mail131-va3 (MessageSwitch) id 1396293596338017_9755; Mon, 31 Mar 2014 19:19:56 +0000 (UTC) Received: from VA3EHSMHS031.bigfish.com (unknown [10.7.14.236]) by mail131-va3.bigfish.com (Postfix) with ESMTP id 4C1F660079; Mon, 31 Mar 2014 19:19:56 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS031.bigfish.com (10.7.99.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 31 Mar 2014 19:19:56 +0000 Received: from CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.435.0; Mon, 31 Mar 2014 19:19:55 +0000 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.898.11; Mon, 31 Mar 2014 19:19:53 +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.0898.005; Mon, 31 Mar 2014 19:19:53 +0000 From: Ross Callon To: "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QAO1hxQ Date: Mon, 31 Mar 2014 19:19:53 +0000 Message-ID: <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> In-Reply-To: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.12] x-forefront-prvs: 0167DB5752 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/AYHUze29xd6yAlbG6UTqqnwkYDU Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:20:08 -0000 It seems to me that if a document has experienced authors who are productiv= e IETF regulars, then they probably don't need a mentor on an ongoing basis= . They might benefit from a one-time review. Thus the question: Would this be limited to documents with inexperienced au= thors? As WG chairs do we envision other reasons why a particular document = might benefit from a mentor? (perhaps a document that needs a strong mathem= atician or a security expert or a link state routing expert to help with on= e section)?=20 Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, March 31, 2014 8:12 AM To: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: [RTG-DIR] Document Mentors Hi, One of the ideas to come out of the recent discussions is appointing a ment= or per document from the time it is adopted by a Routing Area working group un= til it completes WG last call. This would be voluntary in two dimensions: - the WG chairs would need to deem that one would be beneficial - we would have to find someone from the Directorate willing to take on the document. We don't think that technology expertise is as useful in this as IETF clue = and general routing experience. So, to take this forward we would need: - WG chairs to say "Yes, we can see that that would have potential benefit - Directorate members to say "Yes, we could take on that additional work. Alia and I have put together some preliminary notes on how this would all h= ang together. Your opinions and rotten fruit are solicited. Thanks, Adrian and Alia =3D=3D=3D=3D=3D=3D=3D=3D=3D Document Mentors in the Routing Area The Problems:=20 a) Drafts get little review outside the working group and sometimes insid= e=20 the working group until after working group last call. At that point it i= s often painful and costly to make meaningful improvements to the drafts. b) Authors may not know how or whom to ask for assistance or review=20 (e.g., IANA section, Security Section, Operational and Management considerations, details of a protocol, etc. ). The Goals: a) Excellent and consistent review at WG adoption and before WG last call. =20 b) Ability for prolonged discussion and problem-solving when the draft can still be easily enhanced. c) Reduced time to delivery of RFCs. d) Quality documents. The Solution: A per-document mentor who is a known neutral party to whom the authors can go for advice on: - how to write a section - specific issues that arise - ways to resolve conflicts. The document mentor also watches the progress of the document and gives advice and steerage. It is not assumed that every document will need or benefit from=20 having a mentor. The Expected Workload: The routing directorate has approximately 40 people. If we assume that approximately 50 drafts pass WG adoption and a similar number pass WGLC each year, then the load is 2.5 documents per person per year. If we assume that there are about 200 WG drafts in the Routing Area and that they all have mentors, then each Routing Directorate member will have 5 drafts that she or he is mentoring. The Supporting Data Artefacts: a) As part of the Routing Area wiki, the areas of knowledge for each member of the Routing Directorate will be publicly specified. This is added to the wiki by the Routing Area Coordinators (or AD) when the member joins the Routing Directorate, updated by the member while he or she is on the Directorate, and updated by the Routing Area Coordinators (or AD) if and when the member's term renews. b) Document Mentor Availability and Assignments: As part of the Routing Area wiki, each Directorate member will specify the maximum number of documents that he or she is able to mentor. Also listed will be the list of mentored documents (and a count). i) When a Directorate member is assigned as the Document mentor, the Routing Directorate Coordinator will update the wiki page and create a wiki page for the draft. ii) When a Document Mentor provides a review, that should be stored in the draft's wiki page along with the resolutions. iii) When the Document Mentor's final review at WGLC is done, the Document Mentor should move the draft to a list of "previously mentored documents" associated with their name. It is ideal to write up a summary of the document mentoring experie= nce. c) Unmentored Documents: Drafts which have declined a document mentor should be listed on a wiki page. d) For each WG's wiki, it'd be useful to have the list of drafts with their associated Document Mentors (or lack thereof) and the link to the draft's wiki page. The Basic Process: When a new WG draft is adopted, the WG chairs and the Routing Directorate Coordinators discuss and agree on possible Document Mentors (up to 3). Then the Routing Directorate Coordinator confirms with the Routing Directorate members about their availability and willingness to mentor this particular draft. Once one is selected, the Routing Directorate Coordinator updates the wiki and notifies the WG chairs and draft authors. a) With the agreement of the ADs, a Document Mentor who is not a member of the Routing Directorate may be selected. b) The WG chairs can, after consulting with the draft authors, decline to have a Document Mentor. =20 c) The Document Mentor should coordinate with the Document Shepherd for hand-off after WGLC. From nobody Mon Mar 31 13:05:00 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EAB1A08C3; Mon, 31 Mar 2014 13:04:54 -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 M8irxR5cLdJm; Mon, 31 Mar 2014 13:04:49 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 327E91A6F78; Mon, 31 Mar 2014 13:04:48 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 142so3731488ykq.27 for ; Mon, 31 Mar 2014 13:04:44 -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=zwsqh0ips3OOZmh025E4N5hR0Ptv8uYvwadABBK9ZXs=; b=goGuCFYdcoS8JXvs/GbYOBqE1tqNBYT2yKyNXXNyLJw+XQUVSmBbCfw4W820Oqa4zn FO1xPAxkBZGPl6NN5cxWOc95Nqkc7ExSbyofHQWcGC5NE+69jRGg9fqTR7d5+ZGDqOhH 9xQjkjMCPbDGM7qJX+ZqBL9a95v2MMZd9RQtdANTE4Pq3j32zMliJXJE/Xt8x80Oq5fP OVScLCjQZCs3+IgMq53PRDAcBV4Aqyry/MmyxGFH4Q6ll7LNKyTOmLSTNj+FDOhJnFA4 X0rsGehofQChWx3cBpQYpiOnds57qrsEwk8T/lr3jUb93ZKVIR6qzfT0+n7H3Aw7Y5VD OK8Q== MIME-Version: 1.0 X-Received: by 10.236.168.42 with SMTP id j30mr6010207yhl.101.1396296284834; Mon, 31 Mar 2014 13:04:44 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 13:04:44 -0700 (PDT) In-Reply-To: <1829c5ba591e4156af3c386266d7d25e@CO2PR05MB636.namprd05.prod.outlook.com> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <25A2CA65-6137-447A-937D-215144C25B2E@thomasclausen.org> <1829c5ba591e4156af3c386266d7d25e@CO2PR05MB636.namprd05.prod.outlook.com> Date: Mon, 31 Mar 2014 16:04:44 -0400 Message-ID: From: Alia Atlas To: Ross Callon Content-Type: multipart/alternative; boundary=20cf305b13de0f112c04f5ec9086 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/fuT-Re33tUC4oy6lkMyrAPhd0sU Cc: "rtg-dir@ietf.org" , Jamal Hadi Salim , Acee Lindem , Thomas Heide Clausen , "rtg-chairs@ietf.org" , Adrian Farrel Subject: Re: [RTG-DIR] killing bad drafts, RE: Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:04:55 -0000 --20cf305b13de0f112c04f5ec9086 Content-Type: text/plain; charset=ISO-8859-1 Ross, Recall that the idea for a Document Mentor was generated from the expressed desire to have reviews done earlier so that there could be actually technical impact and ability to request fixes and improvements which are not possible at IETF LC time. I would be happy to see suggestions for improvements in the write-up that Adrian sent out. A document mentor is supposed to be neutral - not for or against before hand - and is a mentor (maybe a better word?) for the document, doing the two consistent reviews and suggesting how to get the necessary sections in. I think that WG chairs are currently empowered to refuse bad drafts, that a few people thinking the idea may be ok need not indicate that it should progress, and that additional good reviews are useful. Regards, Alia On Mon, Mar 31, 2014 at 3:14 PM, Ross Callon wrote: > Regarding Alia's comment: > > > > > It would be doing it earlier in the draft life-cycle when there is a > chance of improving or killing bad drafts that did make it past working > group adoption... > > > > I had been thinking of this "mentoring idea" as being distinct from a "one > time review" role that the directorate allegedly already plays, and > involves having mentors be helpful to inexperienced authors writing drafts > about worthy ideas. > > > > There are of course also some documents in the routing area that I might > personally prefer to see die or quietly go away. However, having a mentor > assigned to a document for an extended period of time and specifically try > to kill a bad draft seems like a way to spend a lot of time and make people > unhappy. Also, I doubt that the authors would be thrilled to have a mentor > assigned who is hostile to their work (there must be **someone** active > in the area who likes the work if it was adopted as a WG draft). I am > skeptical regarding whether this proposal is a good way to kill bad drafts. > > > > Thus I think that at least for the initial experiment if someone agrees to > be a mentor for a document then they are sort of implicitly implying that > there is a germ of value there that they would like to see go forward. > > > > Ross > > > > *From:* rtg-dir [mailto:rtg-dir-bounces@ietf.org] *On Behalf Of *Alia > Atlas > *Sent:* Monday, March 31, 2014 10:19 AM > *To:* Acee Lindem > *Cc:* Adrian Farrel; Jamal Hadi Salim; Thomas Heide Clausen; > rtg-dir@ietf.org; rtg-chairs@ietf.org > *Subject:* Re: [RTG-DIR] Document Mentors > > > > Acee, > > > > Absolutely, this would be doing more work. It would be doing it earlier > in the draft life-cycle when there is a chance of improving or killing bad > drafts that did make it past working group adoption. Having better drafts > coming out out of WGLC seems to me to be a clear win - easier to > understand, better technology, common issues and nits addressed, faster to > process through the endgame (IETF Last Call, IESG, IANA, etc). > > > > As for current scale, there are 187 WG drafts in routing plus 27 is IESG > processing. At the moment, the routing directorate is not highly loaded. > > > > Alia > > > > On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem > wrote: > > Hi Thomas, Jamal, and Adrian, > I agree with Jamal on scaling. There may not be an order of magnitude > difference between the number of drafts accepted as WG documents and those > that make it through WG last call but it is certainly some power of 2. > Hence, we'd be increasing our workload by 2 to 4 times just in shear > numbers without even taking into account the fact that the bad drafts will > take much more time than the ones making it through WG last call. > Thanks, > Acee > > > > On Mar 31, 2014, at 9:12 AM, Thomas Clausen > wrote: > > > Jamal, > > > > On 31 Mar 2014, at 14:48, Jamal Hadi Salim wrote: > > > >> The only hole i see is your scale/workload numbers dont take into > >> consideration the fact that there could be a lot more spread than 200 > active > >> documents per year that are in between WG adoption to publication. > >> And that at times that process takes a little longer. > >> Jari's tools could provide some stats (and i could be therefore off), > but > >> to make my point i will handwave and say it is a magnitude more docs, > >> some of which a mentor is responsible for and some which are making > >> progress. > >> This means each of the 40 people is actively mentoring about 25 > documents > >> per year. And lets say 60 over 3 years. You will need a large number of > people > >> in the directorate to scale. > > > > Scalability is an issue in whatever we are designing in the IETF, to be > sure. But I think that various documents are very heterogenous in nature. > > > > Some documents would be written by people who really do not need a > mentor ("Come here, Ross Callon, so that this whippersnapper can tell you > how the IETF works - and Adrian, now, let me explain to you what a good RFC > looks like" -- that just doesn't seem plausible to happen). > > > > Other documents would probably need the occasional review, but mostly be > consensual and developed by a well engaged WG, so the "mentor" would be > mostly redundant, and just "be there" without doing much. > > > > A few documents would likely benefit from more continuing mentoring - > unexperienced IETFers as authors, but eager to learn the ropes. That's > actually the "good kind of effort" to spend, that's working on renewing the > future stock of RTG-DIR members and WG Chairs. I know that when I put pen > to paper for the first time in the IETF decades ago, I'd have appreciated > having had a mentor. > > > > Further, I predict that many documents would likely be rather bursty in > the efforts required. If I was to mentor a document, I'd probably want to > spend a good chunk of effort around WG adoption on reviews, discussions > with the authors, commenting, learning what the WG wants with it - but, > hopefully then it will drop to an occasional review (ideally, at least, > looking at the diff at each release), discussions on precise points and > potential pitfalls, and likely with another burst when the authors start > preparing for WGLC. > > > > I think that as long as the ADs are not mechanically dooling out > documents, but there's a human in the loop to whom we can say "Well, gee, I > may mentor just one document, but right now it's a full-time job to work > with the authors, could you ask Jamal to take thisone instead?" we'll do > alright. > > > >> And then there's handoff challenges. If i am mentoring a doc that is > >> not complete > >> before i let go ... > >> > > > > Worst case: think of the document taking over as "having just been > called for WG adoption", so provide a review, chat with the authors. Best > case, you have notes to hand over, or even sit down and have a beer with > whoever takes over after you. > > > > Anything more complicated than that? > > > > Thomas > > > >> > >> cheers, > >> jamal > >> > >> > >> > >> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel > wrote: > >>> Hi, > >>> > >>> One of the ideas to come out of the recent discussions is appointing a > mentor > >>> per document from the time it is adopted by a Routing Area working > group until > >>> it completes WG last call. > >>> > >>> This would be voluntary in two dimensions: > >>> - the WG chairs would need to deem that one would be beneficial > >>> - we would have to find someone from the Directorate willing to > >>> take on the document. > >>> > >>> We don't think that technology expertise is as useful in this as IETF > clue and > >>> general routing experience. > >>> > >>> So, to take this forward we would need: > >>> - WG chairs to say "Yes, we can see that that would have > >>> potential benefit > >>> - Directorate members to say "Yes, we could take on that > >>> additional work. > >>> > >>> Alia and I have put together some preliminary notes on how this would > all hang > >>> together. > >>> > >>> Your opinions and rotten fruit are solicited. > >>> > >>> Thanks, > >>> Adrian and Alia > >>> > >>> ========= > >>> > >>> Document Mentors in the Routing Area > >>> > >>> The Problems: > >>> > >>> a) Drafts get little review outside the working group and sometimes > inside > >>> the working group until after working group last call. At that point > it is > >>> often > >>> painful and costly to make meaningful improvements to the drafts. > >>> > >>> b) Authors may not know how or whom to ask for assistance or review > >>> (e.g., IANA section, Security Section, Operational and Management > >>> considerations, details of a protocol, etc. ). > >>> > >>> The Goals: > >>> > >>> a) Excellent and consistent review at WG adoption and before WG last > >>> call. > >>> > >>> b) Ability for prolonged discussion and problem-solving when the > >>> draft can still be easily enhanced. > >>> > >>> c) Reduced time to delivery of RFCs. > >>> > >>> d) Quality documents. > >>> > >>> The Solution: > >>> > >>> A per-document mentor who is a known neutral party to whom the > >>> authors can go for advice on: > >>> - how to write a section > >>> - specific issues that arise > >>> - ways to resolve conflicts. > >>> > >>> The document mentor also watches the progress of the document > >>> and gives advice and steerage. > >>> > >>> It is not assumed that every document will need or benefit from > >>> having a mentor. > >>> > >>> The Expected Workload: > >>> > >>> The routing directorate has approximately 40 people. If we assume > >>> that approximately 50 drafts pass WG adoption and a similar number > >>> pass WGLC each year, then the load is 2.5 documents per person > >>> per year. If we assume that there are about 200 WG drafts in the > >>> Routing Area and that they all have mentors, then each Routing > >>> Directorate member will have 5 drafts that she or he is mentoring. > >>> > >>> The Supporting Data Artefacts: > >>> > >>> a) As part of the Routing Area wiki, the areas of knowledge for > >>> each member of the Routing Directorate will be publicly specified. > >>> This is added to the wiki by the Routing Area Coordinators (or AD) > >>> when the member joins the Routing Directorate, updated by the > >>> member while he or she is on the Directorate, and updated by the > >>> Routing Area Coordinators (or AD) if and when the member's term > >>> renews. > >>> > >>> b) Document Mentor Availability and Assignments: As part of the > >>> Routing Area wiki, each Directorate member will specify the maximum > >>> number of documents that he or she is able to mentor. Also listed > >>> will be the list of mentored documents (and a count). > >>> > >>> i) When a Directorate member is assigned as the Document > >>> mentor, the Routing Directorate Coordinator will update the > >>> wiki page and create a wiki page for the draft. > >>> > >>> ii) When a Document Mentor provides a review, that should be > >>> stored in the draft's wiki page along with the resolutions. > >>> > >>> iii) When the Document Mentor's final review at WGLC is done, > >>> the Document Mentor should move the draft to a list of > >>> "previously mentored documents" associated with their name. > >>> It is ideal to write up a summary of the document mentoring > experience. > >>> > >>> c) Unmentored Documents: Drafts which have declined a document > >>> mentor should be listed on a wiki page. > >>> > >>> d) For each WG's wiki, it'd be useful to have the list of drafts > >>> with their associated Document Mentors (or lack thereof) and the > >>> link to the draft's wiki page. > >>> > >>> The Basic Process: > >>> > >>> When a new WG draft is adopted, the WG chairs and the Routing > >>> Directorate Coordinators discuss and agree on possible Document > >>> Mentors (up to 3). Then the Routing Directorate Coordinator > >>> confirms with the Routing Directorate members about their > >>> availability and willingness to mentor this particular draft. Once > >>> one is selected, the Routing Directorate Coordinator updates the > >>> wiki and notifies the WG chairs and draft authors. > >>> > >>> a) With the agreement of the ADs, a Document Mentor who is not a > >>> member of the Routing Directorate may be selected. > >>> > >>> b) The WG chairs can, after consulting with the draft authors, > >>> decline to have a Document Mentor. > >>> > >>> c) The Document Mentor should coordinate with the Document > >>> Shepherd for hand-off after WGLC. > >>> > >>> > >>> > >>> > >> > > > > > --20cf305b13de0f112c04f5ec9086 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ross,

Recall that the idea for a Docume= nt Mentor was generated from the expressed desire to have reviews done earl= ier
so that there could be actually technical impact and ability = to request fixes and improvements which are not possible
at IETF LC time.

I would be happy to see sugg= estions for improvements in the write-up that Adrian sent out.  
=

A document mentor is supposed to be neutral - not for o= r against before hand - and is a mentor (maybe a better word?)
for the document, doing the two consistent reviews and suggesting how = to get the necessary sections in.

I think that WG = chairs are currently empowered to refuse bad drafts, that a few people thin= king the idea may be ok
need not indicate that it should progress, and that additional good re= views are useful.

Regards,
Alia


On Mon, Ma= r 31, 2014 at 3:14 PM, Ross Callon <rcallon@juniper.net> w= rote:

Regarding Alia’s co= mment:

 

> It would be doing it= earlier in the draft life-cycle when there is a chance of improving or kil= ling bad drafts that did make it past working group adoption…=

 

I had been thinking of th= is “mentoring idea” as being distinct from a “one time re= view” role that the directorate allegedly already plays, and involves= having mentors be helpful to inexperienced authors writing drafts about worthy id= eas.

 

There are of course also = some documents in the routing area that I might personally prefer to see di= e or quietly go away. However, having a mentor assigned to a document for an extended period of time and specifically try to kill = a bad draft seems like a way to spend a lot of time and make people unhappy= . Also, I doubt that the authors would be thrilled to have a mentor assigne= d who is hostile to their work (there must be *someone* active in the area who likes the work if it was a= dopted as a WG draft). I am skeptical regarding whether this proposal is a = good way to kill bad drafts.

 

Thus I think that at leas= t for the initial experiment if someone agrees to be a mentor for a documen= t then they are sort of implicitly implying that there is a germ of value there that they would like to see go forward.

 

Ross=

 

From: rtg-dir = [mailto:rtg-d= ir-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Monday, March 31, 2014 10:19 AM
To: Acee Lindem
Cc: Adrian Farrel; Jamal Hadi Salim; Thomas Heide Clausen; rtg-dir@ietf.org; rtg-chairs@ietf.org<= br> Subject: Re: [RTG-DIR] Document Mentors

 

Acee,

 

Absolutely, this would be doing more work.  It = would be doing it earlier in the draft life-cycle when there is a chance of= improving or killing bad drafts that did make it past working group adopti= on.   Having better drafts coming out out of WGLC seems to me to be a clear win - easier to understand, better techn= ology, common issues and nits addressed, faster to process through the endg= ame (IETF Last Call, IESG, IANA, etc).

 

As for current scale, there are 187 WG drafts in rou= ting plus 27 is IESG processing.  At the moment, the routing directora= te is not highly loaded.   

 

Alia

 <= /p>

On Mon, Mar 31, 2014 at 9:40 AM, Acee Lindem <acee.lindem@eric= sson.com> wrote:

Hi Thomas, Jamal, and Adrian,
I agree with Jamal on scaling. There may not be an order of magnitude diffe= rence between the number of drafts accepted as WG documents and those that = make it through WG last call but it is certainly some power of 2. Hence, we= ’d be increasing our workload by 2 to 4 times just in shear numbers without even taking into account the fa= ct that the bad drafts will take much more time than the ones making it thr= ough WG last call.
Thanks,
Acee



On Mar 31, 2014, at 9:12 AM, Thomas Clausen <thomas@thomasclausen.org> wrote:<= br>
> Jamal,
>
> On 31 Mar 2014, at 14:48, Jamal Hadi Salim <hadi@mojatatu.com> wrote:
>
>> The only hole i see is your scale/workload numbers dont take into<= br> >> consideration the fact that there could be a lot more spread than = 200 active
>> documents per year that are in between WG adoption to publication.=
>> And that at times that process takes a little longer.
>> Jari's tools could provide some stats (and i could be therefor= e off), but
>> to make my point  i will handwave and say it is a magnitude m= ore docs,
>> some of which a mentor is responsible for and some which are makin= g
>> progress.
>> This means each of the 40 people is actively mentoring about 25 do= cuments
>> per year. And lets say 60 over 3 years. You will need a large numb= er of people
>> in the directorate to scale.
>
> Scalability is an issue in whatever we are designing in the IETF, to b= e sure. But I think that various documents are very heterogenous in nature.=
>
> Some documents would be written by people who really do not need a men= tor ("Come here, Ross Callon, so that this whippersnapper can tell you= how the IETF works - and Adrian, now, let me explain to you what a good RF= C looks like" -- that just doesn't seem plausible to happen).
>
> Other documents would probably need the occasional review, but mostly = be consensual and developed by a well engaged WG, so the "mentor"= would be mostly redundant, and just "be there" without doing muc= h.
>
> A few documents would likely benefit from more continuing mentoring - = unexperienced IETFers as authors, but eager to learn the ropes. That's = actually the "good kind of effort" to spend, that's working o= n renewing the future stock of RTG-DIR members and WG Chairs. I know that when I put pen to paper for the first time in the IETF= decades ago, I'd have appreciated having had a mentor.
>
> Further, I predict that many documents would likely be rather bursty i= n the efforts required. If I was to mentor a document, I'd probably wan= t to spend a good chunk of effort around WG adoption on reviews, discussion= s with the authors, commenting, learning what the WG wants with it - but, hopefully then it will drop to an occasio= nal review (ideally, at least, looking at the diff at each release), discus= sions on precise points and potential pitfalls, and likely with another bur= st when the authors start preparing for WGLC.
>
> I think that as long as the ADs are not mechanically dooling out docum= ents, but there's a human in the loop to whom we can say "Well, ge= e, I may mentor just one document, but right now it's a full-time job t= o work with the authors, could you ask Jamal to take thisone instead?" we'll do alright.
>
>> And then there's handoff challenges. If i am mentoring a doc t= hat is
>> not complete
>> before i let go ...
>>
>
> Worst case: think of the document taking over as "having just bee= n called for WG adoption", so provide a review, chat with the authors.= Best case, you have notes to hand over, or even sit down and have a beer w= ith whoever takes over after you.
>
> Anything more complicated than that?
>
> Thomas
>
>>
>> cheers,
>> jamal
>>
>>
>>
>> On Mon, Mar 31, 2014 at 8:12 AM, Adrian Farrel <adrian@olddog.co.uk> wrote= :
>>> Hi,
>>>
>>> One of the ideas to come out of the recent discussions is appo= inting a mentor
>>> per document from the time it is adopted by a Routing Area wor= king group until
>>> it completes WG last call.
>>>
>>> This would be voluntary in two dimensions:
>>> - the WG chairs would need to deem that one would be beneficia= l
>>> - we would have to find someone from the Directorate willing t= o
>>>  take on the document.
>>>
>>> We don't think that technology expertise is as useful in t= his as IETF clue and
>>> general routing experience.
>>>
>>> So, to take this forward we would need:
>>> - WG chairs to say "Yes, we can see that that would have<= br> >>>  potential benefit
>>> - Directorate members to say "Yes, we could take on that<= br> >>> additional work.
>>>
>>> Alia and I have put together some preliminary notes on how thi= s would all hang
>>> together.
>>>
>>> Your opinions and rotten fruit are solicited.
>>>
>>> Thanks,
>>> Adrian and Alia
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> Document Mentors in the Routing Area
>>>
>>> The Problems:
>>>
>>> a) Drafts get little review outside the working group and some= times inside
>>> the working group until after working group last call. At that= point it is
>>> often
>>> painful and costly to make meaningful improvements to the draf= ts.
>>>
>>> b) Authors may not know how or whom to ask for assistance &nbs= p;or review
>>> (e.g., IANA section, Security Section, Operational and Managem= ent
>>> considerations, details of a protocol, etc. ).
>>>
>>> The Goals:
>>>
>>> a) Excellent and consistent review at WG adoption and before W= G last
>>> call.
>>>
>>> b) Ability for prolonged discussion and problem-solving when t= he
>>> draft can still be easily enhanced.
>>>
>>> c) Reduced time to delivery of RFCs.
>>>
>>> d) Quality documents.
>>>
>>> The Solution:
>>>
>>> A per-document mentor who is a known neutral party to whom the=
>>> authors can go for advice on:
>>> - how to write a section
>>> - specific issues that arise
>>> - ways to resolve conflicts.
>>>
>>> The document mentor also watches the progress of the document<= br> >>> and gives advice and steerage.
>>>
>>> It is not assumed that every document will need or benefit fro= m
>>> having a mentor.
>>>
>>> The Expected Workload:
>>>
>>>  The routing directorate has approximately 40 people. &nb= sp;If we assume
>>>  that approximately 50 drafts pass WG adoption and a simi= lar number
>>>  pass WGLC each year, then the load is 2.5 documents per = person
>>>  per year.  If we assume that there are about 200 WG= drafts in the
>>>  Routing Area and that they all have mentors, then each R= outing
>>>  Directorate member will have 5 drafts that she or he is = mentoring.
>>>
>>> The Supporting Data Artefacts:
>>>
>>>  a) As part of the Routing Area wiki, the areas of knowle= dge for
>>>  each member of the Routing Directorate will be publicly = specified.
>>>  This is added to the wiki by the Routing Area Coordinato= rs (or AD)
>>>  when the member joins the Routing Directorate, updated b= y the
>>>  member while he or she is on the Directorate, and update= d by the
>>>  Routing Area Coordinators (or AD) if and when the member= 's term
>>>  renews.
>>>
>>>  b) Document Mentor Availability and Assignments: As part= of the
>>>  Routing Area wiki, each Directorate member will specify = the maximum
>>>  number of documents that he or she is able to mentor. &n= bsp;Also listed
>>>  will be the list of mentored documents (and a count). >>>
>>>       i) When a Directorate member is assigned = as the Document
>>>       mentor, the Routing Directorate Coordinat= or will update the
>>>       wiki page and create a wiki page for the = draft.
>>>
>>>       ii) When a Document Mentor provides a rev= iew, that should be
>>>       stored in the draft's wiki page along= with the resolutions.
>>>
>>>       iii) When the Document Mentor's final= review at WGLC is done,
>>>       the Document Mentor should move the draft= to a list of
>>>       "previously mentored documents"= associated with their name.
>>>       It is ideal to write up a summary of the = document mentoring experience.
>>>
>>>  c) Unmentored Documents: Drafts which have declined a do= cument
>>>  mentor should be listed on a wiki page.
>>>
>>>  d) For each WG's wiki, it'd be useful to have th= e list of drafts
>>>  with their associated Document Mentors (or lack thereof)= and the
>>>  link to the draft's wiki page.
>>>
>>> The Basic Process:
>>>
>>> When a new WG draft is adopted, the WG chairs and the Routing<= br> >>> Directorate Coordinators discuss and agree on possible Documen= t
>>> Mentors (up to 3).  Then the Routing Directorate Coordina= tor
>>> confirms with the Routing Directorate members about their
>>> availability and willingness to mentor this particular draft. = Once
>>> one is selected, the Routing Directorate Coordinator updates t= he
>>> wiki and notifies the WG chairs and draft authors.
>>>
>>>    a) With the agreement of the ADs, a Document Ment= or who is not a
>>>    member of the Routing Directorate may be selected= .
>>>
>>>    b) The WG chairs can, after consulting with the d= raft authors,
>>>    decline to have a Document Mentor.
>>>
>>>    c) The Document Mentor should coordinate with the= Document
>>>    Shepherd for hand-off after WGLC.
>>>
>>>
>>>
>>>
>>
>

 


--20cf305b13de0f112c04f5ec9086-- From nobody Mon Mar 31 13:15:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C671A6FAA; Mon, 31 Mar 2014 13:15:20 -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 zQagMHw4iK0H; Mon, 31 Mar 2014 13:15:16 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D56F71A6F98; Mon, 31 Mar 2014 13:15:15 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id c41so8100982yho.37 for ; Mon, 31 Mar 2014 13:15: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=qZ3nCb6d5OPuKKSevlBYltTYxwz7hEtZjJHF7+SgzJM=; b=M8ys8Ru2VBQBZv7AaOvv2hGIBWt9wS14dIvODVA2KM7qK1V7uAVcS/CE7PgjSQ6C3+ L9+Dmk58hRRunyZ85EiWD5CzDXfoFm6XrZJSgbAOgv/0jfrVusNUCWYA2Qj7cZQZGkYb is2yfxn6cbNUIxfotCfPG4NJg3kXB0woS+QPnw6eKFMyXPqR3VA19RMdepXu5fW5k0C9 cnRg2lj47oF66t5HNDtoiMkuiIstgd/Atkjvh0FQ20Cf+VhiKbaVSYtwuEZZeFGe91EA h96SCwc69kBS9Ba24bYxOKklls18hIra2oGM8qBAOwBR3TU+BMuwZ3oUKGszh4YLE2Na VxWQ== MIME-Version: 1.0 X-Received: by 10.236.22.74 with SMTP id s50mr4765929yhs.109.1396296912354; Mon, 31 Mar 2014 13:15:12 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 13:15:12 -0700 (PDT) In-Reply-To: <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> Date: Mon, 31 Mar 2014 16:15:12 -0400 Message-ID: From: Alia Atlas To: Ross Callon Content-Type: multipart/alternative; boundary=e89a8f646df376449b04f5ecb582 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/gYwhoW2JduFnHEUCEqIIKrdMIIA Cc: "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:15:20 -0000 --e89a8f646df376449b04f5ecb582 Content-Type: text/plain; charset=ISO-8859-1 Ross, On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon wrote: > It seems to me that if a document has experienced authors who are > productive IETF regulars, then they probably don't need a mentor on an > ongoing basis. They might benefit from a one-time review. > Yes, if you look at the problem and goals, they apply to most documents. Get good solid reviews early in the process (WG adoption) and late (WGLC) and then work with the authors to make sure that the technical issues are dealt with early enough to have impact. Perhaps if you look at the process less as mentor and more as "dedicated document reviewer"? > > Thus the question: Would this be limited to documents with inexperienced > authors? As WG chairs do we envision other reasons why a particular > document might benefit from a mentor? (perhaps a document that needs a > strong mathematician or a security expert or a link state routing expert to > help with one section)? I'd be interested in what others' perspectives are. When are reviews of drafts useful? What text would you change? Regards, Alia > Ross > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, March 31, 2014 8:12 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: [RTG-DIR] Document Mentors > > Hi, > > One of the ideas to come out of the recent discussions is appointing a > mentor > per document from the time it is adopted by a Routing Area working group > until > it completes WG last call. > > This would be voluntary in two dimensions: > - the WG chairs would need to deem that one would be beneficial > - we would have to find someone from the Directorate willing to > take on the document. > > We don't think that technology expertise is as useful in this as IETF clue > and > general routing experience. > > So, to take this forward we would need: > - WG chairs to say "Yes, we can see that that would have > potential benefit > - Directorate members to say "Yes, we could take on that > additional work. > > Alia and I have put together some preliminary notes on how this would all > hang > together. > > Your opinions and rotten fruit are solicited. > > Thanks, > Adrian and Alia > > ========= > > Document Mentors in the Routing Area > > The Problems: > > a) Drafts get little review outside the working group and sometimes > inside > the working group until after working group last call. At that point it > is > often > painful and costly to make meaningful improvements to the drafts. > > b) Authors may not know how or whom to ask for assistance or review > (e.g., IANA section, Security Section, Operational and Management > considerations, details of a protocol, etc. ). > > The Goals: > > a) Excellent and consistent review at WG adoption and before WG last > call. > > b) Ability for prolonged discussion and problem-solving when the > draft can still be easily enhanced. > > c) Reduced time to delivery of RFCs. > > d) Quality documents. > > The Solution: > > A per-document mentor who is a known neutral party to whom the > authors can go for advice on: > - how to write a section > - specific issues that arise > - ways to resolve conflicts. > > The document mentor also watches the progress of the document > and gives advice and steerage. > > It is not assumed that every document will need or benefit from > having a mentor. > > The Expected Workload: > > The routing directorate has approximately 40 people. If we assume > that approximately 50 drafts pass WG adoption and a similar number > pass WGLC each year, then the load is 2.5 documents per person > per year. If we assume that there are about 200 WG drafts in the > Routing Area and that they all have mentors, then each Routing > Directorate member will have 5 drafts that she or he is mentoring. > > The Supporting Data Artefacts: > > a) As part of the Routing Area wiki, the areas of knowledge for > each member of the Routing Directorate will be publicly specified. > This is added to the wiki by the Routing Area Coordinators (or AD) > when the member joins the Routing Directorate, updated by the > member while he or she is on the Directorate, and updated by the > Routing Area Coordinators (or AD) if and when the member's term > renews. > > b) Document Mentor Availability and Assignments: As part of the > Routing Area wiki, each Directorate member will specify the maximum > number of documents that he or she is able to mentor. Also listed > will be the list of mentored documents (and a count). > > i) When a Directorate member is assigned as the Document > mentor, the Routing Directorate Coordinator will update the > wiki page and create a wiki page for the draft. > > ii) When a Document Mentor provides a review, that should be > stored in the draft's wiki page along with the resolutions. > > iii) When the Document Mentor's final review at WGLC is done, > the Document Mentor should move the draft to a list of > "previously mentored documents" associated with their name. > It is ideal to write up a summary of the document mentoring > experience. > > c) Unmentored Documents: Drafts which have declined a document > mentor should be listed on a wiki page. > > d) For each WG's wiki, it'd be useful to have the list of drafts > with their associated Document Mentors (or lack thereof) and the > link to the draft's wiki page. > > The Basic Process: > > When a new WG draft is adopted, the WG chairs and the Routing > Directorate Coordinators discuss and agree on possible Document > Mentors (up to 3). Then the Routing Directorate Coordinator > confirms with the Routing Directorate members about their > availability and willingness to mentor this particular draft. Once > one is selected, the Routing Directorate Coordinator updates the > wiki and notifies the WG chairs and draft authors. > > a) With the agreement of the ADs, a Document Mentor who is not a > member of the Routing Directorate may be selected. > > b) The WG chairs can, after consulting with the draft authors, > decline to have a Document Mentor. > > c) The Document Mentor should coordinate with the Document > Shepherd for hand-off after WGLC. > > > > > > > > --e89a8f646df376449b04f5ecb582 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ross,

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <rcall= on@juniper.net> wrote:
It seems to me that if a document has experi= enced authors who are productive IETF regulars, then they probably don'= t need a mentor on an ongoing basis. They might benefit from a one-time rev= iew.

Yes, if you look at the problem and goals,= they apply to most documents. =A0Get good solid reviews early in the proce= ss (WG adoption) and late (WGLC) and then work with the authors to make sur= e that the technical issues are dealt with early enough to have impact.

Perhaps if you look at the process less as mentor and m= ore as "dedicated document reviewer"?
=A0

Thus the question: Would this be limited to documents with inexperienced au= thors? As WG chairs do we envision other reasons why a particular document = might benefit from a mentor? (perhaps a document that needs a strong mathem= atician or a security expert or a link state routing expert to help with on= e section)?

I'd be interested in what others' perspectives = are. =A0 When are reviews of drafts useful? =A0What text would you change?<= /div>

Regards,
Alia

= =A0
Ross

-----Original Message-----
From: rtg-dir [mailto:rtg-dir-b= ounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: [RTG-DIR] Document Mentors

Hi,

One of the ideas to come out of the recent discussions is appointing a ment= or
per document from the time it is adopted by a Routing Area working group un= til
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
=A0 =A0take on the document.

We don't think that technology expertise is as useful in this as IETF c= lue and
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
=A0 =A0potential benefit
- Directorate members to say "Yes, we could take on that
=A0 additional work.

Alia and I have put together some preliminary notes on how this would all h= ang
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Document Mentors in the Routing Area

The Problems:

=A0 a) Drafts get little review outside the working group and sometimes ins= ide
=A0 the working group until after working group last call. At that point it= is
often
=A0 painful and costly to make meaningful improvements to the drafts.

=A0 b) Authors may not know how or whom to ask for assistance =A0or review<= br> =A0 (e.g., IANA section, Security Section, Operational and Management
=A0 considerations, details of a protocol, etc. ).

The Goals:

=A0 a) Excellent and consistent review at WG adoption and before WG last =A0 call.

=A0 b) Ability for prolonged discussion and problem-solving when the
=A0 draft can still be easily enhanced.

=A0 c) Reduced time to delivery of RFCs.

=A0 d) Quality documents.

The Solution:

=A0 A per-document mentor who is a known neutral party to whom the
=A0 authors can go for advice on:
=A0 - how to write a section
=A0 - specific issues that arise
=A0 - ways to resolve conflicts.

=A0 The document mentor also watches the progress of the document
=A0 and gives advice and steerage.

=A0 It is not assumed that every document will need or benefit from
=A0 having a mentor.

The Expected Workload:

=A0 =A0The routing directorate has approximately 40 people. =A0If we assume=
=A0 =A0that approximately 50 drafts pass WG adoption and a similar number =A0 =A0pass WGLC each year, then the load is 2.5 documents per person
=A0 =A0per year. =A0If we assume that there are about 200 WG drafts in the<= br> =A0 =A0Routing Area and that they all have mentors, then each Routing
=A0 =A0Directorate member will have 5 drafts that she or he is mentoring.
The Supporting Data Artefacts:

=A0 =A0a) As part of the Routing Area wiki, the areas of knowledge for
=A0 =A0each member of the Routing Directorate will be publicly specified. =A0 =A0This is added to the wiki by the Routing Area Coordinators (or AD) =A0 =A0when the member joins the Routing Directorate, updated by the
=A0 =A0member while he or she is on the Directorate, and updated by the
=A0 =A0Routing Area Coordinators (or AD) if and when the member's term<= br> =A0 =A0renews.

=A0 =A0b) Document Mentor Availability and Assignments: As part of the
=A0 =A0Routing Area wiki, each Directorate member will specify the maximum<= br> =A0 =A0number of documents that he or she is able to mentor. =A0Also listed=
=A0 =A0will be the list of mentored documents (and a count).

=A0 =A0 =A0 =A0 i) When a Directorate member is assigned as the Document =A0 =A0 =A0 =A0 mentor, the Routing Directorate Coordinator will update the=
=A0 =A0 =A0 =A0 wiki page and create a wiki page for the draft.

=A0 =A0 =A0 =A0 ii) When a Document Mentor provides a review, that should b= e
=A0 =A0 =A0 =A0 stored in the draft's wiki page along with the resoluti= ons.

=A0 =A0 =A0 =A0 iii) When the Document Mentor's final review at WGLC is= done,
=A0 =A0 =A0 =A0 the Document Mentor should move the draft to a list of
=A0 =A0 =A0 =A0 "previously mentored documents" associated with t= heir name.
=A0 =A0 =A0 =A0 It is ideal to write up a summary of the document mentoring= experience.

=A0 =A0c) Unmentored Documents: Drafts which have declined a document
=A0 =A0mentor should be listed on a wiki page.

=A0 =A0d) For each WG's wiki, it'd be useful to have the list of dr= afts
=A0 =A0with their associated Document Mentors (or lack thereof) and the
=A0 =A0link to the draft's wiki page.

The Basic Process:

=A0 When a new WG draft is adopted, the WG chairs and the Routing
=A0 Directorate Coordinators discuss and agree on possible Document
=A0 Mentors (up to 3). =A0Then the Routing Directorate Coordinator
=A0 confirms with the Routing Directorate members about their
=A0 availability and willingness to mentor this particular draft. Once
=A0 one is selected, the Routing Directorate Coordinator updates the
=A0 wiki and notifies the WG chairs and draft authors.

=A0 =A0 =A0a) With the agreement of the ADs, a Document Mentor who is not a=
=A0 =A0 =A0member of the Routing Directorate may be selected.

=A0 =A0 =A0b) The WG chairs can, after consulting with the draft authors, =A0 =A0 =A0decline to have a Document Mentor.

=A0 =A0 =A0c) The Document Mentor should coordinate with the Document
=A0 =A0 =A0Shepherd for hand-off after WGLC.








--e89a8f646df376449b04f5ecb582-- From nobody Mon Mar 31 13:17:18 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301241A6FB1 for ; Mon, 31 Mar 2014 13:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ozTEMALAbBeA for ; Mon, 31 Mar 2014 13:15:51 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 20B3D1A6FAA for ; Mon, 31 Mar 2014 13:15:50 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so4013096wiv.1 for ; Mon, 31 Mar 2014 13:15:47 -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=6Z+NBJ4W84L1knBARiqavLQRQZSNA74ZLF3Q2LNsHFg=; b=IVh2swBc1wBQkfqEAHXxboGJ0rD4VvOaGqTu4auryDIIyr45drmWQUnVYsMdynT9AB T/mTzCmFLL3ZSn4TSBKmxnLVRrA/ImqGm0klzaIxHj6/ZcOBjmhtJkR0hawWjkVjtsop nwhga2aQK7KFy7LJmsSvObRe5MfUm0HuUXNFRrdktSDivDHV1DeOV8S5qNXbIH5b+Ib+ 7t99Ngmv6a5GpikokUE7Iq41py1KtW0KM/yyCeCBcQYu/TfZ29+AAhEWsncodXfanlX3 GJa6WlGDI4x9fjwq1Apdj3PBYRQkGAoHqvlfSdHBrv1c6usfXL591hp0QOceJrSrrCmS 5+zA== 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=6Z+NBJ4W84L1knBARiqavLQRQZSNA74ZLF3Q2LNsHFg=; b=M0+qlf4hMnQC16BiVPzh3lA4ZS/MZCaEmg3MA7v7nEcDAfxmnwjSTU4G+HSvbBehUf U9AOFRolKcgoGjYX5uQ/7mukIYoO21tQv4FN2TaFP+cL3sCAOynLKdeaNRVNPaSY82Ey iQrAJAjDDxTl9ZiR7a4cK8edTM7tGIgXEMg9a8pHZ+6mqVX6jxrXHKVbI6veWCX+V+tv C1SC6JdisblVpScFOvYDxR2u0RemGi+SRYMXk6Nom1zdWcf4qfnGVuJhblCc8RoFMiDj cMlzpmUhN+fqWgbpinzwIcmszLVYJZWh5DsANURp/UbiOFjLftfV76Mycn+Ucha7qLX/ M+Qw== X-Gm-Message-State: ALoCoQlOvlzsKXrch8KPNchafg5zP0UHk80Ys9aIepjla0FR93C+F6Box/y8O1F9pIRLHFjaRDzYxJhEtvnmIBaEx7cvs6H4/zkKHmo7/DN2pP90m923mP/4BFQrNJ7DwKo6pn1Xy3KDzQLozKEOkT9fQzbxU97NkpptWUmux7aXvhNqaONnuPAKwhDsOjGJZbMn6Jv4F4IW X-Received: by 10.180.98.232 with SMTP id el8mr14822664wib.27.1396296947330; Mon, 31 Mar 2014 13:15:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.124.65 with HTTP; Mon, 31 Mar 2014 13:15:07 -0700 (PDT) In-Reply-To: <029c01cf4d0e$7e5f00f0$7b1d02d0$@olddog.co.uk> References: <01c501cf4cf7$7938c370$6baa4a50$@olddog.co.uk> <029c01cf4d0e$7e5f00f0$7b1d02d0$@olddog.co.uk> From: Edward Crabbe Date: Mon, 31 Mar 2014 13:15:07 -0700 Message-ID: To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=f46d0442885e8c0a0b04f5ecb790 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/HaAMZBnPdhHlOYVSl21tJXmuv-E X-Mailman-Approved-At: Mon, 31 Mar 2014 13:17:00 -0700 Cc: rtg-dir@ietf.org, rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Scaling, Rewards and Process Rules : Document mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:15:53 -0000 --f46d0442885e8c0a0b04f5ecb790 Content-Type: text/plain; charset=ISO-8859-1 Adrian; Probably a single, specific, reasonable deadline stipulated by the chairs for the WG as a whole, with the document reviewer having 50-70% of said time allotment to submit their review (thus allowing for substantive post review commentary within the deadline.) On Mon, Mar 31, 2014 at 11:24 AM, Adrian Farrel wrote: > Hi Ed, > > > > That's a good question. How would you like that to work? I can guess! > > > > Can you propose changes to the text that do what you want? > > > > A > > > > *From:* Edward Crabbe [mailto:edc@google.com] > *Sent:* 31 March 2014 18:56 > *To:* adrian@olddog.co.uk > *Cc:* rtg-dir@ietf.org; rtg-chairs@ietf.org > *Subject:* Re: Scaling, Rewards and Process Rules : Document mentors > > > > > > Is it mandatory for the group to wait for mentor feedback? (If so, this > may slow document development and iteration unless a specific deadline is > provided and review happens in parallel to existing wg review - I'm > assuming this is the intention.) > > > > > > On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel > wrote: > > To answer two concerns in one email: > > Yes, we might have the scaling numbers wrong. > > I suspect that only about half of the documents would end up with a mentor. > Alia (I think - but she can comment) would like a higher number. > > The number of documents we need to worry about is the number of WG > documents > across the Routing Area at any one time. Alia has counted this as 187+27. > I make > that 200 :-) > > The Directorate is currently 40 people. > That means between 2.5 and 5 documents per person. > 5 seems too many, but some people might want to take on that sort of load > while > others will not. > > We do not know how much effort will be involved. > I would guess 3 detailed reviews over the course of the document, reviews > of a > few diffs, and some email exchanges. > > As the load ramps up, and according to people's willingness to participate > we > might: > - declare the project a failure > - increase the size of the Directorate > - see that everything is cool. > > I do note that several Directorate members said that they wished they got > more > work from the Directorate, so at least some of you want something else to > do. > Not sure if this is it :-) > > Which takes me to "rewards". > What reward does a Directorate member get today? > I think that anyone in the Directorate who participates in this scheme > could > easily expect to double the reward. > > And lastly, is this new process and rules? Absolutely not. > This is just a way to inject resource into documents and help the > authors/WGs to > deliver stuff that is useful and works. > Does a WG have to halt processing while a mentor is found? No. > A mentor is just something that might happen in parallel. > Does a WG have to pay attention to what a mentor says? Yes. > But only in the same way that they would pay attention to the same person > commenting on the mailing list in the normal course of events. > > A > > > --f46d0442885e8c0a0b04f5ecb790 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Adrian;

Probably a single, specific, re= asonable deadline stipulated by the chairs for the WG as a whole, with the = document reviewer having 50-70% of said time allotment =A0to submit their r= eview (thus allowing for substantive post review commentary within the dead= line.)=A0


On Mon,= Mar 31, 2014 at 11:24 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

Hi Ed,=

=A0<= /p>

That's a good ques= tion. How would you like that to work? I can guess!

=A0<= /p>

Can you propose change= s to the text that do what you want?

=A0<= /p>

A=

=A0<= /p>

From: Edward Crabbe [mailto:edc@google.com]
Sent: 31 March 2014 18:56
To: adrian@olddog.co.uk
Cc: rtg-dir@ietf.org; rtg-chairs@ietf.org<= br> Subject: Re: Scaling, Rewards and Process Rules : Document mentors

=A0

=A0

Is it mandatory for the group to wait for= mentor feedback? =A0(If so, this may slow document development and iterati= on unless a specific deadline is provided and review happens in parallel to= existing wg review - I'm assuming this is the intention.)

=A0

=A0

On Mon, Mar 31, 2014 at 8:39 AM, Adrian Farrel <= ;adrian@olddog.co.= uk> wrote:

To answer two concern= s in one email:

Yes, we might have the scaling numbers wrong.
I suspect that only about half of the documents would end up with a mentor= .
Alia (I think - but she can comment) would like a higher number.

The= number of documents we need to worry about is the number of WG documentsacross the Routing Area at any one time. Alia has counted this as 187+27.= I make
that 200 :-)

The Directorate is currently 40 people.
That means b= etween 2.5 and 5 documents per person.
5 seems too many, but some people= might want to take on that sort of load while
others will not.

We do not know how much effort will be involved.
I would guess 3 detaile= d reviews over the course of the document, reviews of a
few diffs, and s= ome email exchanges.

As the load ramps up, and according to people&#= 39;s willingness to participate we
might:
- declare the project a failure
- increase the size of the Dir= ectorate
- see that everything is cool.

I do note that several Di= rectorate members said that they wished they got more
work from the Dire= ctorate, so at least some of you want something else to do.
Not sure if this is it :-)

Which takes me to "rewards".What reward does a Directorate member get today?
I think that anyone in= the Directorate who participates in this scheme could
easily expect to = double the reward.

And lastly, is this new process and rules? Absolutely not.
This is j= ust a way to inject resource into documents and help the authors/WGs to
= deliver stuff that is useful and works.
Does a WG have to halt processin= g while a mentor is found? No.
A mentor is just something that might happen in parallel.
Does a WG have= to pay attention to what a mentor says? Yes.
But only in the same way t= hat they would pay attention to the same person
commenting on the mailin= g list in the normal course of events.

A

=A0


--f46d0442885e8c0a0b04f5ecb790-- From nobody Mon Mar 31 13:17:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA671A6FDC; Mon, 31 Mar 2014 13:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 uny-Vn7jJrtl; Mon, 31 Mar 2014 13:17:40 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 52EE51A6FB4; Mon, 31 Mar 2014 13:17:19 -0700 (PDT) Received: from mail32-ch1-R.bigfish.com (10.43.68.249) by CH1EHSOBE022.bigfish.com (10.43.70.79) with Microsoft SMTP Server id 14.1.225.22; Mon, 31 Mar 2014 20:17:15 +0000 Received: from mail32-ch1 (localhost [127.0.0.1]) by mail32-ch1-R.bigfish.com (Postfix) with ESMTP id 7A41214077B; Mon, 31 Mar 2014 20:17:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz98dI9371Ic85fh542I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hz8dhz8275ch1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh26c8h9a9j1155h) Received-SPF: pass (mail32-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(199002)(164054003)(377454003)(24454002)(189002)(13464003)(85306002)(90146001)(63696002)(94946001)(86362001)(56816005)(80022001)(19609705001)(87266001)(53806001)(59766001)(81816001)(74876001)(19300405004)(18717965001)(92566001)(97186001)(54316002)(93516002)(99286001)(94316002)(97336001)(65816001)(66066001)(16236675002)(83072002)(79102001)(83322001)(76482001)(95666003)(56776001)(95416001)(69226001)(2656002)(20776003)(54356001)(74366001)(76796001)(85852003)(81686001)(77982001)(76576001)(76786001)(98676001)(47736001)(46102001)(47446002)(19580395003)(51856001)(49866001)(4396001)(15202345003)(87936001)(81342001)(19580405001)(1411001)(74316001)(93136001)(80976001)(50986001)(33646001)(74662001)(15975445006)(31966008)(74502001)(74706001)(81542001)(47976001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB633; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:2FFCF25D.ABDA97F1.71D3BDBB.9AED6B79.205E7; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail32-ch1 (localhost.localdomain [127.0.0.1]) by mail32-ch1 (MessageSwitch) id 1396297027131369_13095; Mon, 31 Mar 2014 20:17:07 +0000 (UTC) Received: from CH1EHSMHS043.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.240]) by mail32-ch1.bigfish.com (Postfix) with ESMTP id 1137C4600F2; Mon, 31 Mar 2014 20:17:07 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS043.bigfish.com (10.43.69.252) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 31 Mar 2014 20:16:59 +0000 Received: from CO2PR05MB633.namprd05.prod.outlook.com (10.141.199.12) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.435.0; Mon, 31 Mar 2014 20:16:58 +0000 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.898.11; Mon, 31 Mar 2014 20:16:55 +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.0898.005; Mon, 31 Mar 2014 20:16:55 +0000 From: Ross Callon To: Alia Atlas Thread-Topic: [RTG-DIR] Document Mentors Thread-Index: Ac9M2m6W+5VCadLqSZ+H0wbQvgFp1QAO1hxQAAIJKAAAAAdZoA== Date: Mon, 31 Mar 2014 20:16:55 +0000 Message-ID: <860b9a4c713e472a9fe4d426e9d9b01e@CO2PR05MB636.namprd05.prod.outlook.com> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> 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-forefront-prvs: 0167DB5752 Content-Type: multipart/alternative; boundary="_000_860b9a4c713e472a9fe4d426e9d9b01eCO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ZBQuQq46uk3EVH6KUb-kyAer-pU Cc: "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:17:49 -0000 --_000_860b9a4c713e472a9fe4d426e9d9b01eCO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I thought that the directorate members were already document reviewers, but= doing one-time reviews rather than following a document throughout its jou= rney. Ross From: Alia Atlas [mailto:akatlas@gmail.com] Sent: Monday, March 31, 2014 4:15 PM To: Ross Callon Cc: adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Document Mentors Ross, On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon > wrote: It seems to me that if a document has experienced authors who are productiv= e IETF regulars, then they probably don't need a mentor on an ongoing basis= . They might benefit from a one-time review. Yes, if you look at the problem and goals, they apply to most documents. G= et good solid reviews early in the process (WG adoption) and late (WGLC) an= d then work with the authors to make sure that the technical issues are dea= lt with early enough to have impact. Perhaps if you look at the process less as mentor and more as "dedicated do= cument reviewer"? Thus the question: Would this be limited to documents with inexperienced au= thors? As WG chairs do we envision other reasons why a particular document = might benefit from a mentor? (perhaps a document that needs a strong mathem= atician or a security expert or a link state routing expert to help with on= e section)? I'd be interested in what others' perspectives are. When are reviews of d= rafts useful? What text would you change? Regards, Alia Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Monday, March 31, 2014 8:12 AM To: rtg-dir@ietf.org; rtg-chairs@ietf.org Subject: [RTG-DIR] Document Mentors Hi, One of the ideas to come out of the recent discussions is appointing a ment= or per document from the time it is adopted by a Routing Area working group un= til it completes WG last call. This would be voluntary in two dimensions: - the WG chairs would need to deem that one would be beneficial - we would have to find someone from the Directorate willing to take on the document. We don't think that technology expertise is as useful in this as IETF clue = and general routing experience. So, to take this forward we would need: - WG chairs to say "Yes, we can see that that would have potential benefit - Directorate members to say "Yes, we could take on that additional work. Alia and I have put together some preliminary notes on how this would all h= ang together. Your opinions and rotten fruit are solicited. Thanks, Adrian and Alia =3D=3D=3D=3D=3D=3D=3D=3D=3D Document Mentors in the Routing Area The Problems: a) Drafts get little review outside the working group and sometimes insid= e the working group until after working group last call. At that point it i= s often painful and costly to make meaningful improvements to the drafts. b) Authors may not know how or whom to ask for assistance or review (e.g., IANA section, Security Section, Operational and Management considerations, details of a protocol, etc. ). The Goals: a) Excellent and consistent review at WG adoption and before WG last call. b) Ability for prolonged discussion and problem-solving when the draft can still be easily enhanced. c) Reduced time to delivery of RFCs. d) Quality documents. The Solution: A per-document mentor who is a known neutral party to whom the authors can go for advice on: - how to write a section - specific issues that arise - ways to resolve conflicts. The document mentor also watches the progress of the document and gives advice and steerage. It is not assumed that every document will need or benefit from having a mentor. The Expected Workload: The routing directorate has approximately 40 people. If we assume that approximately 50 drafts pass WG adoption and a similar number pass WGLC each year, then the load is 2.5 documents per person per year. If we assume that there are about 200 WG drafts in the Routing Area and that they all have mentors, then each Routing Directorate member will have 5 drafts that she or he is mentoring. The Supporting Data Artefacts: a) As part of the Routing Area wiki, the areas of knowledge for each member of the Routing Directorate will be publicly specified. This is added to the wiki by the Routing Area Coordinators (or AD) when the member joins the Routing Directorate, updated by the member while he or she is on the Directorate, and updated by the Routing Area Coordinators (or AD) if and when the member's term renews. b) Document Mentor Availability and Assignments: As part of the Routing Area wiki, each Directorate member will specify the maximum number of documents that he or she is able to mentor. Also listed will be the list of mentored documents (and a count). i) When a Directorate member is assigned as the Document mentor, the Routing Directorate Coordinator will update the wiki page and create a wiki page for the draft. ii) When a Document Mentor provides a review, that should be stored in the draft's wiki page along with the resolutions. iii) When the Document Mentor's final review at WGLC is done, the Document Mentor should move the draft to a list of "previously mentored documents" associated with their name. It is ideal to write up a summary of the document mentoring experie= nce. c) Unmentored Documents: Drafts which have declined a document mentor should be listed on a wiki page. d) For each WG's wiki, it'd be useful to have the list of drafts with their associated Document Mentors (or lack thereof) and the link to the draft's wiki page. The Basic Process: When a new WG draft is adopted, the WG chairs and the Routing Directorate Coordinators discuss and agree on possible Document Mentors (up to 3). Then the Routing Directorate Coordinator confirms with the Routing Directorate members about their availability and willingness to mentor this particular draft. Once one is selected, the Routing Directorate Coordinator updates the wiki and notifies the WG chairs and draft authors. a) With the agreement of the ADs, a Document Mentor who is not a member of the Routing Directorate may be selected. b) The WG chairs can, after consulting with the draft authors, decline to have a Document Mentor. c) The Document Mentor should coordinate with the Document Shepherd for hand-off after WGLC. --_000_860b9a4c713e472a9fe4d426e9d9b01eCO2PR05MB636namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I thought that the direct= orate members were already document reviewers, but doing one-time reviews r= ather than following a document throughout its journey.

 <= /p>

Ross

 <= /p>

From: Alia Atl= as [mailto:akatlas@gmail.com]
Sent: Monday, March 31, 2014 4:15 PM
To: Ross Callon
Cc: adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] Document Mentors

 

Ross,

 

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <rcallon@juniper.net> wrote:

It seems to me that if a document has experienced au= thors who are productive IETF regulars, then they probably don't need a men= tor on an ongoing basis. They might benefit from a one-time review.

 

Yes, if you look at the problem and goals, they appl= y to most documents.  Get good solid reviews early in the process (WG = adoption) and late (WGLC) and then work with the authors to make sure that = the technical issues are dealt with early enough to have impact.

 

Perhaps if you look at the process less as mentor an= d more as "dedicated document reviewer"?

 


Thus the question: Would this be limited to documents with inexperienced au= thors? As WG chairs do we envision other reasons why a particular document = might benefit from a mentor? (perhaps a document that needs a strong mathem= atician or a security expert or a link state routing expert to help with one section)?

 

I'd be interested in what others' perspectives are. =   When are reviews of drafts useful?  What text would you change?=

 

Regards,

Alia

 

 

Ross


-----Original Message-----
From: rtg-dir [mailto:rtg-dir-b= ounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: [RTG-DIR] Document Mentors

Hi,

One of the ideas to come out of the recent discussions is appointing a ment= or
per document from the time it is adopted by a Routing Area working group un= til
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
   take on the document.

We don't think that technology expertise is as useful in this as IETF clue = and
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
   potential benefit
- Directorate members to say "Yes, we could take on that
  additional work.

Alia and I have put together some preliminary notes on how this would all h= ang
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Document Mentors in the Routing Area

The Problems:

  a) Drafts get little review outside the working group and sometimes = inside
  the working group until after working group last call. At that point= it is
often
  painful and costly to make meaningful improvements to the drafts.
  b) Authors may not know how or whom to ask for assistance  or r= eview
  (e.g., IANA section, Security Section, Operational and Management   considerations, details of a protocol, etc. ).

The Goals:

  a) Excellent and consistent review at WG adoption and before WG last=
  call.

  b) Ability for prolonged discussion and problem-solving when the
  draft can still be easily enhanced.

  c) Reduced time to delivery of RFCs.

  d) Quality documents.

The Solution:

  A per-document mentor who is a known neutral party to whom the
  authors can go for advice on:
  - how to write a section
  - specific issues that arise
  - ways to resolve conflicts.

  The document mentor also watches the progress of the document
  and gives advice and steerage.

  It is not assumed that every document will need or benefit from
  having a mentor.

The Expected Workload:

   The routing directorate has approximately 40 people.  If = we assume
   that approximately 50 drafts pass WG adoption and a similar nu= mber
   pass WGLC each year, then the load is 2.5 documents per person=
   per year.  If we assume that there are about 200 WG draft= s in the
   Routing Area and that they all have mentors, then each Routing=
   Directorate member will have 5 drafts that she or he is mentor= ing.

The Supporting Data Artefacts:

   a) As part of the Routing Area wiki, the areas of knowledge fo= r
   each member of the Routing Directorate will be publicly specif= ied.
   This is added to the wiki by the Routing Area Coordinators (or= AD)
   when the member joins the Routing Directorate, updated by the<= br>    member while he or she is on the Directorate, and updated by t= he
   Routing Area Coordinators (or AD) if and when the member's ter= m
   renews.

   b) Document Mentor Availability and Assignments: As part of th= e
   Routing Area wiki, each Directorate member will specify the ma= ximum
   number of documents that he or she is able to mentor.  Al= so listed
   will be the list of mentored documents (and a count).

        i) When a Directorate member is assigned as the= Document
        mentor, the Routing Directorate Coordinator wil= l update the
        wiki page and create a wiki page for the draft.=

        ii) When a Document Mentor provides a review, t= hat should be
        stored in the draft's wiki page along with the = resolutions.

        iii) When the Document Mentor's final review at= WGLC is done,
        the Document Mentor should move the draft to a = list of
        "previously mentored documents" assoc= iated with their name.
        It is ideal to write up a summary of the docume= nt mentoring experience.

   c) Unmentored Documents: Drafts which have declined a document=
   mentor should be listed on a wiki page.

   d) For each WG's wiki, it'd be useful to have the list of draf= ts
   with their associated Document Mentors (or lack thereof) and t= he
   link to the draft's wiki page.

The Basic Process:

  When a new WG draft is adopted, the WG chairs and the Routing
  Directorate Coordinators discuss and agree on possible Document
  Mentors (up to 3).  Then the Routing Directorate Coordinator   confirms with the Routing Directorate members about their
  availability and willingness to mentor this particular draft. Once   one is selected, the Routing Directorate Coordinator updates the
  wiki and notifies the WG chairs and draft authors.

     a) With the agreement of the ADs, a Document Mentor who= is not a
     member of the Routing Directorate may be selected.

     b) The WG chairs can, after consulting with the draft a= uthors,
     decline to have a Document Mentor.

     c) The Document Mentor should coordinate with the Docum= ent
     Shepherd for hand-off after WGLC.






 

--_000_860b9a4c713e472a9fe4d426e9d9b01eCO2PR05MB636namprd05pro_-- From nobody Mon Mar 31 13:27:34 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58B71A6F81; Mon, 31 Mar 2014 13:27: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 6US3hvAStaMO; Mon, 31 Mar 2014 13:27:24 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id ABCFA1A08C6; Mon, 31 Mar 2014 13:27:23 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id 79so6618978ykr.37 for ; Mon, 31 Mar 2014 13:27:20 -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=oo9QucD9fl+dU6iiL5n35Z8+sVKQDmaWl57wx5RiYxY=; b=Uuy2WS3aoJShBhkgzC5f1StE1QhQJRvBBPLXnaYc40ipQh/uFFWYR4wGkZ6jv0v83k dIaDK79sjS3OK/H1fhRrgRSzfPiVnllamfaKA0/GkDK39Ie4gPbvjTZzH4/ASPFMhoPF XsWPwx7wPKU6rX9H7gqmGlWTIMXZVa/zwOWg/bnzSnpxR9EY2l4FAZFxTR7C2sRhX8aV NxsqAtDG4xl6hzE/ekOUf8j3p1bfJhlV2yJVhYzqQGDZu2UUsFVC/l3BGcMaJmn8qkAW yoW9vm7cz0AGOgs+6N/HnvF2rLzah+kKbkEV65f/QhX6hcxy9lb1aI4nwg8sxkU6UvGG OblA== MIME-Version: 1.0 X-Received: by 10.236.199.78 with SMTP id w54mr4780889yhn.139.1396297640268; Mon, 31 Mar 2014 13:27:20 -0700 (PDT) Received: by 10.170.194.69 with HTTP; Mon, 31 Mar 2014 13:27:20 -0700 (PDT) In-Reply-To: <860b9a4c713e472a9fe4d426e9d9b01e@CO2PR05MB636.namprd05.prod.outlook.com> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> <860b9a4c713e472a9fe4d426e9d9b01e@CO2PR05MB636.namprd05.prod.outlook.com> Date: Mon, 31 Mar 2014 16:27:20 -0400 Message-ID: From: Alia Atlas To: Ross Callon Content-Type: multipart/alternative; boundary=089e0158c41cd958f704f5ece0f4 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/sJdVH6vmlGu3KpYGo23fOPi_lqs Cc: "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:27:27 -0000 --089e0158c41cd958f704f5ece0f4 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 31, 2014 at 4:16 PM, Ross Callon wrote: > I thought that the directorate members were already document reviewers, > but doing one-time reviews rather than following a document throughout its > journey. > Yes - and the one-time reviews happen at IETF LC or so - based on AD need/request. This is pushing it earlier, with the expectation that the reviewer will also push the technical concerns, and then a review later at WGLC. Alia > > > Ross > > > > *From:* Alia Atlas [mailto:akatlas@gmail.com] > *Sent:* Monday, March 31, 2014 4:15 PM > *To:* Ross Callon > > *Cc:* adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org > *Subject:* Re: [RTG-DIR] Document Mentors > > > > Ross, > > > > On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon wrote: > > It seems to me that if a document has experienced authors who are > productive IETF regulars, then they probably don't need a mentor on an > ongoing basis. They might benefit from a one-time review. > > > > Yes, if you look at the problem and goals, they apply to most documents. > Get good solid reviews early in the process (WG adoption) and late (WGLC) > and then work with the authors to make sure that the technical issues are > dealt with early enough to have impact. > > > > Perhaps if you look at the process less as mentor and more as "dedicated > document reviewer"? > > > > > Thus the question: Would this be limited to documents with inexperienced > authors? As WG chairs do we envision other reasons why a particular > document might benefit from a mentor? (perhaps a document that needs a > strong mathematician or a security expert or a link state routing expert to > help with one section)? > > > > I'd be interested in what others' perspectives are. When are reviews of > drafts useful? What text would you change? > > > > Regards, > > Alia > > > > > > Ross > > > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, March 31, 2014 8:12 AM > To: rtg-dir@ietf.org; rtg-chairs@ietf.org > Subject: [RTG-DIR] Document Mentors > > Hi, > > One of the ideas to come out of the recent discussions is appointing a > mentor > per document from the time it is adopted by a Routing Area working group > until > it completes WG last call. > > This would be voluntary in two dimensions: > - the WG chairs would need to deem that one would be beneficial > - we would have to find someone from the Directorate willing to > take on the document. > > We don't think that technology expertise is as useful in this as IETF clue > and > general routing experience. > > So, to take this forward we would need: > - WG chairs to say "Yes, we can see that that would have > potential benefit > - Directorate members to say "Yes, we could take on that > additional work. > > Alia and I have put together some preliminary notes on how this would all > hang > together. > > Your opinions and rotten fruit are solicited. > > Thanks, > Adrian and Alia > > ========= > > Document Mentors in the Routing Area > > The Problems: > > a) Drafts get little review outside the working group and sometimes > inside > the working group until after working group last call. At that point it > is > often > painful and costly to make meaningful improvements to the drafts. > > b) Authors may not know how or whom to ask for assistance or review > (e.g., IANA section, Security Section, Operational and Management > considerations, details of a protocol, etc. ). > > The Goals: > > a) Excellent and consistent review at WG adoption and before WG last > call. > > b) Ability for prolonged discussion and problem-solving when the > draft can still be easily enhanced. > > c) Reduced time to delivery of RFCs. > > d) Quality documents. > > The Solution: > > A per-document mentor who is a known neutral party to whom the > authors can go for advice on: > - how to write a section > - specific issues that arise > - ways to resolve conflicts. > > The document mentor also watches the progress of the document > and gives advice and steerage. > > It is not assumed that every document will need or benefit from > having a mentor. > > The Expected Workload: > > The routing directorate has approximately 40 people. If we assume > that approximately 50 drafts pass WG adoption and a similar number > pass WGLC each year, then the load is 2.5 documents per person > per year. If we assume that there are about 200 WG drafts in the > Routing Area and that they all have mentors, then each Routing > Directorate member will have 5 drafts that she or he is mentoring. > > The Supporting Data Artefacts: > > a) As part of the Routing Area wiki, the areas of knowledge for > each member of the Routing Directorate will be publicly specified. > This is added to the wiki by the Routing Area Coordinators (or AD) > when the member joins the Routing Directorate, updated by the > member while he or she is on the Directorate, and updated by the > Routing Area Coordinators (or AD) if and when the member's term > renews. > > b) Document Mentor Availability and Assignments: As part of the > Routing Area wiki, each Directorate member will specify the maximum > number of documents that he or she is able to mentor. Also listed > will be the list of mentored documents (and a count). > > i) When a Directorate member is assigned as the Document > mentor, the Routing Directorate Coordinator will update the > wiki page and create a wiki page for the draft. > > ii) When a Document Mentor provides a review, that should be > stored in the draft's wiki page along with the resolutions. > > iii) When the Document Mentor's final review at WGLC is done, > the Document Mentor should move the draft to a list of > "previously mentored documents" associated with their name. > It is ideal to write up a summary of the document mentoring > experience. > > c) Unmentored Documents: Drafts which have declined a document > mentor should be listed on a wiki page. > > d) For each WG's wiki, it'd be useful to have the list of drafts > with their associated Document Mentors (or lack thereof) and the > link to the draft's wiki page. > > The Basic Process: > > When a new WG draft is adopted, the WG chairs and the Routing > Directorate Coordinators discuss and agree on possible Document > Mentors (up to 3). Then the Routing Directorate Coordinator > confirms with the Routing Directorate members about their > availability and willingness to mentor this particular draft. Once > one is selected, the Routing Directorate Coordinator updates the > wiki and notifies the WG chairs and draft authors. > > a) With the agreement of the ADs, a Document Mentor who is not a > member of the Routing Directorate may be selected. > > b) The WG chairs can, after consulting with the draft authors, > decline to have a Document Mentor. > > c) The Document Mentor should coordinate with the Document > Shepherd for hand-off after WGLC. > > > > > > > > --089e0158c41cd958f704f5ece0f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 31, 2014 at 4:16 PM, Ross Callon <rcallon@juniper.net> wrote:

I thought that the direct= orate members were already document reviewers, but doing one-time reviews r= ather than following a document throughout its journey.


Yes - and the one-time reviews= happen at IETF LC or so - based on AD need/request.
This is push= ing it earlier, with the expectation that the reviewer will also push the t= echnical concerns,
and then a review later at WGLC.

Alia
=A0

=A0<= /p>

Ross=

=A0<= /p>

From: Alia Atl= as [mailto:akatlas@g= mail.com]
Sent: Monday, March 31, 2014 4:15 PM
To: Ross Callon


Cc: adrian@= olddog.co.uk; rtg= -dir@ietf.org; rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] Document Mentors

=A0

Ross,

=A0

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <rcallon@juniper.net> wrote:

It seems to me that if a document has experienced au= thors who are productive IETF regulars, then they probably don't need a= mentor on an ongoing basis. They might benefit from a one-time review.<= /u>

=A0

Yes, if you look at the problem and goals, they appl= y to most documents. =A0Get good solid reviews early in the process (WG ado= ption) and late (WGLC) and then work with the authors to make sure that the= technical issues are dealt with early enough to have impact.

=A0

Perhaps if you look at the process less as mentor an= d more as "dedicated document reviewer"?

=A0


Thus the question: Would this be limited to documents with inexperienced au= thors? As WG chairs do we envision other reasons why a particular document = might benefit from a mentor? (perhaps a document that needs a strong mathem= atician or a security expert or a link state routing expert to help with one section)?

=A0

I'd be interested in what others' perspectiv= es are. =A0 When are reviews of drafts useful? =A0What text would you chang= e?

=A0

Regards,

Alia

=A0

=A0

Ross


-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: rtg-dir@ietf.org<= /a>; rtg-chairs@ietf.org
Subject: [RTG-DIR] Document Mentors

Hi,

One of the ideas to come out of the recent discussions is appointing a ment= or
per document from the time it is adopted by a Routing Area working group un= til
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
=A0 =A0take on the document.

We don't think that technology expertise is as useful in this as IETF c= lue and
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
=A0 =A0potential benefit
- Directorate members to say "Yes, we could take on that
=A0 additional work.

Alia and I have put together some preliminary notes on how this would all h= ang
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Document Mentors in the Routing Area

The Problems:

=A0 a) Drafts get little review outside the working group and sometimes ins= ide
=A0 the working group until after working group last call. At that point it= is
often
=A0 painful and costly to make meaningful improvements to the drafts.

=A0 b) Authors may not know how or whom to ask for assistance =A0or review<= br> =A0 (e.g., IANA section, Security Section, Operational and Management
=A0 considerations, details of a protocol, etc. ).

The Goals:

=A0 a) Excellent and consistent review at WG adoption and before WG last =A0 call.

=A0 b) Ability for prolonged discussion and problem-solving when the
=A0 draft can still be easily enhanced.

=A0 c) Reduced time to delivery of RFCs.

=A0 d) Quality documents.

The Solution:

=A0 A per-document mentor who is a known neutral party to whom the
=A0 authors can go for advice on:
=A0 - how to write a section
=A0 - specific issues that arise
=A0 - ways to resolve conflicts.

=A0 The document mentor also watches the progress of the document
=A0 and gives advice and steerage.

=A0 It is not assumed that every document will need or benefit from
=A0 having a mentor.

The Expected Workload:

=A0 =A0The routing directorate has approximately 40 people. =A0If we assume=
=A0 =A0that approximately 50 drafts pass WG adoption and a similar number =A0 =A0pass WGLC each year, then the load is 2.5 documents per person
=A0 =A0per year. =A0If we assume that there are about 200 WG drafts in the<= br> =A0 =A0Routing Area and that they all have mentors, then each Routing
=A0 =A0Directorate member will have 5 drafts that she or he is mentoring.
The Supporting Data Artefacts:

=A0 =A0a) As part of the Routing Area wiki, the areas of knowledge for
=A0 =A0each member of the Routing Directorate will be publicly specified. =A0 =A0This is added to the wiki by the Routing Area Coordinators (or AD) =A0 =A0when the member joins the Routing Directorate, updated by the
=A0 =A0member while he or she is on the Directorate, and updated by the
=A0 =A0Routing Area Coordinators (or AD) if and when the member's term<= br> =A0 =A0renews.

=A0 =A0b) Document Mentor Availability and Assignments: As part of the
=A0 =A0Routing Area wiki, each Directorate member will specify the maximum<= br> =A0 =A0number of documents that he or she is able to mentor. =A0Also listed=
=A0 =A0will be the list of mentored documents (and a count).

=A0 =A0 =A0 =A0 i) When a Directorate member is assigned as the Document =A0 =A0 =A0 =A0 mentor, the Routing Directorate Coordinator will update the=
=A0 =A0 =A0 =A0 wiki page and create a wiki page for the draft.

=A0 =A0 =A0 =A0 ii) When a Document Mentor provides a review, that should b= e
=A0 =A0 =A0 =A0 stored in the draft's wiki page along with the resoluti= ons.

=A0 =A0 =A0 =A0 iii) When the Document Mentor's final review at WGLC is= done,
=A0 =A0 =A0 =A0 the Document Mentor should move the draft to a list of
=A0 =A0 =A0 =A0 "previously mentored documents" associated with t= heir name.
=A0 =A0 =A0 =A0 It is ideal to write up a summary of the document mentoring= experience.

=A0 =A0c) Unmentored Documents: Drafts which have declined a document
=A0 =A0mentor should be listed on a wiki page.

=A0 =A0d) For each WG's wiki, it'd be useful to have the list of dr= afts
=A0 =A0with their associated Document Mentors (or lack thereof) and the
=A0 =A0link to the draft's wiki page.

The Basic Process:

=A0 When a new WG draft is adopted, the WG chairs and the Routing
=A0 Directorate Coordinators discuss and agree on possible Document
=A0 Mentors (up to 3). =A0Then the Routing Directorate Coordinator
=A0 confirms with the Routing Directorate members about their
=A0 availability and willingness to mentor this particular draft. Once
=A0 one is selected, the Routing Directorate Coordinator updates the
=A0 wiki and notifies the WG chairs and draft authors.

=A0 =A0 =A0a) With the agreement of the ADs, a Document Mentor who is not a=
=A0 =A0 =A0member of the Routing Directorate may be selected.

=A0 =A0 =A0b) The WG chairs can, after consulting with the draft authors, =A0 =A0 =A0decline to have a Document Mentor.

=A0 =A0 =A0c) The Document Mentor should coordinate with the Document
=A0 =A0 =A0Shepherd for hand-off after WGLC.






=A0


--089e0158c41cd958f704f5ece0f4-- From nobody Mon Mar 31 14:31:12 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6581A702C; Mon, 31 Mar 2014 14:29:44 -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 zf4THaJgtc1K; Mon, 31 Mar 2014 14:29:39 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69A1A7025; Mon, 31 Mar 2014 14:29:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A65006A01DC; Mon, 31 Mar 2014 14:29:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B19D56A01D7; Mon, 31 Mar 2014 14:29:35 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-62A0C197-894A-48D6-A5FB-1E11BB669C1D Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D167) In-Reply-To: Date: Mon, 31 Mar 2014 23:29:34 +0200 Content-Transfer-Encoding: 7bit Message-Id: <45C09AD2-39D3-4DC5-B530-5B9A82C907A5@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> To: Alia Atlas Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/dA_qSSlnxmk_aPdohDiQeinSl-s X-Mailman-Approved-At: Mon, 31 Mar 2014 14:31:11 -0700 Cc: Ross Callon , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:29:44 -0000 --Apple-Mail-62A0C197-894A-48D6-A5FB-1E11BB669C1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 31 mars 2014, at 22:15, Alia Atlas wrote: >=20 > Ross, >=20 >> On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon wrote:= >> It seems to me that if a document has experienced authors who are product= ive IETF regulars, then they probably don't need a mentor on an ongoing basi= s. They might benefit from a one-time review. >=20 > Yes, if you look at the problem and goals, they apply to most documents. G= et good solid reviews early in the process (WG adoption) and late (WGLC) and= then work with the authors to make sure that the technical issues are dealt= with early enough to have impact. >=20 > Perhaps if you look at the process less as mentor and more as "dedicated d= ocument reviewer"? That may kinda be a good term as such - nobody gets too old and too experien= ced to benefit from a review and a sanity-check from another IETFer, whereas= experienced authors may not need any "mentoring". I'd feel, for example, perfectly happy giving Ross a review of a document, a= nd even do it twice or thrice - but yeah, it'd fe "odd" being designated a "= mentor" for his document...egg teaching the rooster, and all that. >> Thus the question: Would this be limited to documents with inexperienced a= uthors? As WG chairs do we envision other reasons why a particular document m= ight benefit from a mentor? (perhaps a document that needs a strong mathemat= ician or a security expert or a link state routing expert to help with one s= ection)? >=20 > I'd be interested in what others' perspectives are. When are reviews of d= rafts useful? What text would you change? >=20 Personally? Well, the more reviews the happier I am .... Realistically: whenever a document reaches a "stable state", or whenever I'm= stuck. In a perfect world: already when I have the outline and the idea ready, and f= rom people with different specialities...security-guidance even before putti= ng pen to paper would, for example. Thomas > Regards, > Alia >=20 > =20 >> Ross >>=20 >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farre= l >> Sent: Monday, March 31, 2014 8:12 AM >> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: [RTG-DIR] Document Mentors >>=20 >> Hi, >>=20 >> One of the ideas to come out of the recent discussions is appointing a me= ntor >> per document from the time it is adopted by a Routing Area working group u= ntil >> it completes WG last call. >>=20 >> This would be voluntary in two dimensions: >> - the WG chairs would need to deem that one would be beneficial >> - we would have to find someone from the Directorate willing to >> take on the document. >>=20 >> We don't think that technology expertise is as useful in this as IETF clu= e and >> general routing experience. >>=20 >> So, to take this forward we would need: >> - WG chairs to say "Yes, we can see that that would have >> potential benefit >> - Directorate members to say "Yes, we could take on that >> additional work. >>=20 >> Alia and I have put together some preliminary notes on how this would all= hang >> together. >>=20 >> Your opinions and rotten fruit are solicited. >>=20 >> Thanks, >> Adrian and Alia >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Document Mentors in the Routing Area >>=20 >> The Problems: >>=20 >> a) Drafts get little review outside the working group and sometimes ins= ide >> the working group until after working group last call. At that point it= is >> often >> painful and costly to make meaningful improvements to the drafts. >>=20 >> b) Authors may not know how or whom to ask for assistance or review >> (e.g., IANA section, Security Section, Operational and Management >> considerations, details of a protocol, etc. ). >>=20 >> The Goals: >>=20 >> a) Excellent and consistent review at WG adoption and before WG last >> call. >>=20 >> b) Ability for prolonged discussion and problem-solving when the >> draft can still be easily enhanced. >>=20 >> c) Reduced time to delivery of RFCs. >>=20 >> d) Quality documents. >>=20 >> The Solution: >>=20 >> A per-document mentor who is a known neutral party to whom the >> authors can go for advice on: >> - how to write a section >> - specific issues that arise >> - ways to resolve conflicts. >>=20 >> The document mentor also watches the progress of the document >> and gives advice and steerage. >>=20 >> It is not assumed that every document will need or benefit from >> having a mentor. >>=20 >> The Expected Workload: >>=20 >> The routing directorate has approximately 40 people. If we assume >> that approximately 50 drafts pass WG adoption and a similar number >> pass WGLC each year, then the load is 2.5 documents per person >> per year. If we assume that there are about 200 WG drafts in the >> Routing Area and that they all have mentors, then each Routing >> Directorate member will have 5 drafts that she or he is mentoring. >>=20 >> The Supporting Data Artefacts: >>=20 >> a) As part of the Routing Area wiki, the areas of knowledge for >> each member of the Routing Directorate will be publicly specified. >> This is added to the wiki by the Routing Area Coordinators (or AD) >> when the member joins the Routing Directorate, updated by the >> member while he or she is on the Directorate, and updated by the >> Routing Area Coordinators (or AD) if and when the member's term >> renews. >>=20 >> b) Document Mentor Availability and Assignments: As part of the >> Routing Area wiki, each Directorate member will specify the maximum >> number of documents that he or she is able to mentor. Also listed >> will be the list of mentored documents (and a count). >>=20 >> i) When a Directorate member is assigned as the Document >> mentor, the Routing Directorate Coordinator will update the >> wiki page and create a wiki page for the draft. >>=20 >> ii) When a Document Mentor provides a review, that should be >> stored in the draft's wiki page along with the resolutions. >>=20 >> iii) When the Document Mentor's final review at WGLC is done, >> the Document Mentor should move the draft to a list of >> "previously mentored documents" associated with their name. >> It is ideal to write up a summary of the document mentoring exper= ience. >>=20 >> c) Unmentored Documents: Drafts which have declined a document >> mentor should be listed on a wiki page. >>=20 >> d) For each WG's wiki, it'd be useful to have the list of drafts >> with their associated Document Mentors (or lack thereof) and the >> link to the draft's wiki page. >>=20 >> The Basic Process: >>=20 >> When a new WG draft is adopted, the WG chairs and the Routing >> Directorate Coordinators discuss and agree on possible Document >> Mentors (up to 3). Then the Routing Directorate Coordinator >> confirms with the Routing Directorate members about their >> availability and willingness to mentor this particular draft. Once >> one is selected, the Routing Directorate Coordinator updates the >> wiki and notifies the WG chairs and draft authors. >>=20 >> a) With the agreement of the ADs, a Document Mentor who is not a >> member of the Routing Directorate may be selected. >>=20 >> b) The WG chairs can, after consulting with the draft authors, >> decline to have a Document Mentor. >>=20 >> c) The Document Mentor should coordinate with the Document >> Shepherd for hand-off after WGLC. >=20 --Apple-Mail-62A0C197-894A-48D6-A5FB-1E11BB669C1D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 31 mars 2014, at 22:15, Alia Atlas <akatlas@gmail.com> wrote:

Ross,

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <rcallon@juniper.net> wrote:
It seems to me that if a document has experienced authors who are productive IETF regulars, then they probably don't need a mentor on an ongoing basis. They might benefit from a one-time review.

Yes, if you look at the problem and goals, they apply to most documents.  Get good solid reviews early in the process (WG adoption) and late (WGLC) and then work with the authors to make sure that the technical issues are dealt with early enough to have impact.

Perhaps if you look at the process less as mentor and more as "dedicated document reviewer"?

That may kinda be a good term as such - nobody gets too old and too experienced to benefit from a review and a sanity-check from another IETFer, whereas experienced authors may not need any "mentoring".

I'd feel, for example, perfectly happy giving Ross a review of a document, and even do it twice or thrice - but yeah, it'd fe "odd" being designated a  "mentor" for his document...egg teaching the rooster, and all that.

Thus the question: Would this be limited to documents with inexperienced authors? As WG chairs do we envision other reasons why a particular document might benefit from a mentor? (perhaps a document that needs a strong mathematician or a security expert or a link state routing expert to help with one section)?

I'd be interested in what others' perspectives are.   When are reviews of drafts useful?  What text would you change?


Personally? Well, the more reviews the happier I am ....

Realistically: whenever a document reaches a "stable state", or whenever I'm stuck.

In a perfect world: already when I have the outline and the idea ready, and from people with different specialities...security-guidance even before putting pen to paper would, for example.

Thomas


Regards,
Alia

 
Ross

-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: [RTG-DIR] Document Mentors

Hi,

One of the ideas to come out of the recent discussions is appointing a mentor
per document from the time it is adopted by a Routing Area working group until
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
   take on the document.

We don't think that technology expertise is as useful in this as IETF clue and
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
   potential benefit
- Directorate members to say "Yes, we could take on that
  additional work.

Alia and I have put together some preliminary notes on how this would all hang
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=========

Document Mentors in the Routing Area

The Problems:

  a) Drafts get little review outside the working group and sometimes inside
  the working group until after working group last call. At that point it is
often
  painful and costly to make meaningful improvements to the drafts.

  b) Authors may not know how or whom to ask for assistance  or review
  (e.g., IANA section, Security Section, Operational and Management
  considerations, details of a protocol, etc. ).

The Goals:

  a) Excellent and consistent review at WG adoption and before WG last
  call.

  b) Ability for prolonged discussion and problem-solving when the
  draft can still be easily enhanced.

  c) Reduced time to delivery of RFCs.

  d) Quality documents.

The Solution:

  A per-document mentor who is a known neutral party to whom the
  authors can go for advice on:
  - how to write a section
  - specific issues that arise
  - ways to resolve conflicts.

  The document mentor also watches the progress of the document
  and gives advice and steerage.

  It is not assumed that every document will need or benefit from
  having a mentor.

The Expected Workload:

   The routing directorate has approximately 40 people.  If we assume
   that approximately 50 drafts pass WG adoption and a similar number
   pass WGLC each year, then the load is 2.5 documents per person
   per year.  If we assume that there are about 200 WG drafts in the
   Routing Area and that they all have mentors, then each Routing
   Directorate member will have 5 drafts that she or he is mentoring.

The Supporting Data Artefacts:

   a) As part of the Routing Area wiki, the areas of knowledge for
   each member of the Routing Directorate will be publicly specified.
   This is added to the wiki by the Routing Area Coordinators (or AD)
   when the member joins the Routing Directorate, updated by the
   member while he or she is on the Directorate, and updated by the
   Routing Area Coordinators (or AD) if and when the member's term
   renews.

   b) Document Mentor Availability and Assignments: As part of the
   Routing Area wiki, each Directorate member will specify the maximum
   number of documents that he or she is able to mentor.  Also listed
   will be the list of mentored documents (and a count).

        i) When a Directorate member is assigned as the Document
        mentor, the Routing Directorate Coordinator will update the
        wiki page and create a wiki page for the draft.

        ii) When a Document Mentor provides a review, that should be
        stored in the draft's wiki page along with the resolutions.

        iii) When the Document Mentor's final review at WGLC is done,
        the Document Mentor should move the draft to a list of
        "previously mentored documents" associated with their name.
        It is ideal to write up a summary of the document mentoring experience.

   c) Unmentored Documents: Drafts which have declined a document
   mentor should be listed on a wiki page.

   d) For each WG's wiki, it'd be useful to have the list of drafts
   with their associated Document Mentors (or lack thereof) and the
   link to the draft's wiki page.

The Basic Process:

  When a new WG draft is adopted, the WG chairs and the Routing
  Directorate Coordinators discuss and agree on possible Document
  Mentors (up to 3).  Then the Routing Directorate Coordinator
  confirms with the Routing Directorate members about their
  availability and willingness to mentor this particular draft. Once
  one is selected, the Routing Directorate Coordinator updates the
  wiki and notifies the WG chairs and draft authors.

     a) With the agreement of the ADs, a Document Mentor who is not a
     member of the Routing Directorate may be selected.

     b) The WG chairs can, after consulting with the draft authors,
     decline to have a Document Mentor.

     c) The Document Mentor should coordinate with the Document
     Shepherd for hand-off after WGLC.








--Apple-Mail-62A0C197-894A-48D6-A5FB-1E11BB669C1D-- From nobody Mon Mar 31 14:44:01 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FB21A6FF6; Mon, 31 Mar 2014 14:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 P9a4biTeegbl; Mon, 31 Mar 2014 14:43:52 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFEE1A6FF9; Mon, 31 Mar 2014 14:43:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 3B4BB2459E2; Mon, 31 Mar 2014 14:43:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2B0B12412B7; Mon, 31 Mar 2014 14:43:48 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-67BFC5F6-7BAB-4A99-9A78-438EE5E0F651 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D167) In-Reply-To: Date: Mon, 31 Mar 2014 23:43:45 +0200 Content-Transfer-Encoding: 7bit Message-Id: <9605C3E4-C7B0-4A80-96E7-1EE5058DD830@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> <860b9a4c713e472a9fe4d426e9d9b01e@CO2PR05MB636.namprd05.prod.outlook.com> To: Alia Atlas Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/G2EWFyI010OdLR3pkhoAs0iwkMQ Cc: Ross Callon , "adrian@olddog.co.uk" , "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:43:56 -0000 --Apple-Mail-67BFC5F6-7BAB-4A99-9A78-438EE5E0F651 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 31 mars 2014, at 22:27, Alia Atlas wrote: >=20 >> On Mon, Mar 31, 2014 at 4:16 PM, Ross Callon wrote:= >> I thought that the directorate members were already document reviewers, b= ut doing one-time reviews rather than following a document throughout its jo= urney. >>=20 >=20 > Yes - and the one-time reviews happen at IETF LC or so - based on AD need/= request. > This is pushing it earlier, with the expectation that the reviewer will al= so push the technical concerns, > and then a review later at WGLC. >=20 I am repeating myself, but to me that is *exactly* the right thing to do.=20= As an author, it is immensely more helpful getting a review when you start, a= nd use that to guide the document development, than it is to get a review wh= en you feel that you already have crossed the finishing line. Also as an author, it's often hard to coerce anybody to give a review before= a document reaches WGLC/IETF LC and there's a formal deadline set. And, as an author, having an external pair of eyes who has a priori kinda pr= omised to "be available, as needed, and give the occasional review" to solic= it on occasion, is quite handy. I'm repeating myself, but my opinion is "let's give it a shot, and check bac= k in in due time". Thomas > Alia > =20 >> =20 >>=20 >> Ross >>=20 >> =20 >>=20 >> From: Alia Atlas [mailto:akatlas@gmail.com]=20 >> Sent: Monday, March 31, 2014 4:15 PM >> To: Ross Callon >>=20 >>=20 >> Cc: adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: Re: [RTG-DIR] Document Mentors >> =20 >>=20 >> Ross, >>=20 >> =20 >>=20 >> On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon wrote:= >>=20 >> It seems to me that if a document has experienced authors who are product= ive IETF regulars, then they probably don't need a mentor on an ongoing basi= s. They might benefit from a one-time review. >>=20 >> =20 >>=20 >> Yes, if you look at the problem and goals, they apply to most documents. = Get good solid reviews early in the process (WG adoption) and late (WGLC) a= nd then work with the authors to make sure that the technical issues are dea= lt with early enough to have impact. >>=20 >> =20 >>=20 >> Perhaps if you look at the process less as mentor and more as "dedicated d= ocument reviewer"? >>=20 >> =20 >>=20 >>=20 >> Thus the question: Would this be limited to documents with inexperienced a= uthors? As WG chairs do we envision other reasons why a particular document m= ight benefit from a mentor? (perhaps a document that needs a strong mathemat= ician or a security expert or a link state routing expert to help with one s= ection)? >>=20 >> =20 >>=20 >> I'd be interested in what others' perspectives are. When are reviews of= drafts useful? What text would you change? >>=20 >> =20 >>=20 >> Regards, >>=20 >> Alia >>=20 >> =20 >>=20 >> =20 >>=20 >> Ross >>=20 >>=20 >> -----Original Message----- >> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farre= l >> Sent: Monday, March 31, 2014 8:12 AM >> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >> Subject: [RTG-DIR] Document Mentors >>=20 >> Hi, >>=20 >> One of the ideas to come out of the recent discussions is appointing a me= ntor >> per document from the time it is adopted by a Routing Area working group u= ntil >> it completes WG last call. >>=20 >> This would be voluntary in two dimensions: >> - the WG chairs would need to deem that one would be beneficial >> - we would have to find someone from the Directorate willing to >> take on the document. >>=20 >> We don't think that technology expertise is as useful in this as IETF clu= e and >> general routing experience. >>=20 >> So, to take this forward we would need: >> - WG chairs to say "Yes, we can see that that would have >> potential benefit >> - Directorate members to say "Yes, we could take on that >> additional work. >>=20 >> Alia and I have put together some preliminary notes on how this would all= hang >> together. >>=20 >> Your opinions and rotten fruit are solicited. >>=20 >> Thanks, >> Adrian and Alia >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Document Mentors in the Routing Area >>=20 >> The Problems: >>=20 >> a) Drafts get little review outside the working group and sometimes ins= ide >> the working group until after working group last call. At that point it= is >> often >> painful and costly to make meaningful improvements to the drafts. >>=20 >> b) Authors may not know how or whom to ask for assistance or review >> (e.g., IANA section, Security Section, Operational and Management >> considerations, details of a protocol, etc. ). >>=20 >> The Goals: >>=20 >> a) Excellent and consistent review at WG adoption and before WG last >> call. >>=20 >> b) Ability for prolonged discussion and problem-solving when the >> draft can still be easily enhanced. >>=20 >> c) Reduced time to delivery of RFCs. >>=20 >> d) Quality documents. >>=20 >> The Solution: >>=20 >> A per-document mentor who is a known neutral party to whom the >> authors can go for advice on: >> - how to write a section >> - specific issues that arise >> - ways to resolve conflicts. >>=20 >> The document mentor also watches the progress of the document >> and gives advice and steerage. >>=20 >> It is not assumed that every document will need or benefit from >> having a mentor. >>=20 >> The Expected Workload: >>=20 >> The routing directorate has approximately 40 people. If we assume >> that approximately 50 drafts pass WG adoption and a similar number >> pass WGLC each year, then the load is 2.5 documents per person >> per year. If we assume that there are about 200 WG drafts in the >> Routing Area and that they all have mentors, then each Routing >> Directorate member will have 5 drafts that she or he is mentoring. >>=20 >> The Supporting Data Artefacts: >>=20 >> a) As part of the Routing Area wiki, the areas of knowledge for >> each member of the Routing Directorate will be publicly specified. >> This is added to the wiki by the Routing Area Coordinators (or AD) >> when the member joins the Routing Directorate, updated by the >> member while he or she is on the Directorate, and updated by the >> Routing Area Coordinators (or AD) if and when the member's term >> renews. >>=20 >> b) Document Mentor Availability and Assignments: As part of the >> Routing Area wiki, each Directorate member will specify the maximum >> number of documents that he or she is able to mentor. Also listed >> will be the list of mentored documents (and a count). >>=20 >> i) When a Directorate member is assigned as the Document >> mentor, the Routing Directorate Coordinator will update the >> wiki page and create a wiki page for the draft. >>=20 >> ii) When a Document Mentor provides a review, that should be >> stored in the draft's wiki page along with the resolutions. >>=20 >> iii) When the Document Mentor's final review at WGLC is done, >> the Document Mentor should move the draft to a list of >> "previously mentored documents" associated with their name. >> It is ideal to write up a summary of the document mentoring exper= ience. >>=20 >> c) Unmentored Documents: Drafts which have declined a document >> mentor should be listed on a wiki page. >>=20 >> d) For each WG's wiki, it'd be useful to have the list of drafts >> with their associated Document Mentors (or lack thereof) and the >> link to the draft's wiki page. >>=20 >> The Basic Process: >>=20 >> When a new WG draft is adopted, the WG chairs and the Routing >> Directorate Coordinators discuss and agree on possible Document >> Mentors (up to 3). Then the Routing Directorate Coordinator >> confirms with the Routing Directorate members about their >> availability and willingness to mentor this particular draft. Once >> one is selected, the Routing Directorate Coordinator updates the >> wiki and notifies the WG chairs and draft authors. >>=20 >> a) With the agreement of the ADs, a Document Mentor who is not a >> member of the Routing Directorate may be selected. >>=20 >> b) The WG chairs can, after consulting with the draft authors, >> decline to have a Document Mentor. >>=20 >> c) The Document Mentor should coordinate with the Document >> Shepherd for hand-off after WGLC. >=20 --Apple-Mail-67BFC5F6-7BAB-4A99-9A78-438EE5E0F651 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 31 mars 2014, at 22:= 27, Alia Atlas <akatlas@gmail.com> wrote:

On Mon, Mar 31, 2014 at 4= :16 PM, Ross Callon <rcallon@juniper.net> wrote:

I thought that the director= ate members were already document reviewers, but doing one-time reviews rath= er than following a document throughout its journey.


Yes - and the one-time reviews h= appen at IETF LC or so - based on AD need/request.
This is pushing= it earlier, with the expectation that the reviewer will also push the techn= ical concerns,
and then a review later at WGLC.

=

I am repeating myself, but to me that is *= exactly* the right thing to do. 

As an author, it is= immensely more helpful getting a review when you start, and use that to gui= de the document development, than it is to get a review when you feel that y= ou already have crossed the finishing line.

Also as= an author, it's often hard to coerce anybody to give a review before a docu= ment reaches WGLC/IETF LC and there's a formal deadline set.

<= /div>
And, as an author, having an external pair of eyes who has a prior= i kinda promised to "be available, as needed, and give the occasional review= " to solicit on occasion, is quite handy.

I'm repea= ting myself, but my opinion is "let's give it a shot, and check back in in d= ue time".

Thomas


=
<= div class=3D"gmail_quote">
Alia
 

 =

Ross

 =

From: Alia Atlas [= mailto:akatlas@gmail.= com]
Sent: Monday, March 31, 2014 4:15 PM
To: Ross Callon


Cc: adrian@o= lddog.co.uk; rtg-d= ir@ietf.org; rt= g-chairs@ietf.org
Subject: Re: [RTG-DIR] Document Mentors

 

Ross,

 

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <rcallon@juniper.net= > wrote:

It seems to me that if a document has experienced aut= hors who are productive IETF regulars, then they probably don't need a mento= r on an ongoing basis. They might benefit from a one-time review.<= /u>

 

Yes, if you look at the problem and goals, they apply= to most documents.  Get good solid reviews early in the process (WG ad= option) and late (WGLC) and then work with the authors to make sure that the= technical issues are dealt with early enough to have impact.

 

Perhaps if you look at the process less as mentor and= more as "dedicated document reviewer"?

 


Thus the question: Would this be limited to documents with inexperienced aut= hors? As WG chairs do we envision other reasons why a particular document mi= ght benefit from a mentor? (perhaps a document that needs a strong mathemati= cian or a security expert or a link state routing expert to help with one section)?

 

I'd be interested in what others' perspectives are. &= nbsp; When are reviews of drafts useful?  What text would you change?

 

Regards,

Alia

 

 

Ross


-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: [RTG-DIR] Document Mentors

Hi,

One of the ideas to come out of the recent discussions is appointing a mento= r
per document from the time it is adopted by a Routing Area working group unt= il
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
   take on the document.

We don't think that technology expertise is as useful in this as IETF clue a= nd
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
   potential benefit
- Directorate members to say "Yes, we could take on that
  additional work.

Alia and I have put together some preliminary notes on how this would all ha= ng
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Document Mentors in the Routing Area

The Problems:

  a) Drafts get little review outside the working group and sometimes i= nside
  the working group until after working group last call. At that point i= t is
often
  painful and costly to make meaningful improvements to the drafts.
=
  b) Authors may not know how or whom to ask for assistance  or re= view
  (e.g., IANA section, Security Section, Operational and Management
=   considerations, details of a protocol, etc. ).

The Goals:

  a) Excellent and consistent review at WG adoption and before WG last<= br>   call.

  b) Ability for prolonged discussion and problem-solving when the
  draft can still be easily enhanced.

  c) Reduced time to delivery of RFCs.

  d) Quality documents.

The Solution:

  A per-document mentor who is a known neutral party to whom the
  authors can go for advice on:
  - how to write a section
  - specific issues that arise
  - ways to resolve conflicts.

  The document mentor also watches the progress of the document
  and gives advice and steerage.

  It is not assumed that every document will need or benefit from
  having a mentor.

The Expected Workload:

   The routing directorate has approximately 40 people.  If w= e assume
   that approximately 50 drafts pass WG adoption and a similar num= ber
   pass WGLC each year, then the load is 2.5 documents per person<= br>    per year.  If we assume that there are about 200 WG drafts= in the
   Routing Area and that they all have mentors, then each Routing<= br>    Directorate member will have 5 drafts that she or he is mentori= ng.

The Supporting Data Artefacts:

   a) As part of the Routing Area wiki, the areas of knowledge for=
   each member of the Routing Directorate will be publicly specifi= ed.
   This is added to the wiki by the Routing Area Coordinators (or A= D)
   when the member joins the Routing Directorate, updated by the    member while he or she is on the Directorate, and updated by th= e
   Routing Area Coordinators (or AD) if and when the member's term=
   renews.

   b) Document Mentor Availability and Assignments: As part of the=
   Routing Area wiki, each Directorate member will specify the max= imum
   number of documents that he or she is able to mentor.  Als= o listed
   will be the list of mentored documents (and a count).

        i) When a Directorate member is assigned as the D= ocument
        mentor, the Routing Directorate Coordinator will= update the
        wiki page and create a wiki page for the draft.<= br>
        ii) When a Document Mentor provides a review, th= at should be
        stored in the draft's wiki page along with the r= esolutions.

        iii) When the Document Mentor's final review at W= GLC is done,
        the Document Mentor should move the draft to a l= ist of
        "previously mentored documents" associated with t= heir name.
        It is ideal to write up a summary of the documen= t mentoring experience.

   c) Unmentored Documents: Drafts which have declined a document<= br>    mentor should be listed on a wiki page.

   d) For each WG's wiki, it'd be useful to have the list of draft= s
   with their associated Document Mentors (or lack thereof) and th= e
   link to the draft's wiki page.

The Basic Process:

  When a new WG draft is adopted, the WG chairs and the Routing
  Directorate Coordinators discuss and agree on possible Document
  Mentors (up to 3).  Then the Routing Directorate Coordinator
=   confirms with the Routing Directorate members about their
  availability and willingness to mentor this particular draft. Once   one is selected, the Routing Directorate Coordinator updates the
  wiki and notifies the WG chairs and draft authors.

     a) With the agreement of the ADs, a Document Mentor who i= s not a
     member of the Routing Directorate may be selected.

     b) The WG chairs can, after consulting with the draft au= thors,
     decline to have a Document Mentor.

     c) The Document Mentor should coordinate with the Docume= nt
     Shepherd for hand-off after WGLC.






 


= --Apple-Mail-67BFC5F6-7BAB-4A99-9A78-438EE5E0F651-- From nobody Mon Mar 31 14:46:21 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB8E1A797C; Mon, 31 Mar 2014 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 FENpPO6i-_Hi; Mon, 31 Mar 2014 14:46:14 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56F1A6FD0; Mon, 31 Mar 2014 14:46:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9B48C240462; Mon, 31 Mar 2014 14:46:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.142] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6131C24121C; Mon, 31 Mar 2014 14:46:10 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-388BA36B-F0CC-4AC5-9171-618EF4F03901 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D167) In-Reply-To: <9605C3E4-C7B0-4A80-96E7-1EE5058DD830@thomasclausen.org> Date: Mon, 31 Mar 2014 23:46:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: <44B8561C-C5E9-443B-B19A-9CBBD1141D60@thomasclausen.org> References: <00cc01cf4cda$78f298e0$6ad7caa0$@olddog.co.uk> <0df4bf3fd1584cd78699c9fe127fe414@CO2PR05MB636.namprd05.prod.outlook.com> <860b9a4c713e472a9fe4d426e9d9b01e@CO2PR05MB636.namprd05.prod.outlook.com> <9605C3E4-C7B0-4A80-96E7-1EE5058DD830@thomasclausen.org> To: Alia Atlas Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/B-vSvm8Mp2Es_Z2RBo_E3g6LKx4 Cc: Ross Callon , "adrian@olddog.co.uk" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] Document Mentors X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 21:46:18 -0000 --Apple-Mail-388BA36B-F0CC-4AC5-9171-618EF4F03901 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 31 mars 2014, at 23:43, Thomas Heide Clausen w= rote: >=20 >=20 >> On 31 mars 2014, at 22:27, Alia Atlas wrote: >>=20 >>> On Mon, Mar 31, 2014 at 4:16 PM, Ross Callon wrote= : >>> I thought that the directorate members were already document reviewers, b= ut doing one-time reviews rather than following a document throughout its jo= urney. >>>=20 >>=20 >> Yes - and the one-time reviews happen at IETF LC or so - based on AD need= /request. >> This is pushing it earlier, with the expectation that the reviewer will a= lso push the technical concerns, >> and then a review later at WGLC. >=20 > I am repeating myself, but to me that is *exactly* the right thing to do.=20= >=20 > As an author, it is immensely more helpful getting a review when you start= , and use that to guide the document development, than it is to get a review= when you feel that you already have crossed the finishing line. >=20 > Also as an author, it's often hard to coerce anybody to give a review befo= re a document reaches WGLC/IETF LC and there's a formal deadline set. >=20 argh...=20 s/anybody/anybody from outside the working group/ s/give a review/give a detailed review/ > And, as an author, having an external pair of eyes who has a priori kinda p= romised to "be available, as needed, and give the occasional review" to soli= cit on occasion, is quite handy. >=20 > I'm repeating myself, but my opinion is "let's give it a shot, and check b= ack in in due time". >=20 > Thomas >=20 >=20 >> Alia >> =20 >>> =20 >>>=20 >>> Ross >>>=20 >>> =20 >>>=20 >>> From: Alia Atlas [mailto:akatlas@gmail.com]=20 >>> Sent: Monday, March 31, 2014 4:15 PM >>> To: Ross Callon >>>=20 >>>=20 >>> Cc: adrian@olddog.co.uk; rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Subject: Re: [RTG-DIR] Document Mentors >>> =20 >>>=20 >>> Ross, >>>=20 >>> =20 >>>=20 >>> On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon wrote= : >>>=20 >>> It seems to me that if a document has experienced authors who are produc= tive IETF regulars, then they probably don't need a mentor on an ongoing bas= is. They might benefit from a one-time review. >>>=20 >>> =20 >>>=20 >>> Yes, if you look at the problem and goals, they apply to most documents.= Get good solid reviews early in the process (WG adoption) and late (WGLC) a= nd then work with the authors to make sure that the technical issues are dea= lt with early enough to have impact. >>>=20 >>> =20 >>>=20 >>> Perhaps if you look at the process less as mentor and more as "dedicated= document reviewer"? >>>=20 >>> =20 >>>=20 >>>=20 >>> Thus the question: Would this be limited to documents with inexperienced= authors? As WG chairs do we envision other reasons why a particular documen= t might benefit from a mentor? (perhaps a document that needs a strong mathe= matician or a security expert or a link state routing expert to help with on= e section)? >>>=20 >>> =20 >>>=20 >>> I'd be interested in what others' perspectives are. When are reviews o= f drafts useful? What text would you change? >>>=20 >>> =20 >>>=20 >>> Regards, >>>=20 >>> Alia >>>=20 >>> =20 >>>=20 >>> =20 >>>=20 >>> Ross >>>=20 >>>=20 >>> -----Original Message----- >>> From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farr= el >>> Sent: Monday, March 31, 2014 8:12 AM >>> To: rtg-dir@ietf.org; rtg-chairs@ietf.org >>> Subject: [RTG-DIR] Document Mentors >>>=20 >>> Hi, >>>=20 >>> One of the ideas to come out of the recent discussions is appointing a m= entor >>> per document from the time it is adopted by a Routing Area working group= until >>> it completes WG last call. >>>=20 >>> This would be voluntary in two dimensions: >>> - the WG chairs would need to deem that one would be beneficial >>> - we would have to find someone from the Directorate willing to >>> take on the document. >>>=20 >>> We don't think that technology expertise is as useful in this as IETF cl= ue and >>> general routing experience. >>>=20 >>> So, to take this forward we would need: >>> - WG chairs to say "Yes, we can see that that would have >>> potential benefit >>> - Directorate members to say "Yes, we could take on that >>> additional work. >>>=20 >>> Alia and I have put together some preliminary notes on how this would al= l hang >>> together. >>>=20 >>> Your opinions and rotten fruit are solicited. >>>=20 >>> Thanks, >>> Adrian and Alia >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Document Mentors in the Routing Area >>>=20 >>> The Problems: >>>=20 >>> a) Drafts get little review outside the working group and sometimes in= side >>> the working group until after working group last call. At that point i= t is >>> often >>> painful and costly to make meaningful improvements to the drafts. >>>=20 >>> b) Authors may not know how or whom to ask for assistance or review >>> (e.g., IANA section, Security Section, Operational and Management >>> considerations, details of a protocol, etc. ). >>>=20 >>> The Goals: >>>=20 >>> a) Excellent and consistent review at WG adoption and before WG last >>> call. >>>=20 >>> b) Ability for prolonged discussion and problem-solving when the >>> draft can still be easily enhanced. >>>=20 >>> c) Reduced time to delivery of RFCs. >>>=20 >>> d) Quality documents. >>>=20 >>> The Solution: >>>=20 >>> A per-document mentor who is a known neutral party to whom the >>> authors can go for advice on: >>> - how to write a section >>> - specific issues that arise >>> - ways to resolve conflicts. >>>=20 >>> The document mentor also watches the progress of the document >>> and gives advice and steerage. >>>=20 >>> It is not assumed that every document will need or benefit from >>> having a mentor. >>>=20 >>> The Expected Workload: >>>=20 >>> The routing directorate has approximately 40 people. If we assume >>> that approximately 50 drafts pass WG adoption and a similar number >>> pass WGLC each year, then the load is 2.5 documents per person >>> per year. If we assume that there are about 200 WG drafts in the >>> Routing Area and that they all have mentors, then each Routing >>> Directorate member will have 5 drafts that she or he is mentoring. >>>=20 >>> The Supporting Data Artefacts: >>>=20 >>> a) As part of the Routing Area wiki, the areas of knowledge for >>> each member of the Routing Directorate will be publicly specified. >>> This is added to the wiki by the Routing Area Coordinators (or AD) >>> when the member joins the Routing Directorate, updated by the >>> member while he or she is on the Directorate, and updated by the >>> Routing Area Coordinators (or AD) if and when the member's term >>> renews. >>>=20 >>> b) Document Mentor Availability and Assignments: As part of the >>> Routing Area wiki, each Directorate member will specify the maximum >>> number of documents that he or she is able to mentor. Also listed >>> will be the list of mentored documents (and a count). >>>=20 >>> i) When a Directorate member is assigned as the Document >>> mentor, the Routing Directorate Coordinator will update the >>> wiki page and create a wiki page for the draft. >>>=20 >>> ii) When a Document Mentor provides a review, that should be >>> stored in the draft's wiki page along with the resolutions. >>>=20 >>> iii) When the Document Mentor's final review at WGLC is done, >>> the Document Mentor should move the draft to a list of >>> "previously mentored documents" associated with their name. >>> It is ideal to write up a summary of the document mentoring expe= rience. >>>=20 >>> c) Unmentored Documents: Drafts which have declined a document >>> mentor should be listed on a wiki page. >>>=20 >>> d) For each WG's wiki, it'd be useful to have the list of drafts >>> with their associated Document Mentors (or lack thereof) and the >>> link to the draft's wiki page. >>>=20 >>> The Basic Process: >>>=20 >>> When a new WG draft is adopted, the WG chairs and the Routing >>> Directorate Coordinators discuss and agree on possible Document >>> Mentors (up to 3). Then the Routing Directorate Coordinator >>> confirms with the Routing Directorate members about their >>> availability and willingness to mentor this particular draft. Once >>> one is selected, the Routing Directorate Coordinator updates the >>> wiki and notifies the WG chairs and draft authors. >>>=20 >>> a) With the agreement of the ADs, a Document Mentor who is not a >>> member of the Routing Directorate may be selected. >>>=20 >>> b) The WG chairs can, after consulting with the draft authors, >>> decline to have a Document Mentor. >>>=20 >>> c) The Document Mentor should coordinate with the Document >>> Shepherd for hand-off after WGLC. >>=20 --Apple-Mail-388BA36B-F0CC-4AC5-9171-618EF4F03901 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 31 mars 2014, at 23:= 43, Thomas Heide Clausen <ietf@= thomasclausen.org> wrote:


On 31 mars 2014, at 22:27, Alia Atlas <akatlas@gmail.com> wrote:

On Mon, Mar 31, 2014 at 4:16 PM, Ross Callon <rcallon@jun= iper.net> wrote:

I thought that the director= ate members were already document reviewers, but doing one-time reviews rath= er than following a document throughout its journey.


Yes - and the one-time reviews h= appen at IETF LC or so - based on AD need/request.
This is pushing= it earlier, with the expectation that the reviewer will also push the techn= ical concerns,
and then a review later at WGLC.

=

I am repeating myself, but to me that is *= exactly* the right thing to do. 

As an author, it is= immensely more helpful getting a review when you start, and use that to gui= de the document development, than it is to get a review when you feel that y= ou already have crossed the finishing line.

Also as= an author, it's often hard to coerce anybody to give a review before a docu= ment reaches WGLC/IETF LC and there's a formal deadline set.

<= /div>
argh... 

s/anybody/anybody f= rom outside the working group/

s/give a review/give= a detailed review/

And, a= s an author, having an external pair of eyes who has a priori kinda promised= to "be available, as needed, and give the occasional review" to solicit on o= ccasion, is quite handy.

I'm repeating myself, but m= y opinion is "let's give it a shot, and check back in in due time".

Thomas


Alia
 

 =

Ross

 =

From: Alia Atlas [= mailto:akatlas@gmail.= com]
Sent: Monday, March 31, 2014 4:15 PM
To: Ross Callon


Cc: adrian@o= lddog.co.uk; rtg-d= ir@ietf.org; rt= g-chairs@ietf.org
Subject: Re: [RTG-DIR] Document Mentors

 

Ross,

 

On Mon, Mar 31, 2014 at 3:19 PM, Ross Callon <rcallon@juniper.net= > wrote:

It seems to me that if a document has experienced aut= hors who are productive IETF regulars, then they probably don't need a mento= r on an ongoing basis. They might benefit from a one-time review.<= /u>

 

Yes, if you look at the problem and goals, they apply= to most documents.  Get good solid reviews early in the process (WG ad= option) and late (WGLC) and then work with the authors to make sure that the= technical issues are dealt with early enough to have impact.

 

Perhaps if you look at the process less as mentor and= more as "dedicated document reviewer"?

 


Thus the question: Would this be limited to documents with inexperienced aut= hors? As WG chairs do we envision other reasons why a particular document mi= ght benefit from a mentor? (perhaps a document that needs a strong mathemati= cian or a security expert or a link state routing expert to help with one section)?

 

I'd be interested in what others' perspectives are. &= nbsp; When are reviews of drafts useful?  What text would you change?

 

Regards,

Alia

 

 

Ross


-----Original Message-----
From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, March 31, 2014 8:12 AM
To: rtg-dir@ietf.org; rtg-chairs@ietf.org
Subject: [RTG-DIR] Document Mentors

Hi,

One of the ideas to come out of the recent discussions is appointing a mento= r
per document from the time it is adopted by a Routing Area working group unt= il
it completes WG last call.

This would be voluntary in two dimensions:
- the WG chairs would need to deem that one would be beneficial
- we would have to find someone from the Directorate willing to
   take on the document.

We don't think that technology expertise is as useful in this as IETF clue a= nd
general routing experience.

So, to take this forward we would need:
- WG chairs to say "Yes, we can see that that would have
   potential benefit
- Directorate members to say "Yes, we could take on that
  additional work.

Alia and I have put together some preliminary notes on how this would all ha= ng
together.

Your opinions and rotten fruit are solicited.

Thanks,
Adrian and Alia

=3D=3D=3D=3D=3D=3D=3D=3D=3D

Document Mentors in the Routing Area

The Problems:

  a) Drafts get little review outside the working group and sometimes i= nside
  the working group until after working group last call. At that point i= t is
often
  painful and costly to make meaningful improvements to the drafts.
=
  b) Authors may not know how or whom to ask for assistance  or re= view
  (e.g., IANA section, Security Section, Operational and Management
=   considerations, details of a protocol, etc. ).

The Goals:

  a) Excellent and consistent review at WG adoption and before WG last<= br>   call.

  b) Ability for prolonged discussion and problem-solving when the
  draft can still be easily enhanced.

  c) Reduced time to delivery of RFCs.

  d) Quality documents.

The Solution:

  A per-document mentor who is a known neutral party to whom the
  authors can go for advice on:
  - how to write a section
  - specific issues that arise
  - ways to resolve conflicts.

  The document mentor also watches the progress of the document
  and gives advice and steerage.

  It is not assumed that every document will need or benefit from
  having a mentor.

The Expected Workload:

   The routing directorate has approximately 40 people.  If w= e assume
   that approximately 50 drafts pass WG adoption and a similar num= ber
   pass WGLC each year, then the load is 2.5 documents per person<= br>    per year.  If we assume that there are about 200 WG drafts= in the
   Routing Area and that they all have mentors, then each Routing<= br>    Directorate member will have 5 drafts that she or he is mentori= ng.

The Supporting Data Artefacts:

   a) As part of the Routing Area wiki, the areas of knowledge for=
   each member of the Routing Directorate will be publicly specifi= ed.
   This is added to the wiki by the Routing Area Coordinators (or A= D)
   when the member joins the Routing Directorate, updated by the    member while he or she is on the Directorate, and updated by th= e
   Routing Area Coordinators (or AD) if and when the member's term=
   renews.

   b) Document Mentor Availability and Assignments: As part of the=
   Routing Area wiki, each Directorate member will specify the max= imum
   number of documents that he or she is able to mentor.  Als= o listed
   will be the list of mentored documents (and a count).

        i) When a Directorate member is assigned as the D= ocument
        mentor, the Routing Directorate Coordinator will= update the
        wiki page and create a wiki page for the draft.<= br>
        ii) When a Document Mentor provides a review, th= at should be
        stored in the draft's wiki page along with the r= esolutions.

        iii) When the Document Mentor's final review at W= GLC is done,
        the Document Mentor should move the draft to a l= ist of
        "previously mentored documents" associated with t= heir name.
        It is ideal to write up a summary of the documen= t mentoring experience.

   c) Unmentored Documents: Drafts which have declined a document<= br>    mentor should be listed on a wiki page.

   d) For each WG's wiki, it'd be useful to have the list of draft= s
   with their associated Document Mentors (or lack thereof) and th= e
   link to the draft's wiki page.

The Basic Process:

  When a new WG draft is adopted, the WG chairs and the Routing
  Directorate Coordinators discuss and agree on possible Document
  Mentors (up to 3).  Then the Routing Directorate Coordinator
=   confirms with the Routing Directorate members about their
  availability and willingness to mentor this particular draft. Once   one is selected, the Routing Directorate Coordinator updates the
  wiki and notifies the WG chairs and draft authors.

     a) With the agreement of the ADs, a Document Mentor who i= s not a
     member of the Routing Directorate may be selected.

     b) The WG chairs can, after consulting with the draft au= thors,
     decline to have a Document Mentor.

     c) The Document Mentor should coordinate with the Docume= nt
     Shepherd for hand-off after WGLC.






 


= --Apple-Mail-388BA36B-F0CC-4AC5-9171-618EF4F03901--