From nobody Fri Aug 1 01:05: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 BAC051B2948; Thu, 31 Jul 2014 10:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MeumA0mscfn; Thu, 31 Jul 2014 10:41:54 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C9F1A0114; Thu, 31 Jul 2014 10:41:50 -0700 (PDT) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id s6VHeuHV016097; Thu, 31 Jul 2014 13:41:41 -0400 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 1nfnvjhd6t-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 31 Jul 2014 13:41:40 -0400 Received: from VAWVE2K13MBX01.ciena.com (10.4.156.87) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 31 Jul 2014 13:41:39 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by VAWVE2K13MBX01.ciena.com (10.4.156.87) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 31 Jul 2014 13:41:39 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 31 Jul 2014 13:41:38 -0400 From: "Shah, Himanshu" To: "adrian@olddog.co.uk" , "'Sami Boutros (sboutros)'" , "'Mach Chen'" Date: Thu, 31 Jul 2014 13:41:37 -0400 Thread-Topic: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt Thread-Index: AQHr8B29JN6lHzMtl3Z16fKN/FuooQKiAWJDAb034jICW3sei5tLyQkggABM8WA= Message-ID: <40746B2300A8FC4AB04EE722A593182B76F4F63A@ONWVEXCHMB04.ciena.com> References: <2120028D-672D-423E-ADE1-CB61F4DFFB84@cisco.com> <40746B2300A8FC4AB04EE722A593182B76F4F1C4@ONWVEXCHMB04.ciena.com> <001201cface4$33eaf1b0$9bc0d510$@olddog.co.uk> In-Reply-To: <001201cface4$33eaf1b0$9bc0d510$@olddog.co.uk> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20852.000 X-TM-AS-Result: No--37.628600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-07-31_07:2014-07-31,2014-07-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1407310221 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/9BB6beONoyX0zHwGyxd9puZ2maM X-Mailman-Approved-At: Fri, 01 Aug 2014 01:05:22 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-lsp-ping-ttl-tlv.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [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: Thu, 31 Jul 2014 17:41:57 -0000 Hi Adrian - By no means I was wondering about the delay in review process. Sorry if it came off that way. I was surprised about the overall time and the number of revisions that it = went through. /himanshu -----Original Message----- From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: Thursday, July 31, 2014 1:23 PM To: Shah, Himanshu; 'Sami Boutros (sboutros)'; 'Mach Chen' Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl-tlv.all@t= ools.ietf.org; rtg-ads@tools.ietf.org Subject: RE: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt OK, I'm moving this forward now that we have a new revision (posted yesterd= ay, and a response from Mach today), Please note that none of this is magic! To advance a document that is in re= view you have to complete the discussion of review comments and post a revi= sion. The authors and shepherd are responsible for chasing down those comme= nts: you can come to the AD to handle issues of silence, but the AD cannot = micro-manage all of the documents and it doesn't help to ask why this has t= aken so long when no update was posted. Adrian > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: 31 July 2014 00:15 > To: Sami Boutros (sboutros); Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl-=20 > tlv.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: RE: RtgDir review: draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >=20 > This draft fills a major shortcoming of the VCCV ping over MS-PW=20 > (especially if > reply mode is in-band). > I am not sure why this draft is stuck (i.e. taking too long to go through= ). >=20 > Is there a provisional IANA assignment for the TTL TLV type value? >=20 > Thanks, > himanshu >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sami Boutros > (sboutros) > Sent: Wednesday, July 30, 2014 3:44 PM > To: Mach Chen > Cc: rtg-dir@ietf.org; mpls@ietf.org; draft-ietf-mpls-lsp-ping-ttl-=20 > tlv.all@tools.ietf.org; rtg-ads@tools.ietf.org > Subject: Re: [mpls] RtgDir review:=20 > draft-ietf-mpls-lsp-ping-ttl-tlv-07.txt >=20 > Resending.. >=20 > On May 15, 2014, at 9:20 PM, Sami Boutros (sboutros) wrote: >=20 > >> > >> Minor Issues: > >> > >> 1. Since the TTL TLV is defined for both MS-PW and bidirectional=20 > >> co-routed LSP, it should be better to explicitly state this in the=20 > >> abstract section. > >> > > > > Sami: Sure will do. > > > >> 2. "LSP-Ping echo request", "LSP-Ping request", "MPLS echo=20 > >> request", "echo request" and "request" are interchangeably used in=20 > >> the draft, it's better to unify the usage of it to "MPLS echo=20 > >> request" (to align with the usage in RFC4379). For "echo reply",=20 > >> "bidirectional co-routed LSP", they have the similar issue. > >> > > > > Sami: Ok, will fix that. > > > >> 3.Section 3.1 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | Value | Reserved | Flags | > >> =20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> For the TTL TLV, the value filed should include the "value",=20 > >> "Reserved" and "Flags", so it's better to change the "Value" field=20 > >> to "TTL" field hence to reduce the confusion. > >> > > > > Sami: Sure. > > > >> 4. Section 3.2 > >> "This TLV shall be included in the echo request by the originator=20 > >> of request. The use of this TLV is optional. If a receiver does not=20 > >> understand the TTL TLV, it will simply ignore the TLV (Type value=20 > >> of TLV is assumed to be in the range of optional TLV's which SHOULD=20 > >> be ignored if an implementation does not support or understand=20 > >> them). In the absence of TTL TLV or if TTL TLV is ignored by a=20 > >> receiver, the determination of the TTL value used in the MPLS label=20 > >> 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=20 > >> to apply the procedures defined in RFC4379 or just let it to the=20 > >> implementation?I guess you assume to apply the definition in=20 > >> RFC4379, > > > > Sami: It is out of scope of this document, but for sure procedure in=20 > > 4379 apply. > >> if > > > >> so, the TTL of the MPLS label will be more probably set to 255,=20 > >> means the echo reply will be sent to the ingress of the MS-PW or=20 > >> LSP. I am not sure whether this is the right procedure, it seems a=20 > >> security issue. IMHO, it does not make any sense to expect the=20 > >> receiver to send echo reply in this situation, and even sent, the=20 > >> initiator will not receive the reply. The safer way is to drop the=20 > >> whole echo request and > record an error log. > > > > > > Sami: > > > > We are not saying the receiver must send a reply, however if he does=20 > > the reply may be received by the ingress node which might be the=20 > > wrong node, since the receiver may not set the TTL properly on the=20 > > reply, keep in mind that this is a receiver with an old=20 > > implementation and the TLV is > optional. > > > > Please refer to the security section for your security concern. > > > > Sami: > > > > > >> > >> 5. Section 3.2 > >> > >> "In other words, if the value of the TTL provided by this TLV does=20 > >> not match the TTL determined by other means, such as Switching=20 > >> Point TLV in MS-PW, then TTL TLV must be used." > >> Here, it implies that the receiver has to perform TTL matching=20 > >> process, since how to set the TTL is independent of such matching,=20 > >> seems this sentence is redundant and confusion. > >> > > > > Sami: Are you familiar with the switching point TLV? and what it includ= es? > > > >> 6. Section 4. > >> > >> "...The value field of the TTL TLV and the TTL field of the MPLS=20 > >> label are set to 2," > >> > >> I guess that the MPLS Label is the PW label, right? It's better to=20 > >> add more text to make this more explicit. In addition, how to set=20 > >> the TTL value of the tunnel Label? 255 or any other value? > >> > > > > Sami: The tunnel label TTL is irrelevant here, however we will make=20 > > it explicit > that this is a PW label. > > > >> 5. Section 4.1. Traceroute mode > >> "In the traceroute mode TTL value in the TLV is successively set=20 > >> to 1, 2, and so on. This is similar to the TTL values used for the=20 > >> label set on the packet." > >> IMHO, some text may be needed to clarify which "FEC" should be=20 > >> carried, especially for MS-PW trace. Since in Section 4.0, the=20 > >> example says the FEC of segment C-D should be carried, does it mean=20 > >> the FEC of last PW Segment of the segment under test should be=20 > >> carried or the FEC will vary when TTL changed. For example, when=20 > >> perform segment trace (e.g., to trace B-D segment), when TTL is 1,=20 > >> which FEC > should be carried? > > > > Sami: > > We are not here redefining a trace route for a MS-PW, we are=20 > > describing how > our extensions will apply. > > Sami: > > > >> > >> 6. Section 4.2. Error scenario > >> For this scenario, do you need to define some error codes here? > > > > Sami: > > The section describe how to handle the error scenario, there is no=20 > > need for an > error code. > > Sami: > > > >> > >> 7. For MS-PW trace, seems that you assume the tunnel is pipe mode,=20 > >> if so, it should be explicitly stated. If not, you should define=20 > >> how the MS-PW trace works (given that the tunnels in both=20 > >> directions may span different hops). > > > > Sami: > > Not sure I get the concern? Again we are not re-defining how MS-PW=20 > > trace > work. > > > > Thanks, > > > > Sami > >> > >> Nits: > >> > >> 1. Please check the text for acronyms that have not been expanded=20 > >> in their first use. > >> > >> 2. I run the idnits tool and found the following nits, please check=20 > >> and fix. > >> (See RFCs 3967 and 4897 for information about using normative=20 > >> references > >> to lower-maturity documents in RFCs) > >> > >> -- Looks like a reference, but probably isn't: 'RFC2119' on line=20 > >> 121 > >> > >> -- Looks like a reference, but probably isn't: 'RFC4379' on line=20 > >> 258 > >> > >> =3D=3D Unused Reference: '1' is defined on line 284, but no explicit=20 > >> reference > >> was found in the text > >> > >> =3D=3D Unused Reference: '2' is defined on line 287, but no explicit=20 > >> reference > >> was found in the text > >> > >> =3D=3D Unused Reference: '3' is defined on line 291, but no explicit=20 > >> reference > >> 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=20 > >> concept, it's better to add related references to this document. > >> > >> > >> Best regards, > >> Mach > >> > >> > > >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Tue Aug 5 11:44: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 84C811B2AD4; Tue, 5 Aug 2014 11:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 OkLfPFr0XQys; Tue, 5 Aug 2014 11:44:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1869D1B2ACE; Tue, 5 Aug 2014 11:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32592; q=dns/txt; s=iport; t=1407264258; x=1408473858; h=from:to:cc:subject:date:message-id:mime-version; bh=SrHOEkIq+qOBByHZMNgnNJ1VoXwNhgI8PjQgj004b+0=; b=M73yn2vkbNYCsnrag5TOS68Igbq64zY0lWzHg3dpkThuGGJenYsW/jxr PWeGD2GR9SD5Etwk0KU9mRzELeTbWYfIvK5K/o+Ov2fkQTdqC4TqkdhsN YBthjbqZka3gou6s6MDwIBWoqD7V2HqzqRoc2fQV2bgCUB270ZGR6460H I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoHABwl4VOtJV2c/2dsb2JhbABbgkdGUlcBA4JzyH+HSBp9FneECiMEUhIBHCQKAgQwJwQOIIgnDaxLlxYXjUaBdRGDAIFSBY57hi+CN4QsgVSTDYNNbYFF X-IronPort-AV: E=Sophos;i="5.01,806,1400025600"; d="scan'208,217";a="345253569" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 05 Aug 2014 18:44:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s75Ii1bK027505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 18:44:01 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.66]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 13:44:01 -0500 From: "Alvaro Retana (aretana)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: AQHPsN05Fz/zKfFp40GaWihT2u/peQ== Date: Tue, 5 Aug 2014 18:44:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D0069E2E65909aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/BpIYduivia_VQFuAyhjv8DYqUMM Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Tue, 05 Aug 2014 18:44:21 -0000 --_000_D0069E2E65909aretanaciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkhDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUg YXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyPGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI+DQoNCkFsdGhvdWdoIHRoZXNlIGNvbW1l bnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3Vs ZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90 aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUg dG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJh ZnQuDQoNCkRvY3VtZW50OiBkcmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC0wMSAoR2FwIEFu YWx5c2lzIGZvciBPcGVyYXRpbmcgSVB2Ni1vbmx5IE1QTFMgTmV0d29ya3MpDQpSZXZpZXdlcjog QWx2YXJvIFJldGFuYQ0KUmV2aWV3IERhdGU6IEF1Zy4gNSwgMjAxNC4NCklFVEYgTEMgRW5kIERh dGU6IEF1Zy4gOCwgMjAxNC4NCkludGVuZGVkIFN0YXR1czogSW5mb3JtYXRpb25hbA0KDQpTdW1t YXJ5Og0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0 IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KQ29tbWVu dHM6DQoNClRoaXMgZHJhZnQgY292ZXJzIGEgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ3kgdG8g ZmluZCBnYXBzIHRoYXQgbWF5IHByZXZlbnQgdGhlIHVzZSBvZiBJUHY2LW9ubHkgTVBMUyBuZXR3 b3Jrcy4gIEl0IGRvZXMgc28gaW4gYSBjb25jaXNlIGFuZCBjbGVhciBmb3JtLCBhbiBlYXN5IHJl YWQuICBJIGJlbGlldmUgdGhhdCB0aGlzIHdvcmsgaXMgdmVyeSB2YWx1YWJsZSBnaXZlbiwgYXMg dGhlIGRyYWZ0IHB1dHMgaXQsIHRoYXQgIklQdjYgaXMgYW4gaW50ZWdyYWwgcGFydCBvZiBtb2Rl cm4gbmV0d29yayBkZXBsb3ltZW50cyIuDQoNCkkgZG8gaGF2ZSBhIGNvdXBsZSBvZiBoaWdoLWxl dmVsIGl0ZW1zIEkgd2FudCB0byBicmluZyB1cC4gIEJlY2F1c2UgSSBhc3N1bWUgdGhhdCB0aGVz ZSBtYXkgaGF2ZSBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBhcHByb3ByaWF0ZSBXRyhz KSBJJ20gbm90IGxpc3RpbmcgdGhlbSBhcyBtYWpvciBpc3N1ZXMsIGFuZCB3aWxsIGRlZmVyIHRv IHdoYXQgdGhlIGNvbnNlbnN1cyBoYXMgYmVlbiBzbyBmYXIuDQoNCiAgMS4gIFdoeSBkbyB3ZSBu ZWVkIHRvIHB1Ymxpc2ggdGhpcyBkb2N1bWVudD8gIEFzIEkgc2FpZCBhYm92ZSwgSSBiZWxpZXZl IHRoZSB3b3JrIGlzIHZhbHVhYmxlLCBidXQgaXQgY2FwdHVyZXMgdGhlIHN0YXRlIGluIHRpbWUg KHRvZGF5ISkgb2YgdGhlIGdhcHMg4oCUIGl0IHBvaW50cyB0byB3b3JrIHRoYXQgYWxyZWFkeSBz b2x2ZWQgYSBwb3RlbnRpYWwgZ2FwLCBvciBpcyBpbiB0aGUgcHJvY2VzcyBvZiBzb2x2aW5nIHRo ZW0uICBBIHNpZ25pZmljYW50IHBvcnRpb24gb2YgdGhlIGdhcHMgYXJlIGFscmVhZHkgYmVpbmcg YWRkcmVzc2VkLiAgR2l2ZW4gdGhlIGltcG9ydGFuY2Ugb2YgSVB2NiwgaWYgcHVibGlzaGVkLCBz b29uIHRoaXMgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIGJlIHVwZGF0ZWQgdG8gc2F5ICJub3RoaW5n IGJyZWFrcyIuICBBZ2FpbiwgdGhlIHdvcmsgaXMgaW1wb3J0YW50LCBidXQgaXQgbWF5IGJlIGJl dHRlciBzdWl0ZWQgdG8gYmUgYSAibGl2aW5nIGRvY3VtZW50IiBhcyBhIGd1aWRlIGZvciB3aGF0 IHN0aWxsIG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4gIElmIGl0IGlzIHRvIGJlIHB1Ymxpc2hlZCwg SSB3b3VsZCBzdWdnZXN0IGF2b2lkaW5nIGxpbmtzIHRvIHdvcmsgaW4gcHJvZ3Jlc3MsIGJ1dCBs aW1pdGluZyB0aGUgY29udGVudCB0byBpZGVudGlmeWluZyB0aGUgZ2Fwcy4uYW5kIHRoZW4gbGV0 dGluZyB0aGUgc29sdXRpb24gZHJhZnRzL1JGQ3MgcG9pbnQgYmFjayB0byB0aGlzIGRvY3VtZW50 Li4gIChhbGEgcmVxdWlyZW1lbnRzIC0+IHNvbHV0aW9uKQ0KICAyLiAgSXQgaXMgaW50ZXJlc3Rp bmcgdG8gbWUgdGhhdCB0aGlzIGRyYWZ0IGNhbWUgdGhyb3VnaCB0aGUgbXBscyBXRywgYW5kIG5v dCBvbmUgb2YgdGhlIG9wZXJhdGlvbnMtZm9jdXNlZCBncm91cHMuLndoaWNoIHByZXN1bWFibHkg d291bGQgYmUgaW4gYSBiZXR0ZXIgcG9zaXRpb24gdG8gZXZhbHVhdGUgdGhlIG5lZWRzIGRlc2Ny aWJlZC4gIEdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGlzIGFscmVhZHkgaW4gV0cgTGFzdCBDYWxs LCBJJ20gYXNzdW1pbmcgdGhhdCB0aGUgYWxpZ25tZW50IGhhcyBhbHJlYWR5IGJlZW4gZGlzY3Vz c2VkIGFuZCB0aGF0IHByb3BlciBjcm9zcy1XRyByZXZpZXdzIGhhdmUgb2NjdXJyZWQuDQoNCk1h am9yIElzc3VlczoNCg0KTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6DQoN CiAgKiAgIFNvbWUgdGVybWlub2xvZ3kgd2FzIG5vdCBleHBhbmRlZCBiZWZvcmUvd2hlbiBpdCB3 YXMgZmlyc3QgdXNlZDogd2UgYWxsIGtub3cgd2hhdCBNUExTIGlzLCBidXQgb3RoZXJzIGxpa2Ug TFNSLCBMRVIsIEZFQywgTDJWUE4sIEVWUE4sIE5HLW1WUE4sIGV0Yy4gc2hvdWxkIGJlIGV4cGFu ZGVkLg0KICAqICAgU2VjdGlvbiAzLjEgKE1QTFMgRGF0YSBQbGFuZSk6ICJJbiB0aGUgY2FzZSB3 aGVyZSBhbiBJUHY0IHByZWZpeCBpcyByZXNvbHZlZCBvdmVyIGFuIElQdjYgTFNQLCBhbiBJUHY2 IEV4cGxpY2l0IE51bGwgbGFiZWwgY2Fubm90IGltbWVkaWF0ZWx5IHByZWNlZWQgYW4gSVB2NCBw YWNrZXQuIiAgSXMgdGhlcmUgYSByZWZlcmVuY2UgZm9yIHRoaXMgc3RhdGVtZW50IG9yIGlzIHRo aXMgYSByZXF1aXJlbWVudCB0byBmaWxsIGluIHRoZSBnYXA/ICBJZiBpdCBpcyBhIHJlcXVpcmVt ZW50LCBkbyB3ZSBuZWVkIHRvIGFkZCAyMTE5IGxhbmd1YWdlPw0KICAqICAgV2hlbiBhIGdhcCBl eGlzdHMsIHlvdSBjbGFzc2lmeSBpdCBhcyAibWFqb3IiIG9yICJtaW5vciIuICBXaGF0IGlzIHRo ZSBjcml0ZXJpYSB1c2VkPyAgSSB3b3VsZCBpbWFnaW5lIHRoYXQgZ2l2ZW4gdGhhdCBpdCBpcyBh IGdhcCBhbmFseXNpcywgdGhlIG9iamVjdGl2ZSBpcyB0byBwb2ludCBvdXQgdGhlIG5lZWRzLCBu b3QgY2hhcmFjdGVyaXplIHRoZW0gKGlmIEkgbmVlZCBhICJtaW5vciIgZ2FwIHRvIGJlIGZpbGxl ZCBpbiBvcmRlciBmb3IgbXkgbmV0d29yayBkZXBsb3ltZW50IHRvIG9wZXJhdGUsIGl0IGJlY29t ZXMgIm1ham9yIiB0byBtZSkuDQogICogICBUaGUgaW50cm9kdWN0aW9uIHRvIHRoZSBkcmFmdCB0 YWxrcyBhYm91dCAiZ2FwcyB0aGF0IG11c3QgYmUgYWRkcmVzc2VkIGluIG9yZGVyIHRvIGFsbG93 IE1QTFMtcmVsYXRlZCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB0byBiZSB1c2VkIHdpdGgg SVB2Ni1vbmx5IG5ldHdvcmtzIiAoIklQdjYtb25seSAobm8gSVB2NCBwcm92aXNpb25lZCBvbiB0 aGUgZGV2aWNlKSIpLCB3aGljaCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IG5vIElQdjQgaXMg cHJlc2VudCBpbiB0aGUgbmV0d29yayBhdCBhbGwuICAgSG93ZXZlciwgc2V2ZXJhbCBnYXBzIGFy ZSBpZGVudGlmaWVkIHRoYXQgb2NjdXIgaW4gIm1peGVkIiBuZXR3b3Jrcywgd2hlcmUgaXNsYW5k cyBvZiBJUHY0L0lQdjYgZXhpc3QuICBJIHdvdWxkIHN1Z2dlc3QgY2xhcmlmeWluZyB0aGUgc2Nv cGUgb2YgdGhlIGRvY3VtZW50IGluIHRoZSBpbnRyb2R1Y3Rpb24uICBTb21lIG9mIHRoZSBwbGFj ZXMgd2hlcmUgdGhlc2Ugc2NlbmFyaW9zIGFyZSBkaXNjdXNzZWQgaW5jbHVkZTogIDMuMi4yLiAo TXVsdGlwb2ludCBMRFApLCAzLjMuMi4gKEwzVlBOKSwgIDMuNC4xLiAoRXh0ZW5kZWQgSUNNUCkg YW5kIDMuNC4yLiAoTFNQIFBpbmcpLg0KICAqICAgMy4zLjEuMS4gKEVWUE4pICBJZiB0aGUgRVZQ TiB3b3JrIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50LCB0aGVuIHRha2UgaXQg b3V0LiAgQW5vdGhlciBvcHRpb24gbWF5IGJlIHRvIHRhbGsgYWJvdXQgYW55IGdhcHMgaW4gdGhl IGN1cnJlbnQgd29yay4gIFNhbWUgY29tbWVudCBmb3Igc2VjdGlvbiAzLjMuMi40LjMuIChQRS1Q RSBNdWx0aWNhc3QgUm91dGluZyBQcm90b2NvbCkuDQogICogICAzLjMuMi4gKEwzVlBOKSAgdGhl IHRleHQgc2F5cyB0aGF0IHRoZSBnYXBzIGluIFJGQzQzNjQgKG5vIFZQTi1JUHY2IGFkZHJlc3Mg YW5kIGEgMTI4IGJpdCBuZXh0LWhvcCkgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBSRkMgNDY1OSwg YnV0IGl0IHRoZW4gaWRlbnRpZmllcyB0aGUgZ2FwIGFuZCBzYXlzIHRoYXQgIlJGQzQzNjQgbXVz dCBiZSB1cGRhdGVkIi4gIFdoYXQgd291bGQgdGhhdCB1cGRhdGUgYmU/DQogICogICBTZWN0aW9u cyAzLjMuMi40LjMuIChQRS1QRSBNdWx0aWNhc3QgUm91dGluZyBQcm90b2NvbCksIDMuMy4zLiAo TVBMUy1UUCkgYW5kIDMuNC41LiAoTVBMUy1UUCBPQU0pIGFyZSBpbmNsdWRlZCwgYnV0IG91dCBv ZiBzY29wZS4uICBTaG91bGQgdGhleSBiZSByZW1vdmVkPyAgSWYgbm90LCB0aGVuIGEgc2hvcnQg anVzdGlmaWNhdGlvbiBpbiB0aGUgdGV4dCB3b3VsZCBiZSBuaWNlLg0KICAqICAgMy40LiAoTVBM UyBPQU0pICBUaGlzIHNlbnRlbmNlICJBbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyB3b3JrIGluIHB1 cmUgSVB2NiBlbnZpcm9ubWVudHMuIiBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IGFsbCB0aGUg bWVjaGFuaXNtcyB3b3JrIGNvcnJlY3RseSBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gZ2Fwcy4uYnV0 IHRoZW4gc2V2ZXJhbCBnYXBzIGFyZSBsaXN0ZWQuDQogICogICBUYWJsZSAxOiBJUHY2LW9ubHkg TVBMUyBHYXBzLiAgVGhlIHRhYmxlIGRvZXNuJ3QgaW5jbHVkZSBhbGwgdGhlIGdhcHMgaWRlbnRp ZmllZC4gIEZvciBleGFtcGxlLCAzLjIuMi4gKE11bHRpcG9pbnQgTERQKSBpcyBub3QgaW5jbHVk ZWQgaW4gdGhlIHRhYmxlLCBldmVuIHRob3VnaCBhIG1ham9yIGdhcCB3YXMgaWRlbnRpZmllZC4g IEluIHRoaXMgY2FzZSwgdGhlIHdvcmsgaW4gdGhlIHRhYmxlIGZvciBMRFAgbWF5IGFsc28gYWRk cmVzcyB0aGUgZ2FwIGluIG1MRFAsIGJ1dCB0aGF0IGlzIG5vdCBwb2ludGVkIG91dCBpbiB0aGUg dGFibGUuLiAgSW4gc2hvcnQsIHRoZSB0YWJsZSBpcyBub3QgY29tcGxldGUuDQogICogICBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucy4gIFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBpbiBjdXJyZW50IHNwZWNpZmljYXRpb25zLi5idXQgaXQgbGVhdmVzIG91 dCBtZW50aW9uIG9mIHRoZSBmYWN0IHRoYXQgbmV3IHNwZWNpZmljYXRpb25zICh0byBjbG9zZSB0 aGUgZ2Fwcykgc2hvdWxkIChNVVNUID8pIGNvbnNpZGVyIHRoZSBlZmZlY3Qgb2YgSVB2Ni4NCg0K Tml0czoNCg0KICAqICAgU2VjdGlvbiAyIChVc2UgQ2FzZSk6ICBzL2F0IGxlYXN0IG9uZS9vbmUg KGdlbmVyYWwpDQogICogICBTZWN0aW9uIDMgKEdhcCBBbmFseXNpcykuICBZb3Ugd3JvdGU6ICJU aGlzIGdhcCBhbmFseXNpcyBhaW1zIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24sICJ3aGF0IGJyZWFr cyB3aGVuIG9uZSBhdHRlbXB0cyB0byB1c2UgTVBMUyBmZWF0dXJlcyBvbiBhIG5ldHdvcmsgb2Yg SVB2Ni1vbmx5IGRldmljZXM/IiAgV2hpbGUgSSB1bmRlcnN0YW5kIHdoYXQgeW91J3JlIGFza2lu ZywgaW4gcmVhbGl0eSB5b3UncmUgdHJ5aW5nIHRvIGFuc3dlciAid2hhdCBkb2Vzbid0IHdvcmsu LiIuICBCcmVha2luZyBpbXBsaWVzIHRoYXQgaXQgbWF5IHdvcmsgZm9yIGEgd2hpbGUgYW5kIHRo ZW4gc3RvcCBkb2luZyBzby4NCiAgKiAgIFNlY3Rpb24gMy4xIChNUExTIERhdGEgUGxhbmUpOiAg cy9wcmVjZWVkL3ByZWNlZGUNCiAgKiAgIDMuMi4yLiAoTXVsdGlwb2ludCBMRFApICBBIHJlZmVy ZW5jZSBiYWNrIHRvIHRoZSBMRFAgc2VjdGlvbiB3b3VsZCBiZSBuaWNlIGluIHBvaW50IDEuDQog ICogICAzLjIuMi4gKE11bHRpcG9pbnQgTERQKSAtIFBvaW50IDIuICBzL2xvb2t1cCBhZ2FpbnN0 IHJvb3QgYWRkcmVzcy9sb29rdXAgYWdhaW5zdCB0aGUgcm9vdCBhZGRyZXNzDQogICogICAzLjIu Mi4gKE11bHRpcG9pbnQgTERQKSBzL3Rocm91Z2ggdGhlIHByb2NlZHVyZXMgc2ltaWxhciB0byBS RkM2NTEyL3Rocm91Z2ggcHJvY2VkdXJlcyBzaW1pbGFyIHRvIFJGQzY1MTIgICAgQlRXLCB0aGUg bGFzdCBzZW50ZW5jZSBpbiB0aGlzIHNhbWUgcGFyYWdyYXBoIHNlZW1zIHJlZHVuZGFudCB0byBt ZS4NCiAgKiAgIDMuMi4zLiAoUlNWUC0gVEUpICBzL3Byb2NlZHVyZXMgJmVuaGFuY2VtZW50cy9w cm9jZWR1cmVzIGFuZCBlbmhhbmNlbWVudHMNCiAgKiAgIDMuMy4yLiAoTDNWUE4pICAgVGhlIGdh cCBzZWN0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgdGV4dDogIkRpc2N1c3NlZCBpbiBmdXJ0 aGVyIGRldGFpbCBiZWxvdyIuICBJdCB3b3VsZCBiZSBuaWNlIHRvIGhhdmUgYW4gYWN0dWFsIHJl ZmVyZW5jZSB0byB0aGUgc2VjdGlvbiBpbnN0ZWFkIG9mIHRoZSB0ZXh0Lg0KICAqICAgRXZlbiB0 aG91Z2ggc2VjdGlvbnMgMy4zLjIuMSBhbmQgMy4zLjIuMiBhcmUgc3Vic2VjdGlvbnMgb2YgMy4z LjIsIHdpdGggc28gbWFueSBzY2VuYXJpb3MgYmVpbmcgY292ZXJlZCwgaXQgZ2V0cyBoYXJkIHRv IGtlZXAgdHJhY2sgb2Ygd2hlcmUgc29tZXRoaW5nIHdhcyBkZXNjcmliZWQuICBJdCB3b3VsZCBi ZSB2ZXJ5IG5pY2UgdG8gaW5jbHVkZSByZWZlcmVuY2VzIHRvIHdoZXJlICJ1c2UgY2FzZSAjMiIg d2FzIGRlZmluZWQgaW4gc2FjIG9mIHRob3NlIHN1YnNlY3Rpb25zLg0KICAqICAgMy4zLjIuNC4g KE5HLU1WUE4pICBzL292ZXIgTVBMUyBWUE4gYmFja2JvbmUvb3ZlciBhbiBNUExTIFZQTiBiYWNr Ym9uZQ0KICAqICAgMy4zLjIuNC4yLiAoUC1UdW5uZWwgSW5zdGFudGlhdGlvbikNCiAgICAgKiAg ICIuIC4gLmNvdmVyZWQgaW4gcHJldmlvdXMgc2VjdGlvbnMiLiAgUmVmZXJlbmNlcyBwbGVhc2Uu DQogICAgICogICAiUElNIFRyZWUgYW5kIEluZ3Jlc3MgUmVwbGljYXRpb24gYXJlIG91dCBvZiB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4uIiBiZWNhdXNlLi4gIEVpdGhlciBleHBsYWluIHdo eSBvciByZW1vdmUgdGhlbSBmcm9tIHRoZSBsaXN0IHJpZ2h0IGJlZm9yZS4NCiAgKiAgIDMuNC4x LiAoRXh0ZW5kZWQgSUNNUCkgIHMvc3VwcG9ydGVkIGJ5IElQdjYtb25seSBpbmZyYXN0cnVjdHVy ZS9zdXBwb3J0ZWQgYnkgYW4gSVB2Ni1vbmx5IGluZnJhc3RydWN0dXJlDQogICoNCjMuNC4yLiAo TFNQIFBpbmcpICBzL0xTUCBQaW5nIHBhY2tldHMgYXJlIFVEUCBwYWNrZXRzIG92ZXIgYm90aCBJ UHY0IGFuZCBJUHY2L0xTUCBQaW5nIHBhY2tldHMgYXJlIFVEUCBwYWNrZXRzIG92ZXIgZWl0aGVy IElQdjQgb3IgSVB2Ng0KICAqICAgVGhlcmUgaXMgc29tZSB1bmV2ZW4gdHJlYXRtZW50IGluIHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgc3VwcG9ydC9nYXBzLiAgSXQgd291bGQgYmUgbmljZSB0byBw cm92aWRlIHRoZSBzYW1lIGxldmVsIG9mIGRldGFpbCBldmVyeXdoZXJlIChpZiBuZWVkZWQpLiAg Rm9yIGV4YW1wbGUsIDMuMi4zLjIgKFJTVlAtVEUtUDJNUCkgcGxhaW5seSBtZW50aW9ucyB0aGF0 IFJGQzQ4NzUgY292ZXJzIHRoZSBzdXBwb3J0IGZvciBJUHY2Li53aGlsZSAzLjQuMyAoQkZEIE9B TSkgbWVudGlvbnMgd2hlcmUgSVB2NiBzdXBwb3J0IHVzIGRlZmluZWQgYnV0IGl0IGFsc28gcG9p bnRzIHRvIHRoZSBzcGVjaWZpYyBzZWN0aW9ucy4gIElNSE8sIHRoZSBhZGRpdGlvbmFsIGRldGFp bCBpcyBub3QgbmVlZGVkICh1bmxlc3MgdmVyeSBzcGVjaWZpYyBwb2ludHMgbmVlZCB0byBiZSBt YWRlKS4NCg== --_000_D0069E2E65909aretanaciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <80AEC4F367601B439C17C3F4EE8ABFA5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxwIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KSGkhPC9wPg0KPHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQpJIGhh dmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3Ig dGhpcyBkcmFmdC4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCBy b3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2ggSUVU RiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgc29tZXRpbWVzIG9uIHNwZWNpYWwgcmVx dWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlDQogcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5j ZSB0byB0aGUgUm91dGluZyBBRHMuICZuYnNwO0ZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRo ZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8YSBjbGFzcz0iZXh0LWxpbmsiIGhy ZWY9Imh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXIi PjxzcGFuIGNsYXNzPSJpY29uIj7igIs8L3NwYW4+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv YXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpcjwvYT4NCjwvcD4NCjxwIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KQWx0aG91Z2ggdGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVz ZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNv bnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMg dGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNj dXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFmdC4NCjwvcD4NCjxwIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyAiPg0KRG9jdW1lbnQ6Jm5ic3A7ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAt MDEgKEdhcCBBbmFseXNpcyBmb3IgT3BlcmF0aW5nIElQdjYtb25seSBNUExTIE5ldHdvcmtzKTxi cj4NClJldmlld2VyOiBBbHZhcm8gUmV0YW5hPGJyPg0KUmV2aWV3IERhdGU6IEF1Zy4gNSwgMjAx NC48YnI+DQpJRVRGIExDIEVuZCBEYXRlOiBBdWcuIDgsIDIwMTQuPGJyPg0KSW50ZW5kZWQgU3Rh dHVzOiZuYnNwO0luZm9ybWF0aW9uYWw8L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4N CjxzdHJvbmc+U3VtbWFyeTo8L3N0cm9uZz4gPGJyPg0KSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJl Zm9yZSBwdWJsaWNhdGlvbi48L3A+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzdHJv bmc+Q29tbWVudHM6PC9zdHJvbmc+PC9wPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4N ClRoaXMgZHJhZnQgY292ZXJzIGEgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ3kgdG8gZmluZCBn YXBzIHRoYXQgbWF5IHByZXZlbnQgdGhlIHVzZSBvZiBJUHY2LW9ubHkgTVBMUyBuZXR3b3Jrcy4g Jm5ic3A7SXQgZG9lcyBzbyBpbiBhIGNvbmNpc2UgYW5kIGNsZWFyIGZvcm0sIGFuIGVhc3kgcmVh ZC4gJm5ic3A7SSBiZWxpZXZlIHRoYXQgdGhpcyB3b3JrIGlzIHZlcnkgdmFsdWFibGUgZ2l2ZW4s IGFzIHRoZSBkcmFmdCBwdXRzIGl0LCB0aGF0ICZxdW90O0lQdjYgaXMgYW4NCiBpbnRlZ3JhbCBw YXJ0IG9mIG1vZGVybiBuZXR3b3JrIGRlcGxveW1lbnRzJnF1b3Q7LjwvZGl2Pg0KPGRpdiBzdHls ZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsgIj4NCkkgZG8gaGF2ZSBhIGNvdXBsZSBvZiBoaWdoLWxldmVsIGl0ZW1zIEkgd2FudCB0 byBicmluZyB1cC4gJm5ic3A7QmVjYXVzZSBJIGFzc3VtZSB0aGF0IHRoZXNlIG1heSBoYXZlIGFs cmVhZHkgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIGFwcHJvcHJpYXRlIFdHKHMpIEknbSBub3QgbGlz dGluZyB0aGVtIGFzIG1ham9yIGlzc3VlcywgYW5kIHdpbGwgZGVmZXIgdG8gd2hhdCB0aGUgY29u c2Vuc3VzIGhhcyBiZWVuIHNvIGZhci48L2Rpdj4NCjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Ij4NCjxsaT5XaHkgZG8gd2UgbmVlZCB0byBwdWJsaXNoIHRoaXMgZG9jdW1lbnQ/ICZuYnNwO0Fz IEkgc2FpZCBhYm92ZSwgSSBiZWxpZXZlIHRoZSB3b3JrIGlzIHZhbHVhYmxlLCBidXQgaXQgY2Fw dHVyZXMgdGhlIHN0YXRlIGluIHRpbWUgKHRvZGF5ISkgb2YgdGhlIGdhcHMg4oCUIGl0IHBvaW50 cyB0byB3b3JrIHRoYXQgYWxyZWFkeSBzb2x2ZWQgYSBwb3RlbnRpYWwgZ2FwLCBvciBpcyBpbiB0 aGUgcHJvY2VzcyBvZiBzb2x2aW5nIHRoZW0uICZuYnNwO0Egc2lnbmlmaWNhbnQNCiBwb3J0aW9u IG9mIHRoZSBnYXBzIGFyZSBhbHJlYWR5IGJlaW5nIGFkZHJlc3NlZC4gJm5ic3A7R2l2ZW4gdGhl IGltcG9ydGFuY2Ugb2YgSVB2NiwgaWYgcHVibGlzaGVkLCBzb29uIHRoaXMgZG9jdW1lbnQgd2ls bCBoYXZlIHRvIGJlIHVwZGF0ZWQgdG8gc2F5ICZxdW90O25vdGhpbmcgYnJlYWtzJnF1b3Q7LiAm bmJzcDtBZ2FpbiwgdGhlIHdvcmsgaXMgaW1wb3J0YW50LCBidXQgaXQgbWF5IGJlIGJldHRlciBz dWl0ZWQgdG8gYmUgYSAmcXVvdDtsaXZpbmcgZG9jdW1lbnQmcXVvdDsgYXMgYSBndWlkZQ0KIGZv ciB3aGF0IHN0aWxsIG5lZWRzIHRvIGJlIGFkZHJlc3NlZC4gJm5ic3A7SWYgaXQgaXMgdG8gYmUg cHVibGlzaGVkLCBJIHdvdWxkIHN1Z2dlc3QgYXZvaWRpbmcgbGlua3MgdG8gd29yayBpbiBwcm9n cmVzcywgYnV0IGxpbWl0aW5nIHRoZSBjb250ZW50IHRvIGlkZW50aWZ5aW5nIHRoZSBnYXBzLi5h bmQgdGhlbiBsZXR0aW5nIHRoZSBzb2x1dGlvbiBkcmFmdHMvUkZDcyBwb2ludCBiYWNrIHRvIHRo aXMgZG9jdW1lbnQuLiAmbmJzcDsoYWxhIHJlcXVpcmVtZW50cw0KIC0mZ3Q7IHNvbHV0aW9uKTwv bGk+PGxpPkl0IGlzIGludGVyZXN0aW5nIHRvIG1lIHRoYXQgdGhpcyBkcmFmdCBjYW1lIHRocm91 Z2ggdGhlIG1wbHMgV0csIGFuZCBub3Qgb25lIG9mIHRoZSBvcGVyYXRpb25zLWZvY3VzZWQgZ3Jv dXBzLi53aGljaCBwcmVzdW1hYmx5IHdvdWxkIGJlIGluIGEgYmV0dGVyIHBvc2l0aW9uIHRvIGV2 YWx1YXRlIHRoZSBuZWVkcyBkZXNjcmliZWQuICZuYnNwO0dpdmVuIHRoYXQgdGhlIGRvY3VtZW50 IGlzIGFscmVhZHkgaW4gV0cgTGFzdCBDYWxsLCBJJ20gYXNzdW1pbmcNCiB0aGF0IHRoZSBhbGln bm1lbnQgaGFzIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgYW5kIHRoYXQgcHJvcGVyIGNyb3NzLVdH IHJldmlld3MgaGF2ZSBvY2N1cnJlZC48L2xpPjwvb2w+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHN0 cm9uZz5NYWpvciBJc3N1ZXM6PC9zdHJvbmc+PC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyAiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KTm8g bWFqb3IgaXNzdWVzIGZvdW5kLjwvZGl2Pg0KPHAgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8 c3Ryb25nPk1pbm9yIElzc3Vlczo8L3N0cm9uZz4gPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KU29tZSB0ZXJtaW5vbG9neSB3YXMgbm90IGV4cGFuZGVkIGJlZm9yZS93 aGVuIGl0IHdhcyBmaXJzdCB1c2VkOiB3ZSBhbGwga25vdyB3aGF0IE1QTFMgaXMsIGJ1dCBvdGhl cnMgbGlrZSBMU1IsIExFUiwgRkVDLCBMMlZQTiwgRVZQTiwgTkctbVZQTiwgZXRjLiBzaG91bGQg YmUgZXhwYW5kZWQuPC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQpTZWN0aW9uIDMu MSAoTVBMUyBEYXRhIFBsYW5lKTogJnF1b3Q7SW4gdGhlIGNhc2Ugd2hlcmUgYW4gSVB2NCBwcmVm aXggaXMgcmVzb2x2ZWQgb3ZlciBhbiBJUHY2IExTUCwgYW4mbmJzcDtJUHY2IEV4cGxpY2l0IE51 bGwgbGFiZWwgY2Fubm90IGltbWVkaWF0ZWx5IHByZWNlZWQgYW4gSVB2NCBwYWNrZXQuJnF1b3Q7 ICZuYnNwO0lzIHRoZXJlIGEgcmVmZXJlbmNlIGZvciB0aGlzIHN0YXRlbWVudCBvciBpcyB0aGlz IGEgcmVxdWlyZW1lbnQgdG8gZmlsbCBpbiB0aGUgZ2FwPyAmbmJzcDtJZg0KIGl0IGlzIGEgcmVx dWlyZW1lbnQsIGRvIHdlIG5lZWQgdG8gYWRkIDIxMTkgbGFuZ3VhZ2U/PC9saT48bGkgc3R5bGU9 ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDE0cHg7ICI+DQpXaGVuIGEgZ2FwIGV4aXN0cywgeW91IGNsYXNzaWZ5IGl0IGFz ICZxdW90O21ham9yJnF1b3Q7IG9yICZxdW90O21pbm9yJnF1b3Q7LiAmbmJzcDtXaGF0IGlzIHRo ZSBjcml0ZXJpYSB1c2VkPyAmbmJzcDtJIHdvdWxkIGltYWdpbmUgdGhhdCBnaXZlbiB0aGF0IGl0 IGlzIGEgZ2FwIGFuYWx5c2lzLCB0aGUgb2JqZWN0aXZlIGlzIHRvIHBvaW50IG91dCB0aGUgbmVl ZHMsIG5vdCBjaGFyYWN0ZXJpemUgdGhlbSAoaWYgSSBuZWVkIGEgJnF1b3Q7bWlub3ImcXVvdDsg Z2FwIHRvIGJlIGZpbGxlZCBpbiBvcmRlciBmb3IgbXkNCiBuZXR3b3JrIGRlcGxveW1lbnQgdG8g b3BlcmF0ZSwgaXQgYmVjb21lcyAmcXVvdDttYWpvciZxdW90OyB0byBtZSkuPC9saT48bGk+PGZv bnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPlRoZSBpbnRyb2R1Y3Rpb24gdG8gdGhlIGRyYWZ0 IHRhbGtzIGFib3V0ICZxdW90OzwvZm9udD5nYXBzIHRoYXQgbXVzdCBiZSBhZGRyZXNzZWQgaW4g b3JkZXIgdG8gYWxsb3cgTVBMUy1yZWxhdGVkDQogcHJvdG9jb2xzPGZvbnQgZmFjZT0iQ2FsaWJy aSxzYW5zLXNlcmlmIj4mbmJzcDthbmQgYXBwbGljYXRpb25zIHRvIGJlIHVzZWQgd2l0aCBJUHY2 LW9ubHkgbmV0d29ya3MmcXVvdDsgKCZxdW90O0lQdjYtb25seSAobm8gSVB2NCZuYnNwOzwvZm9u dD48L2ZvbnQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAi PnByb3Zpc2lvbmVkIG9uIHRoZSBkZXZpY2UpJnF1b3Q7KTwvc3Bhbj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+LA0KIHdoaWNo IGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgbm8gSVB2NCBpcyBwcmVzZW50IGluIHRoZSBuZXR3 b3JrIGF0IGFsbC4gJm5ic3A7Jm5ic3A7SG93ZXZlciwgc2V2ZXJhbCBnYXBzIGFyZSBpZGVudGlm aWVkIHRoYXQgb2NjdXIgaW4gJnF1b3Q7bWl4ZWQmcXVvdDsgbmV0d29ya3MsIHdoZXJlIGlzbGFu ZHMgb2YgSVB2NC9JUHY2IGV4aXN0LiAmbmJzcDtJIHdvdWxkIHN1Z2dlc3QgY2xhcmlmeWluZyB0 aGUgc2NvcGUgb2YgdGhlJm5ic3A7ZG9jdW1lbnQgaW4gdGhlIGludHJvZHVjdGlvbi4gJm5ic3A7 U29tZQ0KIG9mIHRoZSBwbGFjZXMgd2hlcmUgdGhlc2Ugc2NlbmFyaW9zIGFyZSBkaXNjdXNzZWQg aW5jbHVkZTogJm5ic3A7PC9mb250PjMuMi4yLiAoTXVsdGlwb2ludCBMRFApLCZuYnNwOzwvZm9u dD48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHN0eWxlPSJmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPjMuMy4yLiAoTDNWUE4pLCAmbmJz cDszLjQuMS4gKEV4dGVuZGVkIElDTVApIGFuZCZuYnNwOzMuNC4yLiAoTFNQIFBpbmcpLjwvZm9u dD48L2xpPjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPjMuMy4xLjEuIChF VlBOKSAmbmJzcDtJZiB0aGUgRVZQTiB3b3JrIGlzIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhlIGRv Y3VtZW50LCB0aGVuIHRha2UgaXQgb3V0LiAmbmJzcDtBbm90aGVyIG9wdGlvbiBtYXkgYmUgdG8g dGFsayBhYm91dCBhbnkgZ2FwcyBpbiB0aGUgY3VycmVudCB3b3JrLiAmbmJzcDtTYW1lIGNvbW1l bnQgZm9yIHNlY3Rpb24mbmJzcDszLjMuMi40LjMuDQogKFBFLVBFIE11bHRpY2FzdCBSb3V0aW5n IFByb3RvY29sKS48L3NwYW4+PC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7ICI+My4zLjIuIChMM1ZQTikgJm5ic3A7dGhl IHRleHQgc2F5cyB0aGF0IHRoZSBnYXBzIGluIFJGQzQzNjQgKG5vJm5ic3A7VlBOLUlQdjYgYWRk cmVzcyBhbmQgYSZuYnNwOzEyOCBiaXQgbmV4dC1ob3ApIGhhdmUgYmVlbg0KIGFkZHJlc3NlZCBp biBSRkMgNDY1OSwgYnV0IGl0IHRoZW4gaWRlbnRpZmllcyB0aGUgZ2FwIGFuZCBzYXlzIHRoYXQg JnF1b3Q7UkZDNDM2NCBtdXN0IGJlIHVwZGF0ZWQmcXVvdDsuICZuYnNwO1doYXQgd291bGQgdGhh dCB1cGRhdGUgYmU/PC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyAiPlNlY3Rpb25zIDMuMy4yLjQuMy4gKFBF LVBFIE11bHRpY2FzdCBSb3V0aW5nIFByb3RvY29sKSwmbmJzcDs8L3NwYW4+PGZvbnQgZmFjZT0i Q2FsaWJyaSxzYW5zLXNlcmlmIj4zLjMuMy4gKE1QTFMtVFApDQogYW5kJm5ic3A7My40LjUuIChN UExTLVRQIE9BTSkmbmJzcDthcmUgaW5jbHVkZWQsIGJ1dCBvdXQgb2Ygc2NvcGUuLiAmbmJzcDtT aG91bGQgdGhleSBiZSByZW1vdmVkPyAmbmJzcDtJZiBub3QsIHRoZW4gYSBzaG9ydCBqdXN0aWZp Y2F0aW9uIGluIHRoZSB0ZXh0IHdvdWxkIGJlIG5pY2UuPC9mb250PjwvbGk+PGxpIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyAiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4zLjQuIChN UExTIE9BTSkgJm5ic3A7VGhpcyBzZW50ZW5jZSAmcXVvdDs8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPkFsbCBvZiB0aGVzZSZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+bWVjaGFu aXNtcyB3b3JrIGluIHB1cmUgSVB2NiBlbnZpcm9ubWVudHMuJnF1b3Q7IGdpdmVzIHRoZSBpbXBy ZXNzaW9uIHRoYXQNCiBhbGwgdGhlIG1lY2hhbmlzbXMgd29yayBjb3JyZWN0bHkgYW5kIHRoYXQg dGhlcmUgYXJlIG5vIGdhcHMuLmJ1dCB0aGVuIHNldmVyYWwgZ2FwcyBhcmUgbGlzdGVkLjwvc3Bh bj48L2xpPjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiI+VGFibGUgMTogSVB2Ni1vbmx5IE1QTFMgR2Fwcy4gJm5ic3A7VGhlIHRhYmxl IGRvZXNuJ3QgaW5jbHVkZSBhbGwgdGhlIGdhcHMgaWRlbnRpZmllZC4gJm5ic3A7Rm9yIGV4YW1w bGUsJm5ic3A7PC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+My4yLjIuIChN dWx0aXBvaW50IExEUCkgaXMgbm90IGluY2x1ZGVkIGluIHRoZSB0YWJsZSwgZXZlbiB0aG91Z2gg YSBtYWpvciBnYXAgd2FzIGlkZW50aWZpZWQuDQogJm5ic3A7SW4gdGhpcyBjYXNlLCB0aGUgd29y ayBpbiB0aGUgdGFibGUgZm9yIExEUCBtYXkgYWxzbyBhZGRyZXNzIHRoZSBnYXAgaW4gbUxEUCwg YnV0IHRoYXQgaXMgbm90IHBvaW50ZWQgb3V0IGluIHRoZSB0YWJsZS4uICZuYnNwO0luIHNob3J0 LCB0aGUgdGFibGUgaXMgbm90Jm5ic3A7Y29tcGxldGUuPC9mb250PjwvbGk+PGxpIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyAiPg0KPGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5TZWN1cml0 eSBDb25zaWRlcmF0aW9ucy4gJm5ic3A7VGhpcyBzZWN0aW9uIHRhbGtzIGFib3V0IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIGluIGN1cnJlbnQgc3BlY2lmaWNhdGlvbnMuLmJ1dCBpdCBsZWF2ZXMg b3V0IG1lbnRpb24gb2YgdGhlIGZhY3QgdGhhdCBuZXcgc3BlY2lmaWNhdGlvbnMgKHRvIGNsb3Nl IHRoZSBnYXBzKSBzaG91bGQgKE1VU1QgPykgY29uc2lkZXIgdGhlIGVmZmVjdCBvZiBJUHY2Ljwv Zm9udD48L2xpPjwvdWw+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzdHJvbmc+Tml0 czo8L3N0cm9uZz4gPC9wPg0KPHVsIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KPGxpIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxNHB4OyAiPg0KU2VjdGlvbiAyIChVc2UgQ2FzZSk6ICZuYnNwO3MvYXQgbGVh c3Qgb25lL29uZSAoZ2VuZXJhbCkgJm5ic3A7Jm5ic3A7PC9saT48bGkgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7ICI+DQpTZWN0aW9uIDMgKEdhcCBBbmFseXNpcykuICZuYnNwO1lvdSB3cm90ZTogJnF1 b3Q7VGhpcyBnYXAgYW5hbHlzaXMgYWltcyB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uLCAmcXVvdDt3 aGF0IGJyZWFrcyB3aGVuIG9uZSZuYnNwO2F0dGVtcHRzIHRvIHVzZSBNUExTIGZlYXR1cmVzIG9u IGEgbmV0d29yayBvZiBJUHY2LW9ubHkgZGV2aWNlcz8mcXVvdDsgJm5ic3A7V2hpbGUgSSB1bmRl cnN0YW5kIHdoYXQgeW91J3JlIGFza2luZywgaW4gcmVhbGl0eSB5b3UncmUgdHJ5aW5nIHRvIGFu c3dlciAmcXVvdDt3aGF0IGRvZXNuJ3QNCiB3b3JrLi4mcXVvdDsuICZuYnNwO0JyZWFraW5nIGlt cGxpZXMgdGhhdCBpdCBtYXkgd29yayBmb3IgYSB3aGlsZSBhbmQgdGhlbiBzdG9wIGRvaW5nIHNv LjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0KU2VjdGlvbiAzLjEgKE1QTFMgRGF0 YSBQbGFuZSk6Jm5ic3A7IHMvcHJlY2VlZC9wcmVjZWRlPC9saT48bGkgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7ICI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjMuMi4yLiAoTXVsdGlw b2ludCBMRFApICZuYnNwO0EgcmVmZXJlbmNlIGJhY2sgdG8gdGhlIExEUCBzZWN0aW9uIHdvdWxk IGJlIG5pY2UgaW4gcG9pbnQgMS48L2ZvbnQ+PC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7 ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07ICI+My4yLjIuIChNdWx0aXBvaW50 IExEUCkmbmJzcDstIFBvaW50IDIuICZuYnNwO3M8L3NwYW4+L2xvb2t1cCBhZ2FpbnN0IHJvb3Qg YWRkcmVzcy9sb29rdXAgYWdhaW5zdCB0aGUgcm9vdCBhZGRyZXNzJm5ic3A7PC9saT48bGkgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7ICI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiBtZWRpdW07ICI+ My4yLjIuIChNdWx0aXBvaW50IExEUCk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogbWVk aXVtOyAiPiZuYnNwO3MvPC9zcGFuPnRocm91Z2ggdGhlJm5ic3A7cHJvY2VkdXJlcyBzaW1pbGFy IHRvIFJGQzY1MTIvdGhyb3VnaCZuYnNwO3Byb2NlZHVyZXMgc2ltaWxhciB0byBSRkM2NTEyICZu YnNwOyAmbmJzcDtCVFcsIHRoZSBsYXN0IHNlbnRlbmNlIGluIHRoaXMgc2FtZSBwYXJhZ3JhcGgg c2VlbXMgcmVkdW5kYW50IHRvIG1lLjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0K PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4zLjIuMy4gKFJTVlAtIFRFKSAmbmJzcDtz LzwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ cHJvY2VkdXJlcyAmYW1wO2VuaGFuY2VtZW50cy88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyAiPnByb2NlZHVyZXMgYW5kJm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5lbmhhbmNlbWVu dHM8L3NwYW4+PC9saT48bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPjMuMy4yLiAoTDNWUE4pICZuYnNwOyBUaGUgZ2FwIHNlY3Rpb24g aW5jbHVkZXMgdGhlIGZvbGxvd2luZyB0ZXh0OiAmcXVvdDs8L2ZvbnQ+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+RGlzY3Vz c2VkIGluIGZ1cnRoZXImbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+ZGV0YWlsDQogYmVsb3cmcXVvdDsu ICZuYnNwO0l0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBhbiBhY3R1YWwgcmVmZXJlbmNlIHRvIHRo ZSBzZWN0aW9uIGluc3RlYWQgb2YgdGhlIHRleHQuPC9zcGFuPjwvbGk+PGxpIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyAiPkV2ZW4g dGhvdWdoIHNlY3Rpb25zIDMuMy4yLjEgYW5kIDMuMy4yLjIgYXJlIHN1YnNlY3Rpb25zIG9mIDMu My4yLCB3aXRoIHNvIG1hbnkgc2NlbmFyaW9zIGJlaW5nIGNvdmVyZWQsIGl0DQogZ2V0cyBoYXJk IHRvIGtlZXAgdHJhY2sgb2Ygd2hlcmUgc29tZXRoaW5nIHdhcyZuYnNwOzwvc3Bhbj48Zm9udCBm YWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPmRlc2NyaWJlZC4gJm5ic3A7SXQgd291bGQgYmUgdmVy eSBuaWNlIHRvIGluY2x1ZGUgcmVmZXJlbmNlcyB0byB3aGVyZSAmcXVvdDt1c2UgY2FzZSAjMiZx dW90OyB3YXMgZGVmaW5lZCBpbiZuYnNwO3NhYyZuYnNwO29mIHRob3NlIHN1YnNlY3Rpb25zLjwv Zm9udD48L2xpPjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+My4zLjIuNC4gKE5HLU1WUE4pICZuYnNwO3MvPC9mb250Pjxmb250IGZh Y2U9IkNhbGlicmksc2Fucy1zZXJpZiI+b3ZlciBNUExTIFZQTiBiYWNrYm9uZS9vdmVyIGFuIE1Q TFMgVlBOIGJhY2tib25lPC9mb250PjwvbGk+PGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyAiPg0K My4zLjIuNC4yLiAoUC1UdW5uZWwgSW5zdGFudGlhdGlvbikgJm5ic3A7DQo8dWwgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7ICI+DQo8bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4mcXVv dDsuIC4gLjwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7ICI+Y292ZXJlZCZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7ICI+aW4gcHJldmlvdXMgc2VjdGlvbnMmcXVvdDsuICZuYnNwO1JlZmVy ZW5jZXMgcGxlYXNlLjwvc3Bhbj48L2xpPjxsaT48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7ICI+JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgIj5QSU0gVHJlZSBhbmQgSW5ncmVzcyBSZXBsaWNhdGlvbiBhcmUgb3V0IG9m IHRoZQ0KIHNjb3BlIG9mIHRoaXM8L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij4mbmJzcDtkb2N1bWVudC4uJnF1b3Q7Jm5ic3A7YmVjYXVzZS4uICZuYnNwO0VpdGhlciBleHBs YWluIHdoeSBvciByZW1vdmUgdGhlbSBmcm9tIHRoZSBsaXN0IHJpZ2h0IGJlZm9yZS48L2ZvbnQ+ PC9saT48L3VsPg0KPC9saT48bGk+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj4zLjQu MS4gKEV4dGVuZGVkIElDTVApICZuYnNwO3Mvc3VwcG9ydGVkIGJ5Jm5ic3A7SVB2Ni1vbmx5IGlu ZnJhc3RydWN0dXJlL3N1cHBvcnRlZCBieSBhbiZuYnNwO0lQdjYtb25seSBpbmZyYXN0cnVjdHVy ZTwvZm9udD48L2xpPjxsaT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRpdj4z LjQuMi4gKExTUCBQaW5nKSAmbmJzcDtzL0xTUCBQaW5nIHBhY2tldHMgYXJlIFVEUCBwYWNrZXRz IG92ZXIgYm90aCBJUHY0IGFuZCZuYnNwO0lQdjYvTFNQIFBpbmcgcGFja2V0cyBhcmUgVURQIHBh Y2tldHMgb3ZlciBlaXRoZXIgSVB2NCBvciZuYnNwO0lQdjY8L2Rpdj4NCjwvZm9udD48L2xpPjxs aT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPlRoZXJlIGlzIHNvbWUgdW5ldmVuIHRy ZWF0bWVudCBpbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHN1cHBvcnQvZ2Fwcy4gJm5ic3A7SXQg d291bGQgYmUgbmljZSB0byBwcm92aWRlIHRoZSBzYW1lIGxldmVsIG9mIGRldGFpbCBldmVyeXdo ZXJlIChpZiBuZWVkZWQpLiAmbmJzcDtGb3IgZXhhbXBsZSwgMy4yLjMuMiAoPC9mb250PlJTVlAt VEUtUDJNUCkgcGxhaW5seSBtZW50aW9ucyB0aGF0IFJGQzQ4NzUNCiBjb3ZlcnMgdGhlIHN1cHBv cnQgZm9yIElQdjYuLndoaWxlIDMuNC4zIChCRkQgT0FNKSBtZW50aW9ucyB3aGVyZSBJUHY2IHN1 cHBvcnQgdXMgZGVmaW5lZCBidXQgaXQgYWxzbyBwb2ludHMgdG8gdGhlIHNwZWNpZmljIHNlY3Rp b25zLiAmbmJzcDtJTUhPLCB0aGUgYWRkaXRpb25hbCBkZXRhaWwgaXMgbm90IG5lZWRlZCAodW5s ZXNzIHZlcnkgc3BlY2lmaWMgcG9pbnRzIG5lZWQgdG8gYmUgbWFkZSkuPC9saT48L3VsPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_D0069E2E65909aretanaciscocom_-- From nobody Wed Aug 6 12:02: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 8AEE61B27D9 for ; Wed, 6 Aug 2014 12:02:26 -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 bJn5H5xNhovy for ; Wed, 6 Aug 2014 12:02:18 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0076.outbound.protection.outlook.com [213.199.154.76]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219B91A0390 for ; Wed, 6 Aug 2014 12:01:33 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB611.eurprd03.prod.outlook.com (10.242.109.28) with Microsoft SMTP Server (TLS) id 15.0.995.14; Wed, 6 Aug 2014 19:01:30 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.0995.014; Wed, 6 Aug 2014 19:01:30 +0000 From: Alexander Vainshtein To: "Kamran Raza (skraza)" , "Sami Boutros (sboutros)" Thread-Topic: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Thread-Index: Ac9tIpHty7MH85zjQlWHldfu8Tbv0Q+0+TYAAApoeoAACPLngAFW+mmAAAIXEYE= Date: Wed, 6 Aug 2014 19:01:30 +0000 Message-ID: <1407351683540.8563@ecitele.com> References: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> <005401cfac43$e76b9f10$b642dd30$@olddog.co.uk>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.202] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(48214007)(50854003)(189002)(199002)(52604005)(36304003)(252514010)(52284002)(377454003)(80022001)(85306004)(93886004)(66066001)(16236675004)(76482001)(36756003)(50986999)(19273905006)(17760045003)(46102001)(19300405004)(54356999)(76176999)(81342001)(4396001)(15202345003)(99936001)(31966008)(99396002)(19580395003)(87936001)(19580405001)(85852003)(77982001)(81542001)(92566001)(92726001)(20776003)(74662001)(74502001)(64706001)(19617315012)(18206015026)(19627595001)(105586002)(95666004)(79102001)(83322001)(83072002)(2656002)(101416001)(15975445006)(86362001)(107046002)(19625215002)(19627405001)(21056001)(106356001)(24704002)(579004)(559001)(563064011)(19607625011); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB611; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/related; boundary="_004_14073516835408563ecitelecom_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/53jTL5mHHbgFrWXLe3Sh5gbLPJQ Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , Adrian Farrel , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-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: Wed, 06 Aug 2014 19:02:26 -0000 --_004_14073516835408563ecitelecom_ Content-Type: multipart/alternative; boundary="_000_14073516835408563ecitelecom_" --_000_14073516835408563ecitelecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kamran, Sami, Lots of thanks for your cooperation. I believe that we have successfully resolved all the remaining issues at ou= r WebEx call today. I will be waiting for the next revision of the draft to formally confirm th= at. Adrian and all, It took more time than we originally planned - but we did it! Regards, Sasha ________________________________ From: Kamran Raza (skraza) Sent: Wednesday, August 6, 2014 8:56 PM To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); draft-ietf-mpls-ldp-ip-pw-ca= pability.all@tools.ietf.org; Alexander Vainshtein; rtg-ads@tools.ietf.org Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hi Adrian, We (authors) just had a webex call with Sasha to discuss/close on his comme= nts [ which we had also discussed over the email starting May ]. We all are in agreement/sync on the points that were raised during this rev= iew . Almost all, if not all, of the points/comments will be addressed by clarifying the scope of the extension in a new =93Applicability" section w= ith risk and recommendations highlighted. We will work on updating the draft and post a new rev shortly. We thank you Sasha for his detailed review and useful comments and thank yo= u for your patience. =97 Kamran and Sami From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, July 30, 2014 at 6:16 PM To: Syed Kamran Raza > Cc: "rtg-dir@ietf.org" >, "Sami Boutros (sboutros)" >, "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org<= mailto:draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>" >, 'Alexander Vainshtein' >, "rtg-ads@too= ls.ietf.org" > Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt This is very excellent. Thank you for going the extra mile to sort things o= ut. A From: Kamran Raza (skraza) [mailto:skraza@cisco.com] Sent: 30 July 2014 19:00 To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); dra= ft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander Vainshtein'; rtg-ads@= tools.ietf.org Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hi Adrian, Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to s= chedule the meeting post IETF as Sasha did not attend. We are meeting tomorrow with Sasha to clarify/converge. Thanks. Kamran Raza TECHNICAL LEADER.ENGINEERING Product Development skraza@cisco.com Phone: +1 613 254 4520 Cisco.com Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J = 2T3. Phone: 416-306-7000; Fax: 416-306-7099. Preferences - Unsubs= cribe =96 Privacy<= http://www.cisco.com/web/siteassets/legal/privacy.html> [Image removed by sender.] Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, July 30, 2014 at 9:02 AM To: Syed Kamran Raza > Cc: "rtg-dir@ietf.org" >, "Sami Boutros (sboutros)" >, "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org<= mailto:draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>" >, 'Alexander Vainshtein' >, "rtg-ads@too= ls.ietf.org" > Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Kamran, Thanks for responding to the question in the GenArt review. Do you have any responses to Sasha's review (copied below)? cheers, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 11 May 2014 15:09 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-c= apability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros= (sboutros@cisco.com) Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts 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, please see http://www.i= etf.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-ip-pw-capability-07.txt Reviewer: Alexander (=93Sasha=94) Vainshtein Review date: 11-May-14 IETF LC End Date: 12-May-14 Intended status: Standards Track Summary: I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors. These concerns mainly deal with potential negative impact of the mechanisms= (introduced in the draft) for disabling =93non-negotiable=94 capabilities = of LDP sessions with the techniques that could dynamically change the stat= e of =93interest=94 in these capabilities for a given LDP session. Some of these mechanisms are already standardized by the IETF, e.g., L2VP= N auto-discovery (RFC 6074) and dynami= c placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others - LDP FRR using remote loop-free adjacencies (draft-ie= tf-rtgwg-remote-lfa)- are in advanced stages of the IETF process. I must admit that I did not follow closely the discussion of the draft in = question in the MPLS WG; so it may well be that some of my concerns have be= en already raised, considered and found not relevant. I also do not know if the draft has ever been discussed in the PWE3, L2VPN = and RTG WGs. One possible way to address these concerns would be by adding an Applicabil= ity Statement section to the draft and discussing potentially problematic c= ombinations of mechanisms there. I have discussed this option with the authors and, to the best of my unders= tanding, they have in general agreed to add such a section to the next revi= sion of the draft. General comments: To the best of my understanding the sole purpose of the draft is preventio= n of =93 wasteful=94 distribution of state dealing with two non-negotiable = classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes = defined in RFC 5036) and PW FECs (i.e. = PW Id FEC and Generalized PW Id FEC defined in RFC 4447) to LDP peers that are =93not interested=92 in this state.= Such unnecessary distribution would result in unnecessary waste of resourc= es (memory and/or CPU cycles) and hence should be avoided. The draft mentions that: To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments. The draft, however, does not mention that filtering policies provide much f= iner granularity of control over distribution of labels than that supported= by the mechanism introduced in the draft. E.g., in a scenario when LDP is supposed to set up only =93tunnel LSPs=94 b= etween PEs for L2 and L3 VPN applications, an appropriate policy allow dist= ribution of the just the FECs associated with Router IDs of the PEs but not= , say FECs associated with the subnets of their core-facing interfaces. IMH= O and FWIW this means that support of the mechanism defined in the draft wo= uld not eliminate the need for the filtering policies. I have discussed this point with the authors and they have agreed to add so= me clarifying text. I have also failed to understand how distribution of PW FECs could be waste= ful. Section 5.3.3 =93Signaling Procedures=94 of RFC 4447 explicitly states that: In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). My reading of the quoted text is that PW FECs are only distributed across t= argeted LDP sessions with the known Remote PEs for specific PWs. AFAIK, this is what actually happens in most existing implementations of PW= signaling with RFC 4447. What=92s more, many implementations, when required to set up a PW with a sp= ecific remote PE, check for existence of a targeted LDP session with this P= E, and set it up implicitly if it does not exist; then they distribute PW F= EC-to-label binding via this session only. Implicit targeted LDP sessions a= re also implicitly torn down when the last PW between the given pair of PE= s is torn down. I have discussed this point with the authors, but, as of the moment of writ= ing this review, we did not yet reach full agreement on it. Readability of the draft: Initially I have failed to understand the following text fragment in the dr= aft (the problematic statements are marked with italics): For Prefix-LSPs application type, the non-interesting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings as a non-interesting state and allows the advertisement of IP Address bindings to facilitate other LDP applications (such as mLDP) that depend on learning of peer addresses over an LDP session for their correct operation. After discussing this point with the authors I=92ve understood that they re= fer to exchange of the LSR addresses in the Address and Address Withdraw me= ssages that is required for mapping Next Hop IP addresses computed by the I= GP to Next Hop LSR. While initial misunderstanding may be specific to me, = I have suggested to the authors to clarify this point with explicit referen= ces to specific LDP messages and sections of RFC 5036. Major Issue: The draft, which builds on the mechanisms defined in RFC 5561, defines two ways to manipu= late distribution of =93non-interesting state=94, since by default it would= be enabled =B7 In the Initialization message. I assume that in this case the o= nly valid use case would be disabling distribution of non-interesting state =B7 In the Capability message. This method could be both to disable= and re-enable distribution of state, but it could only be used if the peer= supports =93Dynamic Announcement Capability=94. My concern stems from the fact that the draft deals with =93old=94 LDP appl= ications, so that the possibility that distribution of FEC-to-Label binding= s can be unilaterally disabled for PW- and Prefix-FECs is not taken into ac= count in the existing deployments and mechanisms. Here is a couple of examples: Consider the case when a targeted LDP session between PE1 and PE2 has been = set just for the purpose of running ICCP between these devices (i.e., in th= e terms of the ICCP draft they belong to the same RG). According to the exa= mple in Section 5.1 of the draft, the PEs could then disable distribution o= f both PW FECs and Prefix-FECs across such a session in their appropriate I= nitialization messages. The following (valid from my point of view) scenarios would make such a set= ting highly problematic: 1. The operator that manages both PE1 and PE2: a. Maintains some VPLS instances in its network b. Initially maintains VPLS instances in both E1 and PE2, but without = overlap between the sets of these instances (so that there is no need to se= tup PWs between PE1 and PE2) c. Uses BGP-based autodiscovery mechanisms for VPLS in its network as= described in RFC 6074 d. Is required to extend one of the VPLS instances it maintains and th= at already has presence in PE1 to have presence also in PE2: i. Wit= h BGP-based autodiscovery, explicit configuration of just PE2 should suffic= e, the person (or management application) that extends this instance does n= ot have to know about the rest of the locations where this VPLS instance is= present ii. The= autodiscovery process (which does not depend on LDP) identifies PE1 as a p= eer for the VPLS instance being defined in PE2, so that a PW between PE1 an= d PE2 is now required iii. The = PW setup process finds a targeted LDP session between PE1 and PE2 and tries= to use it for setting up the required PW iv. Howev= er, PW setup would fails because distribution of PW FECs across the already= existing targeted LDP session between PE1 and PE2 has been disabled. e. If PE1 and PE2 support =93Dynamic Capability Announcement=94, this = could be amended by enabling distribution of PW FECs prior to setting the r= equired PW. However, this would require substantial changes in the existing= PW setup procedures f. If even one of the PEs does not support =93Dynamic Capability Ann= ouncement=94, the existing targeted LDP session would have to be torn down = and re-established again. This would probably have serious implications for= the ICCP-based redundancy mechanism. 2. A similar scenario could be encountered if the operator employs dy= namic setup of multi-segment PWs, and the PW routing mechanism decides that= one of the segments of a new MS-PW to be set up should run between PE1 and= PE2. Such a situation could be probably prevented if the PW routing mech= anism could learn that PE1 and PE2 cannot be =93directly connected=94, but,= to the best of my understanding, it would require changes in the already s= tandardized MS-PW routing mechanism. I have discussed these cases with the authors, but we have not reached an a= greement on them yet. From my point of view, the Applicability Statement se= ction should address these concerns. Consider now the case described in Section 5.2 of the draft, when a targete= d LDP session between PE1 and PE2 is initially used just for distribution o= f setup of PWs, so that distribution of Prefix-FECs is disabled. The following (valid from my point of view) scenario would make such a sett= ing highly problematic: 1. The operator uses LDP for setting =93Tunnel LSPs=94 in its network 2. LFA-based LDP FRR (as per RFC 5286 and Remote LFA draft) is used as the mech= anism for fast protection in the operator=92s network. 3. Initially PE1 can protect all the LSPs passing through it using ju= st local LFA. 4. The network topology changes (e.g., because new LSRs are added to = it), and in order to provide the required coverage, PE1 has to use PE2 as i= ts =93remote LFA=94 for some destinations. a. This would require distribution of Prefix-FECs across the targeted= LDP session between PE1 and PE2 =96 but it has been disabled b. If PE2 does not support =93Dynamic Announcement Capability=94, then= the only way to amend the situation would be to tear down the targeted LDP= session between PE1 and PE2 and to set it up again =96 but this would nega= tively affect PW traffic between PE1 and PE2. I have discussed this case with the authors. To the best of my understandin= g, they have agreed that combining LDP FRR based on Remote LFAs with the me= chanisms defined in the draft would be highly problematic, and will add som= e suitable text to the Applicability Statement section in the next revision= of the draft. Minor Issues: 1. The draft states (in section 4.2) that desire of a given LSR of r= eception of unnecessary state from the peer is =93unilateral and unidirecti= onal by nature=94. a. IMO this makes perfect sense for Prefix-FECs. b. However, PW FECs must always be exchange in both directions of a t= argeted LDP session, so that disabling their distribution in just one direc= tion would effectively prevent setup of PWs between the given pair of PEs 2. I concur with Adrian=92s comment in his AD review of the draft abo= ut proposed encoding of states of non-interest. 3. I also wonder whence the need for 16 potential states of non-inte= rest in the draft that, to the best of my understanding, deals with exactly= 4 =93old=94 LDP applications. I hope that this does not imply possibility = of developing new =93old-style=92 LDP applications in future (or discoverin= g some forgotten old ones?). I have not yet discussed these issues with the authors (as we concentrated = on the major ones). Nits: None found by the IDNITS tool. Spelling and Grammar: I defer to the English Language review team. Hopefully these comments will be useful. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: +972-54-9266302 --_000_14073516835408563ecitelecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Kamran, Sami,

Lots of thanks for your cooperation.

I believe that we have successfully resolved all the= remaining issues at our WebEx call today.

I will be waiting for the next revision of the draft to f= ormally confirm that.

 

Adrian and all,

It took more time than we originally planned - but we did it!

 

Regards,

Sasha  

From: Kamran Raza (skraza= ) <skraza@cisco.com>
Sent: Wednesday, August 6, 2014 8:56 PM
To: adrian@olddog.co.uk
Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); draft-ietf-mpls-ldp-i= p-pw-capability.all@tools.ietf.org; Alexander Vainshtein; rtg-ads@tools.iet= f.org
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07= .txt
 
Hi Adrian,

We (authors) just had a webex call with Sasha to discuss/close on his = comments [ which we had also discussed over the email starting May ].
We all are in agreement/sync on the points that were raised during thi= s review . Almost all, if not all,  of the points/comments will be add= ressed by
clarifying the  scope of the extension in a new =93Applicability&= quot; section with risk and recommendations highlighted.

We will work on updating the draft and post a new rev shortly.

We thank you Sasha for his detailed review and useful comments and tha= nk you for your patience.
=97
Kamran and Sami

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Wednesday, July 30, 2014 at= 6:16 PM
To: Syed Kamran Raza <skraza@cisco.com>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "Sami Boutros (sboutros)" <sboutros@cisco.com>, "draft-i= etf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" <draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, 'Alex= ander Vainshtein' <A= lexander.Vainshtein@ecitele.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org&g= t;
Subject: RE: RTG-DIR Review: draf= t-ietf-mpls-ldp-ip-pw-capability-07.txt

This is ver= y excellent. Thank you for going the extra mile to sort things out.<= /p>

 

A

 

From: Kamran Raza (skraza)= [mailto:skraza@cisco.com]
Sent: 30 July 2014 19:00
To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami B= outros (sboutros); = draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander Vai= nshtein'; rtg-ads@tools.ietf.org
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07= .txt

 

Hi = Adrian,

&nb= sp;

Yes= , authors wanted to have a f2f meeting with Sasha @ IETF but we had to sche= dule the meeting post IETF as Sasha did not attend.

We = are meeting tomorrow with Sasha to clarify/converge.

&nb= sp;

Tha= nks.

&nb= sp;

Kamran Raza
TECHNICAL LEADER.ENGINEERING
Product Development
skraza@cisco.com
Phone: +1 6= 13 254 4520


Cisco.com

&nb= sp;

Cisco Sy= stems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3. Pho= ne: 416-306-7000; Fax: 416-306-7099.
Prefere= nces - Unsubscribe =96&= nbsp;Privacy

3D"Image Think before you print.

This email may contain confidential and privileged material fo= r the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibit= ed. If you are not the intended recipient (or authorized to receive for the= recipient), please contact the sender by reply email and delete all copies= of this message.

Please click here for Company Registration Information.

&nb= sp;

&nb= sp;

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog= .co.uk" <adrian@olddog.c= o.uk>
Date: Wednesday, July 30, 2014 at 9:02 AM
To: Syed Kamran Raza <skraza@= cisco.com>
Cc: "rtg-dir@ietf.org&q= uot; <rtg-dir@ietf.org>, &quo= t;Sami Boutros (sboutros)" <s= boutros@cisco.com>, "draft-ietf-mpls-ldp-ip-pw-capability.all@t= ools.ietf.org" <draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, 'Alex= ander Vainshtein' <A= lexander.Vainshtein@ecitele.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org&g= t;
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07= .txt

&nb= sp;

Kamran,

 

Thanks for = responding to the question in the GenArt review.

 

Do you have= any responses to Sasha's review (copied below)?

 

cheers,

Adrian

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: 11 May 2014 15:09
To: rtg-ads@tools.ietf.org=
Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (s= boutros@cisco.com)
Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt=

 

= Hello,

=  

= I have been selected as the Routing Directorate reviewer for this draft.

= The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Rou= ting 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 wo= uld 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-ietf-mpls-ldp-ip-pw-capability-07.txt

= Reviewer: Alexander (=93Sasha=94) Vainshtein   

= Review date: 11-May-14

= IETF LC End Date: 12-May-14

= Intended status: Standards Track

=  

Summary:

=  

= I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors.

= These concerns mainly deal with potential negative impact of the mechanisms= (introduced in the draft) for disabling =93non-negotiable=94 capabilities of LDP sessions  with the technique= s that could dynamically change the state of =93interest=94 in these capabi= lities for a given LDP session. 

= Some of these mechanisms are already standardized by the IETF, e.g.,  =  L2VPN auto-discovery (= RFC 6074) and  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others -  LDP FRR= using remote loop-free adjacencies (draft-ietf-rtgwg-remot= e-lfa)- are in advanced stages of the IETF process.   

=  

=  

= I must admit that I did not follow closely the discussion of  the draf= t in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found= not relevant.

= I also do not know if the draft has ever been discussed in the PWE3, L2VPN = and RTG WGs.

 =

= One possible way to address these concerns would be by adding an Applicabil= ity Statement section to the draft and discussing potentially problematic combinations of mechanisms there.

= I have discussed this option with the authors and, to the best of my unders= tanding, they have in general agreed to add such a section to the next revision of the draft.

 =

General comments:

To the best of my understanding the sole purpose of t= he draft is  prevention of =93 wasteful=94 distribution of state deali= ng with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined in RFC 5036) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined= in RFC 4447) to LDP peers that are =93not interested=92 in this state. Suc= h unnecessary distribution would result in unnecessary waste of resources (= memory and/or CPU cycles) and hence should be avoided.  

 

The draft mentions that:

<quote>

  To avoid this unnecessary state advertisement= and exchange, currently

  an operator is typically required to con= figure and define filtering

  policies on the LSR, which introduces un= necessary operational

  overhead and complexity for such deploym= ents. 

<end quote>

 

The draft, however, does not mention that filtering p= olicies provide much finer granularity of control over distribution of labe= ls than that supported by the mechanism introduced in the draft.

E.g., in a scenario when LDP is supposed to set up on= ly =93tunnel LSPs=94 between PEs for L2 and L3 VPN applications, an appropr= iate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FECs associated wi= th the subnets of their core-facing interfaces. IMHO and FWIW this means th= at support of the mechanism defined in the draft would not eliminate the ne= ed for the filtering policies.<= /p>

 

I have discussed this point with the authors and they= have agreed to add some clarifying text.

 

I have also failed to understand how distribution of = PW FECs could be wasteful. Section 5.3.3  =93Signaling Procedures=94 o= f RFC 4447 explicitly stat= es that:

<quote>

   In order for PE1 to begin signa=
ling PE2, PE1 must know the address of=

   the remote PE2, and a TAI. =
; This information may have been configured
   at PE1, or it may have been lea=
rned dynamically via some
   autodiscovery procedure.=

 <=
/span>
   The egress PE (PE1), which has =
knowledge of the ingress PE, initiates=

   the setup by sending a Label Ma=
pping Message to the ingress PE (PE2).=

<end quote>

 

My reading of the quoted text is that PW FECs are onl= y distributed across targeted LDP sessions with the known Remote PEs for sp= ecific PWs.

AFAIK, this is what actually happens in most existing= implementations of PW signaling with RFC 4447.

What=92s more, many implementations, when required to= set up a PW with a specific remote PE, check for existence of a targeted L= DP session with this PE, and set it up implicitly if it does not exist; then they distribute PW FEC-to-label binding via thi= s session only. Implicit targeted LDP sessions are also implicitly torn dow= n when the last PW between  the given pair of PEs is torn down.=

I have discussed this point with the authors, but, as= of the moment of writing this review,  we did not yet reach full agre= ement on it.  

 

Readability of the draft:=

 

Initially I have failed to understand the following t= ext fragment in the draft (the problematic statements are marked with italics):

<quote>

   For Prefix-LSPs application type, the=
 non-interesting state refers <=
/pre>

   to any state related to IP Prefi=
x FEC (such as FEC label bindings, 


   LDP Status). This document, h=
owever, does not classify IP address 


   bindings as a non-interesting=
 state and allows the advertisement of 


   IP Address bindings to facili=
tate other LDP applications (such as 


   mLDP) that depend on learning=
 of peer addresses over an LDP session 


   for their correct operation.


<end quote>


After discussing this point with the authors I=92ve u=
nderstood that they refer to exchange of the LSR addresses in the Address a=
nd Address Withdraw messages that is required
 for mapping Next Hop IP addresses computed by the IGP to Next Hop LSR. Whi=
le initial misunderstanding may be specific to me,  I have suggested t=
o the authors to clarify this point with explicit references to specific LD=
P messages and sections of
RFC 5036.


 

Major Issue:


 

The draft, which builds on the mechanisms defined in
RFC =
5561,  defines two ways to manipulate distribution of =93non-inter=
esting state=94, since by default it would be enabled



=B7        
In the Initialization m=
essage. I assume that in this case the only valid use case would be disabli=
ng distribution of non-interesting state
=B7        
In the Capability messa=
ge. This method could be both to disable and re-enable distribution of stat=
e, but it could only be used if the peer supports =93Dynamic Announcement C=
apability=94.


 

My concern stems from the fact that the draft deals w=
ith =93old=94 LDP applications, so that the possibility that distribution o=
f FEC-to-Label bindings can be unilaterally
 disabled for PW- and Prefix-FECs is not taken into account in the existing=
 deployments and mechanisms.

 

Here is a couple of examples:


 

Consider the case when a targeted LDP session between=
 PE1 and PE2 has been set just for the purpose of running ICCP between thes=
e devices (i.e., in the terms of the ICCP
 draft they belong to the same RG). According to the example in Section 5.1=
 of the draft, the PEs could then disable distribution of both PW FECs and =
Prefix-FECs across such a session in their appropriate Initialization messa=
ges.


 

The following (valid from my point of view) scenarios=
 would make such a setting highly problematic:



1.      
The operator that manag=
es both PE1 and PE2:



a.      
Maintains some  VP=
LS instances in its network



b.     
Initially maintains VPL=
S instances in both E1 and PE2, but without overlap between the sets of the=
se instances (so that there is no need to setup PWs between PE1 and PE2)



c.      
Uses BGP-based autodisc=
overy mechanisms for VPLS in its network as described in RFC 6074



d.     
Is required to extend o=
ne of the VPLS instances it maintains and that already has presence in PE1 =
to have presence also in PE2:


       =
;            &n=
bsp;            =
;            &n=
bsp;            =
;      
i.     
With BGP-based autodisc=
overy, explicit configuration of just PE2 should suffice, the person (or ma=
nagement application) that extends this instance does not have to know abou=
t the rest of the locations where this
 VPLS instance is present



       =
;            &n=
bsp;            =
;            &n=
bsp;            =
;     
ii.     
The autodiscovery proce=
ss (which does not depend on LDP) identifies PE1 as a peer for the VPLS ins=
tance being defined in PE2, so that a PW between PE1 and PE2 is now require=
d




       =
;            &n=
bsp;            =
;            &n=
bsp;            =
;   
iii.     
The PW setup process fi=
nds a targeted LDP session between PE1 and PE2 and tries to use it for sett=
ing up the required PW



       =
;            &n=
bsp;            =
;            &n=
bsp;            =
;   
iv.     
However, PW setup would=
 fails because distribution of PW FECs across the already existing targeted=
 LDP session between PE1 and PE2 has been disabled.



e.     
If PE1 and PE2 support =
=93Dynamic Capability Announcement=94, this could be amended by enabling di=
stribution of PW FECs prior to setting the required PW. However, this would=
 require substantial changes in the existing
 PW setup procedures



f.       
If even one of the PEs =
does not support =93Dynamic Capability Announcement=94, the existing target=
ed LDP session would have to be torn down and re-established again. This wo=
uld probably have serious implications for
 the ICCP-based redundancy mechanism.<=
/span>



2.      
A similar scenario coul=
d be encountered if the operator employs dynamic setup of multi-segment PWs=
, and the PW routing mechanism decides that one of the segments of a new MS=
-PW to be set up should run between
 PE1 and PE2.   Such a situation could be probably prevented if t=
he PW routing mechanism could learn that PE1 and PE2 cannot be =93directly =
connected=94, but, to the best of my understanding, it would require change=
s in the already standardized MS-PW routing mechanism.


 


I have discussed these cases=
 with the authors, but we have not reached an agreement on them yet. From m=
y point of view, the Applicability Statement
 section should address these concerns.


 


Consider now the case descri=
bed in Section 5.2 of the draft, when a targeted LDP session between PE1 an=
d PE2 is initially used just for distribution
 of setup of PWs, so that distribution of Prefix-FECs is disabled.


 


The following (valid from my=
 point of view) scenario would make such a setting highly problematic:



1.      
The operator uses LDP f=
or setting =93Tunnel LSPs=94 in its network



2.      
LFA-based LDP FRR (as p=
er 
RFC 5286 and 
Remote LFA draft) is used as the mechanism for fast protection in the o=
perator=92s network.



3.      
Initially PE1 can prote=
ct all the LSPs passing through it using just local LFA.



4.      
The network topology ch=
anges (e.g., because new LSRs are added to it), and in order to provide the=
 required coverage, PE1 has to use PE2 as its =93remote LFA=94 for some des=
tinations.




a.      
This would require dist=
ribution of Prefix-FECs across the targeted LDP session between PE1 and PE2=
 =96 but it has been disabled


b.     
If PE2 does not support=
 =93Dynamic Announcement Capability=94, then the only way to amend the situ=
ation would be to tear down the targeted LDP session between PE1 and PE2 an=
d to set it up again =96 but this would negatively
 affect PW traffic between PE1 and PE2.


 


I have discussed this case with =
the authors. To the best of my understanding, they have agreed that combini=
ng LDP FRR based on Remote LFAs with the
 mechanisms defined in the draft would be highly problematic, and will add =
some suitable text to the Applicability Statement section in the next revis=
ion of the draft.


 


 


Minor Issues: 


1.      
The draft=
 states (in section 4.2) that desire of a given LSR  of reception of u=
nnecessary state from the peer is =93unilateral and unidirectional by natur=
e=94.




a.      
IMO this =
makes perfect sense for Prefix-FECs.




b.     
However, =
PW FECs must always be exchange in both directions of  a targeted LDP =
session, so that disabling their distribution in just one direction would e=
ffectively prevent setup of PWs between the
 given pair of PEs


2.      
I concur =
with Adrian=92s comment in his AD review of the draft about proposed encodi=
ng of states of non-interest.

3.      
 I a=
lso wonder whence the need for 16 potential states of non-interest in =
the draft that, to the best of my understanding, deals with exactly 4 =93ol=
d=94 LDP applications. I hope that this does not imply
 possibility of developing new =93old-style=92 LDP applications in future (=
or discovering some forgotten old ones?).


 

I have not yet discussed these issues with the author=
s (as we concentrated on the major ones).


 

Nits:


None found by the IDNITS tool.


 

 

Spelling and Grammar:


I defer to the English Language review team.



 

Hopefully these comments will be useful.


 

Regards,<=
/p>

       Sasha



Email:
Alexander.Vainshtein@ec=
itele.com


Mobile: +972-54-9266302


 
--_000_14073516835408563ecitelecom_-- --_004_14073516835408563ecitelecom_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Wed, 06 Aug 2014 17:56:52 GMT"; modification-date="Wed, 06 Aug 2014 17:56:52 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_14073516835408563ecitelecom_-- From nobody Wed Aug 6 12:52: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 EC5FF1A03D8 for ; Wed, 6 Aug 2014 10:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 tphKafkOpIYm for ; Wed, 6 Aug 2014 10:56:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E931A014D for ; Wed, 6 Aug 2014 10:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=115336; q=dns/txt; s=iport; t=1407347815; x=1408557415; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wyjBgqqq0WAehOqWAH4MQVBygQuPEl33+7a/ruWJDAY=; b=GOB9SPBII2NNptsZVkTW8HfFPxuk99MO5ZC2NxIxmsDKhQYPPl6vR890 SKS23OnumaTEtgxBb7A9rz3AMaEa6FR7ZyfOcCE6bEPQTHBxB4KEOtfJ6 Nfc1TkK1uiYOe8HxKlq6wGGHpOBHn/t27wJKMQnCethF1iWL2wXL+B88x 4=; X-Files: ~WRD000.jpg : 823 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMHAE5r4lOtJA2F/2dsb2JhbABXAxaCMUZSVwSxQZkCgVkBC4dGAYEWFneEAwEBAQQFFQESIRgHBwUOAgIBCAcKAwEBAQYBAQEEBgMLAQYHAhUBAwsLARQJCAEBBA4BAwEBBQMFDwSIIQ2uR5R1FwSJe4RrEQEZCwEFAgkDBwEMBAYBAgICAwEHhDoFjUCBPIQOgUpXgjmELoFUkxGBZBSBXGwBBn8HFyI X-IronPort-AV: E=Sophos;i="5.01,813,1400025600"; d="jpg'145?scan'145,208,217,145";a="345575144" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP; 06 Aug 2014 17:56:53 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s76Hura7032211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 17:56:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.126]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 12:56:53 -0500 From: "Kamran Raza (skraza)" To: "adrian@olddog.co.uk" Thread-Topic: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Thread-Index: Ac9tIpHty7MH85zjQlWHldfu8Tbv0Q+/c2sAAAIGHYAAEVVFgAFOl7+A Date: Wed, 6 Aug 2014 17:56:53 +0000 Message-ID: References: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> <005401cfac43$e76b9f10$b642dd30$@olddog.co.uk> In-Reply-To: <005401cfac43$e76b9f10$b642dd30$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [161.44.213.21] Content-Type: multipart/mixed; boundary="_004_D007E362A9B54skrazaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/mcBaLeJYfVClqQHGjsf_85mBXjc X-Mailman-Approved-At: Wed, 06 Aug 2014 12:52:22 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , 'Alexander Vainshtein' , "Sami Boutros \(sboutros\)" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-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: Wed, 06 Aug 2014 17:57:02 -0000 --_004_D007E362A9B54skrazaciscocom_ Content-Type: multipart/alternative; boundary="_000_D007E362A9B54skrazaciscocom_" --_000_D007E362A9B54skrazaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adrian, We (authors) just had a webex call with Sasha to discuss/close on his comme= nts [ which we had also discussed over the email starting May ]. We all are in agreement/sync on the points that were raised during this rev= iew . Almost all, if not all, of the points/comments will be addressed by clarifying the scope of the extension in a new =93Applicability" section w= ith risk and recommendations highlighted. We will work on updating the draft and post a new rev shortly. We thank you Sasha for his detailed review and useful comments and thank yo= u for your patience. =97 Kamran and Sami From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, July 30, 2014 at 6:16 PM To: Syed Kamran Raza > Cc: "rtg-dir@ietf.org" >, "Sami Boutros (sboutros)" >, "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org<= mailto:draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>" >, 'Alexander Vainshtein' >, "rtg-ads@too= ls.ietf.org" > Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt This is very excellent. Thank you for going the extra mile to sort things o= ut. A From: Kamran Raza (skraza) [mailto:skraza@cisco.com] Sent: 30 July 2014 19:00 To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); dra= ft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander Vainshtein'; rtg-ads@= tools.ietf.org Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hi Adrian, Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to s= chedule the meeting post IETF as Sasha did not attend. We are meeting tomorrow with Sasha to clarify/converge. Thanks. Kamran Raza TECHNICAL LEADER.ENGINEERING Product Development skraza@cisco.com Phone: +1 613 254 4520 Cisco.com Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J = 2T3. Phone: 416-306-7000; Fax: 416-306-7099. Preferences - Unsubs= cribe =96 Privacy<= http://www.cisco.com/web/siteassets/legal/privacy.html> [Image removed by sender.] Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: Adrian Farrel > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, July 30, 2014 at 9:02 AM To: Syed Kamran Raza > Cc: "rtg-dir@ietf.org" >, "Sami Boutros (sboutros)" >, "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org<= mailto:draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>" >, 'Alexander Vainshtein' >, "rtg-ads@too= ls.ietf.org" > Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Kamran, Thanks for responding to the question in the GenArt review. Do you have any responses to Sasha's review (copied below)? cheers, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 11 May 2014 15:09 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-c= apability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros= (sboutros@cisco.com) Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related draf= ts 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, please see http://www.i= etf.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-ip-pw-capability-07.txt Reviewer: Alexander (=93Sasha=94) Vainshtein Review date: 11-May-14 IETF LC End Date: 12-May-14 Intended status: Standards Track Summary: I have significant concerns about this document and recommend that the Rout= ing ADs discuss these issues further with the authors. These concerns mainly deal with potential negative impact of the mechanisms= (introduced in the draft) for disabling =93non-negotiable=94 capabilities = of LDP sessions with the techniques that could dynamically change the stat= e of =93interest=94 in these capabilities for a given LDP session. Some of these mechanisms are already standardized by the IETF, e.g., L2VP= N auto-discovery (RFC 6074) and dynami= c placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others - LDP FRR using remote loop-free adjacencies (draft-ie= tf-rtgwg-remote-lfa)- are in advanced stages of the IETF process. I must admit that I did not follow closely the discussion of the draft in = question in the MPLS WG; so it may well be that some of my concerns have be= en already raised, considered and found not relevant. I also do not know if the draft has ever been discussed in the PWE3, L2VPN = and RTG WGs. One possible way to address these concerns would be by adding an Applicabil= ity Statement section to the draft and discussing potentially problematic c= ombinations of mechanisms there. I have discussed this option with the authors and, to the best of my unders= tanding, they have in general agreed to add such a section to the next revi= sion of the draft. General comments: To the best of my understanding the sole purpose of the draft is preventio= n of =93 wasteful=94 distribution of state dealing with two non-negotiable = classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes = defined in RFC 5036) and PW FECs (i.e. = PW Id FEC and Generalized PW Id FEC defined in RFC 4447) to LDP peers that are =93not interested=92 in this state.= Such unnecessary distribution would result in unnecessary waste of resourc= es (memory and/or CPU cycles) and hence should be avoided. The draft mentions that: To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments. The draft, however, does not mention that filtering policies provide much f= iner granularity of control over distribution of labels than that supported= by the mechanism introduced in the draft. E.g., in a scenario when LDP is supposed to set up only =93tunnel LSPs=94 b= etween PEs for L2 and L3 VPN applications, an appropriate policy allow dist= ribution of the just the FECs associated with Router IDs of the PEs but not= , say FECs associated with the subnets of their core-facing interfaces. IMH= O and FWIW this means that support of the mechanism defined in the draft wo= uld not eliminate the need for the filtering policies. I have discussed this point with the authors and they have agreed to add so= me clarifying text. I have also failed to understand how distribution of PW FECs could be waste= ful. Section 5.3.3 =93Signaling Procedures=94 of RFC 4447 explicitly states that: In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). My reading of the quoted text is that PW FECs are only distributed across t= argeted LDP sessions with the known Remote PEs for specific PWs. AFAIK, this is what actually happens in most existing implementations of PW= signaling with RFC 4447. What=92s more, many implementations, when required to set up a PW with a sp= ecific remote PE, check for existence of a targeted LDP session with this P= E, and set it up implicitly if it does not exist; then they distribute PW F= EC-to-label binding via this session only. Implicit targeted LDP sessions a= re also implicitly torn down when the last PW between the given pair of PE= s is torn down. I have discussed this point with the authors, but, as of the moment of writ= ing this review, we did not yet reach full agreement on it. Readability of the draft: Initially I have failed to understand the following text fragment in the dr= aft (the problematic statements are marked with italics): For Prefix-LSPs application type, the non-interesting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings as a non-interesting state and allows the advertisement of IP Address bindings to facilitate other LDP applications (such as mLDP) that depend on learning of peer addresses over an LDP session for their correct operation. After discussing this point with the authors I=92ve understood that they re= fer to exchange of the LSR addresses in the Address and Address Withdraw me= ssages that is required for mapping Next Hop IP addresses computed by the I= GP to Next Hop LSR. While initial misunderstanding may be specific to me, = I have suggested to the authors to clarify this point with explicit referen= ces to specific LDP messages and sections of RFC 5036. Major Issue: The draft, which builds on the mechanisms defined in RFC 5561, defines two ways to manipu= late distribution of =93non-interesting state=94, since by default it would= be enabled =B7 In the Initialization message. I assume that in this case the o= nly valid use case would be disabling distribution of non-interesting state =B7 In the Capability message. This method could be both to disable= and re-enable distribution of state, but it could only be used if the peer= supports =93Dynamic Announcement Capability=94. My concern stems from the fact that the draft deals with =93old=94 LDP appl= ications, so that the possibility that distribution of FEC-to-Label binding= s can be unilaterally disabled for PW- and Prefix-FECs is not taken into ac= count in the existing deployments and mechanisms. Here is a couple of examples: Consider the case when a targeted LDP session between PE1 and PE2 has been = set just for the purpose of running ICCP between these devices (i.e., in th= e terms of the ICCP draft they belong to the same RG). According to the exa= mple in Section 5.1 of the draft, the PEs could then disable distribution o= f both PW FECs and Prefix-FECs across such a session in their appropriate I= nitialization messages. The following (valid from my point of view) scenarios would make such a set= ting highly problematic: 1. The operator that manages both PE1 and PE2: a. Maintains some VPLS instances in its network b. Initially maintains VPLS instances in both E1 and PE2, but without = overlap between the sets of these instances (so that there is no need to se= tup PWs between PE1 and PE2) c. Uses BGP-based autodiscovery mechanisms for VPLS in its network as= described in RFC 6074 d. Is required to extend one of the VPLS instances it maintains and th= at already has presence in PE1 to have presence also in PE2: i. Wit= h BGP-based autodiscovery, explicit configuration of just PE2 should suffic= e, the person (or management application) that extends this instance does n= ot have to know about the rest of the locations where this VPLS instance is= present ii. The= autodiscovery process (which does not depend on LDP) identifies PE1 as a p= eer for the VPLS instance being defined in PE2, so that a PW between PE1 an= d PE2 is now required iii. The = PW setup process finds a targeted LDP session between PE1 and PE2 and tries= to use it for setting up the required PW iv. Howev= er, PW setup would fails because distribution of PW FECs across the already= existing targeted LDP session between PE1 and PE2 has been disabled. e. If PE1 and PE2 support =93Dynamic Capability Announcement=94, this = could be amended by enabling distribution of PW FECs prior to setting the r= equired PW. However, this would require substantial changes in the existing= PW setup procedures f. If even one of the PEs does not support =93Dynamic Capability Ann= ouncement=94, the existing targeted LDP session would have to be torn down = and re-established again. This would probably have serious implications for= the ICCP-based redundancy mechanism. 2. A similar scenario could be encountered if the operator employs dy= namic setup of multi-segment PWs, and the PW routing mechanism decides that= one of the segments of a new MS-PW to be set up should run between PE1 and= PE2. Such a situation could be probably prevented if the PW routing mech= anism could learn that PE1 and PE2 cannot be =93directly connected=94, but,= to the best of my understanding, it would require changes in the already s= tandardized MS-PW routing mechanism. I have discussed these cases with the authors, but we have not reached an a= greement on them yet. From my point of view, the Applicability Statement se= ction should address these concerns. Consider now the case described in Section 5.2 of the draft, when a targete= d LDP session between PE1 and PE2 is initially used just for distribution o= f setup of PWs, so that distribution of Prefix-FECs is disabled. The following (valid from my point of view) scenario would make such a sett= ing highly problematic: 1. The operator uses LDP for setting =93Tunnel LSPs=94 in its network 2. LFA-based LDP FRR (as per RFC 5286 and Remote LFA draft) is used as the mech= anism for fast protection in the operator=92s network. 3. Initially PE1 can protect all the LSPs passing through it using ju= st local LFA. 4. The network topology changes (e.g., because new LSRs are added to = it), and in order to provide the required coverage, PE1 has to use PE2 as i= ts =93remote LFA=94 for some destinations. a. This would require distribution of Prefix-FECs across the targeted= LDP session between PE1 and PE2 =96 but it has been disabled b. If PE2 does not support =93Dynamic Announcement Capability=94, then= the only way to amend the situation would be to tear down the targeted LDP= session between PE1 and PE2 and to set it up again =96 but this would nega= tively affect PW traffic between PE1 and PE2. I have discussed this case with the authors. To the best of my understandin= g, they have agreed that combining LDP FRR based on Remote LFAs with the me= chanisms defined in the draft would be highly problematic, and will add som= e suitable text to the Applicability Statement section in the next revision= of the draft. Minor Issues: 1. The draft states (in section 4.2) that desire of a given LSR of r= eception of unnecessary state from the peer is =93unilateral and unidirecti= onal by nature=94. a. IMO this makes perfect sense for Prefix-FECs. b. However, PW FECs must always be exchange in both directions of a t= argeted LDP session, so that disabling their distribution in just one direc= tion would effectively prevent setup of PWs between the given pair of PEs 2. I concur with Adrian=92s comment in his AD review of the draft abo= ut proposed encoding of states of non-interest. 3. I also wonder whence the need for 16 potential states of non-inte= rest in the draft that, to the best of my understanding, deals with exactly= 4 =93old=94 LDP applications. I hope that this does not imply possibility = of developing new =93old-style=92 LDP applications in future (or discoverin= g some forgotten old ones?). I have not yet discussed these issues with the authors (as we concentrated = on the major ones). Nits: None found by the IDNITS tool. Spelling and Grammar: I defer to the English Language review team. Hopefully these comments will be useful. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: +972-54-9266302 --_000_D007E362A9B54skrazaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2F4F2E92742A4546A772EFC92981E8A1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Adrian,

We (authors) just had a webex call with Sasha to discuss/close on his = comments [ which we had also discussed over the email starting May ].
We all are in agreement/sync on the points that were raised during thi= s review . Almost all, if not all,  of the points/comments will be add= ressed by
clarifying the  scope of the extension in a new =93Applicability&= quot; section with risk and recommendations highlighted.

We will work on updating the draft and post a new rev shortly.

We thank you Sasha for his detailed review and useful comments and tha= nk you for your patience.
=97
Kamran and Sami

From: Adrian Farrel <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Wednesday, July 30, 2014 at 6= :16 PM
To: Syed Kamran Raza <skraza@cisco.com>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "Sami Boutros (sboutros)" <sboutros@cisco.com>, "draft-i= etf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" <draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, 'Alex= ander Vainshtein' <A= lexander.Vainshtein@ecitele.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org&g= t;
Subject: RE: RTG-DIR Review: draft-= ietf-mpls-ldp-ip-pw-capability-07.txt

This is very excellent. Thank y= ou for going the extra mile to sort things out.

 

A

 

From: Kamran Raza (skraza= ) [mailto:skraza@cisco.com]
Sent: 30 July 2014 19:00
To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami B= outros (sboutros); = draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander Vai= nshtein'; rtg-ads@tools.ietf.org
Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07= .txt

 

Hi Adrian,

 

Yes, authors wanted to have a = f2f meeting with Sasha @ IETF but we had to schedule the meeting post IETF = as Sasha did not attend.

We are meeting tomorrow with S= asha to clarify/converge.

 

Thanks.

 

Kamran Raza
TECHNICAL LEADER.ENGINEERING
Product Development
skraza@cisco.com
Phone: +1 = 613 254 4520


Cisco.com

 

Cisco S= ystems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3. Ph= one: 416-306-7000; Fax: 416-306-7099.
Preferences - Unsubscribe =96 P= rivacy

 Think before you print.

This email may contain confidential and privileged materi= al for the sole use of the intended recipient. Any review, use, distributio= n or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receiv= e for the recipient), please contact the sender by reply email and delete a= ll copies of this message.

Please click here for Company Registration Information.

 

 

From: Adrian Farrel <ad= rian@olddog.co.uk>
Reply-To: "adrian@olddog= .co.uk" <adrian@olddog.c= o.uk>
Date: Wednesday, July 30, 2014 at 9:02 AM
To: Syed Kamran Raza <skraza@= cisco.com>
Cc: "rtg-dir@ietf.org&q= uot; <rtg-dir@ietf.org>, &quo= t;Sami Boutros (sboutros)" <s= boutros@cisco.com>, "draft-ietf-mpls-ldp-ip-pw-capability.all@t= ools.ietf.org" <draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, 'Alex= ander Vainshtein' <A= lexander.Vainshtein@ecitele.com>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org&g= t;
Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07= .txt

 

Kamran,

 

Thanks for responding = to the question in the GenArt review.

 

Do you have any respon= ses to Sasha's review (copied below)?

 

cheers,

Adrian

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: 11 May 2014 15:09
To: rtg-ads@tools.ietf.org=
Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (s= boutros@cisco.com)
Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt=

 =

H= ello,

&= nbsp;

I= have been selected as the Routing Directorate reviewer for this draft.

T= he Routing Directorate seeks to review all routing or routing-related draft= s as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Rou= ting ADs.

F= or more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

&= nbsp;

A= lthough these comments are primarily for the use of the Routing ADs, it wou= ld 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.

&= nbsp;

D= ocument: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

R= eviewer: Alexander (=93Sasha=94) Vainshtein   

R= eview date: 11-May-14<= /p>

I= ETF LC End Date: 12-May-14

I= ntended status: Standards Track

&= nbsp;

:

&= nbsp;

I= have significant concerns about this document and recommend that the Routi= ng ADs discuss these issues further with the authors.

T= hese concerns mainly deal with potential negative impact of the mechanisms = (introduced in the draft) for disabling =93non-negotiable=94 capabilities of LDP sessions  with the technique= s that could dynamically change the state of =93interest=94 in these capabi= lities for a given LDP session. 

S= ome of these mechanisms are already standardized by the IETF, e.g.,  &= nbsp;L2VPN auto-discovery (R= FC 6074) and  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others -  LDP FRR= using remote loop-free adjacencies (draft-ietf-rtgwg-remot= e-lfa)- are in advanced stages of the IETF process.   

&= nbsp;

&= nbsp;

I= must admit that I did not follow closely the discussion of  the draft= in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found no= t relevant.

I= also do not know if the draft has ever been discussed in the PWE3, L2VPN a= nd RTG WGs.

 

O= ne possible way to address these concerns would be by adding an Applicabili= ty Statement section to the draft and discussing potentially problematic combinations of mechanisms there.

I= have discussed this option with the authors and, to the best of my underst= anding, they have in general agreed to add such a section to the next revision of the draft.

 

:

To the best of my understanding t= he sole purpose of the draft is  prevention of =93 wasteful=94 distrib= ution of state dealing with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined= in RFC 5036) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined= in RFC 4447) to LDP peers that are =93not interested=92 in this state. Suc= h unnecessary distribution would result in unnecessary waste of resources (= memory and/or CPU cycles) and hence should be avoided.  

 

The draft mentions that:

<quote>

  To avoid this unnecessary state advertisement and exchange,= currently

  an operator is typically required to configure and def= ine filtering

  policies on the LSR, which introduces unnecessary oper= ational

  overhead and complexity for such deployments. 

<end quote>

 

The draft, however, does not ment= ion that filtering policies provide much finer granularity of control over = distribution of labels than that supported by the mechanism introduced in the draft.

E.g., in a scenario when LDP is s= upposed to set up only =93tunnel LSPs=94 between PEs for L2 and L3 VPN appl= ications, an appropriate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FE= Cs associated with the subnets of their core-facing interfaces. IMHO and FW= IW this means that support of the mechanism defined in the draft would not = eliminate the need for the filtering policies.

 

I have discussed this point with = the authors and they have agreed to add some clarifying text.

 

I have also failed to understand = how distribution of PW FECs could be wasteful. Section 5.3.3  =93Signa= ling Procedures=94 of RFC 4447 explicitly stat= es that:

<quote>

   In order for =
PE1 to begin signaling PE2, PE1 must know the address of
   the remote PE=
2, and a TAI.  This information may have been configured
   at PE1, or it=
 may have been learned dynamically via some
   autodiscovery=
 procedure.
 
   The egress PE=
 (PE1), which has knowledge of the ingress PE, initiates
   the setup by =
sending a Label Mapping Message to the ingress PE (PE2).

<end quote>

 

My reading of the quoted text is = that PW FECs are only distributed across targeted LDP sessions with the kno= wn Remote PEs for specific PWs.

AFAIK, this is what actually happ= ens in most existing implementations of PW signaling with RFC 4447.

What=92s more, many implementatio= ns, when required to set up a PW with a specific remote PE, check for exist= ence of a targeted LDP session with this PE, and set it up implicitly if it does not exist; then they distribute PW FEC= -to-label binding via this session only. Implicit targeted LDP sessions are= also implicitly torn down when the last PW between  the given pair of= PEs is torn down.

I have discussed this point with = the authors, but, as of the moment of writing this review,  we did not= yet reach full agreement on it.  <= o:p>

 

Readability of the draft:

 

Initially I have failed to unders= tand the following text fragment in the draft (the problematic statements a= re marked with italics):

<quote>

   For Prefix-LSPs app=
lication type, the non-interesting state refers 
   to any state r=
elated to IP Prefix FEC (such as FEC label bindings, 
   LDP Status). <=
i>This document, however, does not classify IP address 
   bindings as=
 a non-interesting state and allows the advertisement of 
   IP Address =
bindings to facilitate other LDP applications (such as 
   mLDP) that =
depend on learning of peer addresses over an LDP session 
   for their c=
orrect operation.

<end quote>


After discussing this point with =
the authors I=92ve understood that they refer to exchange of the LSR addres=
ses in the Address and Address Withdraw messages that
 is required for mapping Next Hop IP addresses computed by the IGP to Next =
Hop LSR. While initial misunderstanding may be specific to me,  I have=
 suggested to the authors to clarify this point with explicit references to=
 specific LDP messages and sections of
RFC 5036.


 


Major Issue:


 


The draft, which builds on the me=
chanisms defined in
RFC =
5561,  defines two ways to manipulate distribution of =93non-inter=
esting state=94, since by default it would be enabled



=B7        
I=
n the Initialization message. I assume that in this case the only valid use=
 case would be disabling distribution of non-interesting state



=B7        
I=
n the Capability message. This method could be both to disable and re-enabl=
e distribution of state, but it could only be used if the peer supports =93=
Dynamic Announcement Capability=94.=



 


My concern stems from the fact th=
at the draft deals with =93old=94 LDP applications, so that the possibility=
 that distribution of FEC-to-Label bindings
 can be unilaterally disabled for PW- and Prefix-FECs is not taken into acc=
ount in the existing deployments and mechanisms.


 


Here is a couple of examples:


 


Consider the case when a targeted=
 LDP session between PE1 and PE2 has been set just for the purpose of runni=
ng ICCP between these devices (i.e., in
 the terms of the ICCP draft they belong to the same RG). According to the =
example in Section 5.1 of the draft, the PEs could then disable distributio=
n of both PW FECs and Prefix-FECs across such a session in their appropriat=
e Initialization messages.


 


The following (valid from my poin=
t of view) scenarios would make such a setting highly problematic:



1.      
T=
he operator that manages both PE1 and PE2:



a.      
M=
aintains some  VPLS instances in its network



b.     
I=
nitially maintains VPLS instances in both E1 and PE2, but without overlap b=
etween the sets of these instances (so that there is no need to setup PWs b=
etween PE1 and PE2)


c.      
U=
ses BGP-based autodiscovery mechanisms for VPLS in its network as described=
 in RFC 6074



d.     
I=
s required to extend one of the VPLS instances it maintains and that alread=
y has presence in PE1 to have presence also in PE2:



     
W=
ith BGP-based autodiscovery, explicit configuration of just PE2 should suff=
ice, the person (or management application) that extends this instance does=
 not have to know about the rest of
 the locations where this VPLS instance is present



     
T=
he autodiscovery process (which does not depend on LDP) identifies PE1 as a=
 peer for the VPLS instance being defined in PE2, so that a PW between PE1 =
and PE2 is now required




     
T=
he PW setup process finds a targeted LDP session between PE1 and PE2 and tr=
ies to use it for setting up the required PW



     
H=
owever, PW setup would fails because distribution of PW FECs across the alr=
eady existing targeted LDP session between PE1 and PE2 has been disabled.



e.     
I=
f PE1 and PE2 support =93Dynamic Capability Announcement=94, this could be =
amended by enabling distribution of PW FECs prior to setting the required P=
W. However, this would require substantial
 changes in the existing PW setup procedures



f.       
I=
f even one of the PEs does not support =93Dynamic Capability Announcement=
=94, the existing targeted LDP session would have to be torn down and re-es=
tablished again. This would probably have
 serious implications for the ICCP-based redundancy mechanism.



2.      
A=
 similar scenario could be encountered if the operator employs dynamic setu=
p of multi-segment PWs, and the PW routing mechanism decides that one of th=
e segments of a new MS-PW to be set
 up should run between PE1 and PE2.   Such a situation could be p=
robably prevented if the PW routing mechanism could learn that PE1 and PE2 =
cannot be =93directly connected=94, but, to the best of my understanding, i=
t would require changes in the already standardized
 MS-PW routing mechanism.


 


I have dis=
cussed these cases with the authors, but we have not reached an agreement o=
n them yet. From my point of view, the Applicability
 Statement section should address these concerns.


 


Consider n=
ow the case described in Section 5.2 of the draft, when a targeted LDP sess=
ion between PE1 and PE2 is initially used
 just for distribution of setup of PWs, so that distribution of Prefix-FECs=
 is disabled.


 


The follow=
ing (valid from my point of view) scenario would make such a setting highly=
 problematic:



1.      
T=
he operator uses LDP for setting =93Tunnel LSPs=94 in its network



2.      
L=
FA-based LDP FRR (as per
RFC =
5286 and

Remote LFA draft) is used as the mechanism for fast protection in the o=
perator=92s network.


3.      
I=
nitially PE1 can protect all the LSPs passing through it using just local L=
FA.



4.      
T=
he network topology changes (e.g., because new LSRs are added to it), and i=
n order to provide the required coverage, PE1 has to use PE2 as its =93remo=
te LFA=94 for some destinations.




a.      
T=
his would require distribution of Prefix-FECs across the targeted LDP sessi=
on between PE1 and PE2 =96 but it has been disabled



b.     
I=
f PE2 does not support =93Dynamic Announcement Capability=94, then the only=
 way to amend the situation would be to tear down the targeted LDP session =
between PE1 and PE2 and to set it up again
 =96 but this would negatively affect PW traffic between PE1 and PE2.


 <=
span style=3D"color:black">


I have discuss=
ed this case with the authors. To the best of my understanding, they have a=
greed that combining LDP FRR based on Remote
 LFAs with the mechanisms defined in the draft would be highly problematic,=
 and will add some suitable text to the Applicability Statement section in =
the next revision of the draft.


 <=
span style=3D"color:black">


 <=
span style=3D"color:black">


Minor Issue=
s:


 <=
span style=3D"color:black">



1.      
The draft states (in section 4.2) that desire of=
 a given LSR  of reception of unnecessary state from the peer is =93un=
ilateral and unidirectional by nature=94.




a.      
IMO this makes perfect sense for Prefix-FECs.




b.     
However, PW FECs must always be exchange in both=
 directions of  a targeted LDP session, so that disabling their distri=
bution in just one direction would effectively
 prevent setup of PWs between the given pair of PEs



2.      
I concur with Adrian=92s comment in his AD revie=
w of the draft about proposed encoding of states of non-interest.



3.      
 I also wonder whence the need for 16 poten=
tial states of non-interest in the draft that, to the best of my under=
standing, deals with exactly 4 =93old=94 LDP applications.
 I hope that this does not imply possibility of developing new =93old-style=
=92 LDP applications in future (or discovering some forgotten old ones?).


 


I have not yet discussed these is=
sues with the authors (as we concentrated on the major ones).


 


Nits:


None found by the IDNITS tool.


 


 


Spelling and Grammar:


I defer to the English Language r=
eview team.



 


Hopefully these comments will be =
useful.


 


Regards,


     &nb=
sp; Sasha



Email:
Alexander.Vainshtein@ec=
itele.com


Mobile: +972-54-9266302


 
--_000_D007E362A9B54skrazaciscocom_-- --_004_D007E362A9B54skrazaciscocom_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: attachment; filename="~WRD000.jpg"; size=823; creation-date="Wed, 06 Aug 2014 17:56:52 GMT"; modification-date="Wed, 06 Aug 2014 17:56:52 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_004_D007E362A9B54skrazaciscocom_-- From nobody Thu Aug 7 03:10: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 D2CD21B27E2 for ; Thu, 7 Aug 2014 03:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy4FVDgfm6kU for ; Thu, 7 Aug 2014 03:10:09 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E811B2A3A for ; Thu, 7 Aug 2014 03:10:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s77A9x8H018933; Thu, 7 Aug 2014 11:09:59 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s77A9v3R018886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Aug 2014 11:09:58 +0100 From: "Adrian Farrel" To: "'Alexander Vainshtein'" , "'Kamran Raza \(skraza\)'" , "'Sami Boutros \(sboutros\)'" References: <2baf5ec74dbf42929b973c99cae1b1bd@AM3PR03MB612.eurprd03.prod.outlook.com> <02ca01cfabf6$7a2a70e0$6e7f52a0$@olddog.co.uk> <005401cfac43$e76b9f10$b642dd30$@olddog.co.uk>, <1407351683540.8563@ecitele.com> In-Reply-To: <1407351683540.8563@ecitele.com> Date: Thu, 7 Aug 2014 11:10:01 +0100 Message-ID: <00f001cfb227$c0f42c50$42dc84f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00F1_01CFB230.22C19500" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5dxMs+oaAUnzdi3sEUonP+cPrIwKFi4+cAi/ERhECBVKMYAEwHZfJAXe0I4CaJk1tcA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20864.006 X-TM-AS-Result: No--32.303-10.0-31-10 X-imss-scan-details: No--32.303-10.0-31-10 X-TMASE-MatchedRID: OoEa6u7Uk5/uYusHgJkgynPacKDoX0vPmLey3mPjJ/mNXnGEI3FAT/I1 J9MkzaLZt72M8lYD5n9cG2eGMs0H+hhTGJQ1M8K9TXnWmEdM1hGgvxJeels/vgkuiFJsQqORr04 EyThcV0N0SCCvyNWPlEd2G5hiQttMVV4ZZmbE3YwNgFUqZt55A/z4l62cQoyGrk1HLwYZu2RZxM IhkErUlos9DYogvyUcdc4udhrWYb5buDP8ZuCmXmWuy5Lm0L4/aYn7tXmtFzNkIBWzJX09HS9LN +axhmsOP9GCUtvlHNaOGtq4RwLbmQbXTLkHVoXVbt2yH3SWiGEUFDkgqWz8DhkBPnq+z+rcwYg6 IuVU8jN3EG58Ar3aQqOfOZHmSOFBEhGH3CRdKUUiRZHrLxuBABIQsvYTMyKwCf2h9A2gFAVVPQM Yc3iy3Px15EY4PiFA8AU0Pl71elVbIYYOiTp4jfcF8Z5bip17bT10UxwZWLCAvGIDnCswPV4ERJ C0jCZ7znBRWbeeTN/OlvT/PJ/pVWZUc2jtcaSdJVMDC8M9UM8chOq9qK+AGi670e2gJiRY+WXvs IYYZvWpfLBCJLeQYZ/JE/eOMuX3S8S2F9lkvO9DGFvBeB2nXEpv30toAMb6acZoEH0YEoQr1LDF 5Dz/8eCOXZO3Kxz/7bzFTf/STMoTRDzcDa8P66uNs95i0J2u0DSEazcOI6S4APs5ALP3U2EcVY/ f9sQKnvuBQNKB66Mgvdg/eFAc/qMVgdN9w+TClFphfRKYquqJ6icw2HMxECg5EdjA8p/c7MCcoN 96LGsnvOfC1B59NFhdPEiZHlm8zfzbRulu08fG0EHapv1eJ2RinB1Mnjd9lR1cT9YafQV95l0nV eyiuI6o3nt+c6PwNkn73uteOJnFtRvlK/5EblLyR7X954oxyxHtKAJx3reU+YYVW76NGk4dcGdc u9nUBD10iB+PZUCTthINKtOhR/5L8hbfzHmvZqsSYYGH2TvzDjQx++DkEiFdmu1docAZ Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/-xdpsD6J5LHSmZBXJ9ltKtuwyAo Cc: rtg-dir@ietf.org, draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt 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, 07 Aug 2014 10:10:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F1_01CFB230.22C19500 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00F2_01CFB230.22C1BC10" ------=_NextPart_001_00F2_01CFB230.22C1BC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Very grateful for the time and effort you all put into resolving this. Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 06 August 2014 20:02 To: Kamran Raza (skraza); Sami Boutros (sboutros) Cc: rtg-dir@ietf.org; draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; rtg-ads@tools.ietf.org; Adrian Farrel Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Kamran, Sami, Lots of thanks for your cooperation. I believe that we have successfully resolved all the remaining issues at our WebEx call today. I will be waiting for the next revision of the draft to formally confirm that. Adrian and all, It took more time than we originally planned - but we did it! Regards, Sasha _____ From: Kamran Raza (skraza) Sent: Wednesday, August 6, 2014 8:56 PM To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; Alexander Vainshtein; rtg-ads@tools.ietf.org Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hi Adrian, We (authors) just had a webex call with Sasha to discuss/close on his comments [ which we had also discussed over the email starting May ]. We all are in agreement/sync on the points that were raised during this review . Almost all, if not all, of the points/comments will be addressed by clarifying the scope of the extension in a new "Applicability" section with risk and recommendations highlighted. We will work on updating the draft and post a new rev shortly. We thank you Sasha for his detailed review and useful comments and thank you for your patience. - Kamran and Sami From: Adrian Farrel Reply-To: "adrian@olddog.co.uk" Date: Wednesday, July 30, 2014 at 6:16 PM To: Syed Kamran Raza Cc: "rtg-dir@ietf.org" , "Sami Boutros (sboutros)" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , 'Alexander Vainshtein' , "rtg-ads@tools.ietf.org" Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt This is very excellent. Thank you for going the extra mile to sort things out. A From: Kamran Raza (skraza) [mailto:skraza@cisco.com] Sent: 30 July 2014 19:00 To: adrian@olddog.co.uk Cc: rtg-dir@ietf.org; Sami Boutros (sboutros); draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander Vainshtein'; rtg-ads@tools.ietf.org Subject: Re: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Hi Adrian, Yes, authors wanted to have a f2f meeting with Sasha @ IETF but we had to schedule the meeting post IETF as Sasha did not attend. We are meeting tomorrow with Sasha to clarify/converge. Thanks. Kamran Raza TECHNICAL LEADER.ENGINEERING Product Development skraza@cisco.com Phone: +1 613 254 4520 Cisco.com Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, M5J 2T3. Phone: 416-306-7000; Fax: 416-306-7099. Preferences - Unsubscribe - Privacy Image removed by sender. Think before you print. This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Please click here for Company Registration Information. From: Adrian Farrel Reply-To: "adrian@olddog.co.uk" Date: Wednesday, July 30, 2014 at 9:02 AM To: Syed Kamran Raza Cc: "rtg-dir@ietf.org" , "Sami Boutros (sboutros)" , "draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" , 'Alexander Vainshtein' , "rtg-ads@tools.ietf.org" Subject: RE: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt Kamran, Thanks for responding to the question in the GenArt review. Do you have any responses to Sasha's review (copied below)? cheers, Adrian From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: 11 May 2014 15:09 To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (sboutros@cisco.com) Subject: RTG-DIR Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt 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. 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-ietf-mpls-ldp-ip-pw-capability-07.txt Reviewer: Alexander ("Sasha") Vainshtein Review date: 11-May-14 IETF LC End Date: 12-May-14 Intended status: Standards Track Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. These concerns mainly deal with potential negative impact of the mechanisms (introduced in the draft) for disabling "non-negotiable" capabilities of LDP sessions with the techniques that could dynamically change the state of "interest" in these capabilities for a given LDP session. Some of these mechanisms are already standardized by the IETF, e.g., L2VPN auto-discovery (RFC 6074 ) and dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw ) while others - LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa )- are in advanced stages of the IETF process. I must admit that I did not follow closely the discussion of the draft in question in the MPLS WG; so it may well be that some of my concerns have been already raised, considered and found not relevant. I also do not know if the draft has ever been discussed in the PWE3, L2VPN and RTG WGs. One possible way to address these concerns would be by adding an Applicability Statement section to the draft and discussing potentially problematic combinations of mechanisms there. I have discussed this option with the authors and, to the best of my understanding, they have in general agreed to add such a section to the next revision of the draft. General comments: To the best of my understanding the sole purpose of the draft is prevention of " wasteful" distribution of state dealing with two non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 and IPv6 prefixes defined in RFC 5036 ) and PW FECs (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447 ) to LDP peers that are "not interested' in this state. Such unnecessary distribution would result in unnecessary waste of resources (memory and/or CPU cycles) and hence should be avoided. The draft mentions that: To avoid this unnecessary state advertisement and exchange, currently an operator is typically required to configure and define filtering policies on the LSR, which introduces unnecessary operational overhead and complexity for such deployments. The draft, however, does not mention that filtering policies provide much finer granularity of control over distribution of labels than that supported by the mechanism introduced in the draft. E.g., in a scenario when LDP is supposed to set up only "tunnel LSPs" between PEs for L2 and L3 VPN applications, an appropriate policy allow distribution of the just the FECs associated with Router IDs of the PEs but not, say FECs associated with the subnets of their core-facing interfaces. IMHO and FWIW this means that support of the mechanism defined in the draft would not eliminate the need for the filtering policies. I have discussed this point with the authors and they have agreed to add some clarifying text. I have also failed to understand how distribution of PW FECs could be wasteful. Section 5.3.3 "Signaling Procedures" of RFC 4447 explicitly states that: In order for PE1 to begin signaling PE2, PE1 must know the address of the remote PE2, and a TAI. This information may have been configured at PE1, or it may have been learned dynamically via some autodiscovery procedure. The egress PE (PE1), which has knowledge of the ingress PE, initiates the setup by sending a Label Mapping Message to the ingress PE (PE2). My reading of the quoted text is that PW FECs are only distributed across targeted LDP sessions with the known Remote PEs for specific PWs. AFAIK, this is what actually happens in most existing implementations of PW signaling with RFC 4447. What's more, many implementations, when required to set up a PW with a specific remote PE, check for existence of a targeted LDP session with this PE, and set it up implicitly if it does not exist; then they distribute PW FEC-to-label binding via this session only. Implicit targeted LDP sessions are also implicitly torn down when the last PW between the given pair of PEs is torn down. I have discussed this point with the authors, but, as of the moment of writing this review, we did not yet reach full agreement on it. Readability of the draft: Initially I have failed to understand the following text fragment in the draft (the problematic statements are marked with italics): For Prefix-LSPs application type, the non-interesting state refers to any state related to IP Prefix FEC (such as FEC label bindings, LDP Status). This document, however, does not classify IP address bindings as a non-interesting state and allows the advertisement of IP Address bindings to facilitate other LDP applications (such as mLDP) that depend on learning of peer addresses over an LDP session for their correct operation. After discussing this point with the authors I've understood that they refer to exchange of the LSR addresses in the Address and Address Withdraw messages that is required for mapping Next Hop IP addresses computed by the IGP to Next Hop LSR. While initial misunderstanding may be specific to me, I have suggested to the authors to clarify this point with explicit references to specific LDP messages and sections of RFC 5036 . Major Issue: The draft, which builds on the mechanisms defined in RFC 5561 , defines two ways to manipulate distribution of "non-interesting state", since by default it would be enabled . In the Initialization message. I assume that in this case the only valid use case would be disabling distribution of non-interesting state . In the Capability message. This method could be both to disable and re-enable distribution of state, but it could only be used if the peer supports "Dynamic Announcement Capability". My concern stems from the fact that the draft deals with "old" LDP applications, so that the possibility that distribution of FEC-to-Label bindings can be unilaterally disabled for PW- and Prefix-FECs is not taken into account in the existing deployments and mechanisms. Here is a couple of examples: Consider the case when a targeted LDP session between PE1 and PE2 has been set just for the purpose of running ICCP between these devices (i.e., in the terms of the ICCP draft they belong to the same RG). According to the example in Section 5.1 of the draft, the PEs could then disable distribution of both PW FECs and Prefix-FECs across such a session in their appropriate Initialization messages. The following (valid from my point of view) scenarios would make such a setting highly problematic: 1. The operator that manages both PE1 and PE2: a. Maintains some VPLS instances in its network b. Initially maintains VPLS instances in both E1 and PE2, but without overlap between the sets of these instances (so that there is no need to setup PWs between PE1 and PE2) c. Uses BGP-based autodiscovery mechanisms for VPLS in its network as described in RFC 6074 d. Is required to extend one of the VPLS instances it maintains and that already has presence in PE1 to have presence also in PE2: i. With BGP-based autodiscovery, explicit configuration of just PE2 should suffice, the person (or management application) that extends this instance does not have to know about the rest of the locations where this VPLS instance is present ii. The autodiscovery process (which does not depend on LDP) identifies PE1 as a peer for the VPLS instance being defined in PE2, so that a PW between PE1 and PE2 is now required iii. The PW setup process finds a targeted LDP session between PE1 and PE2 and tries to use it for setting up the required PW iv. However, PW setup would fails because distribution of PW FECs across the already existing targeted LDP session between PE1 and PE2 has been disabled. e. If PE1 and PE2 support "Dynamic Capability Announcement", this could be amended by enabling distribution of PW FECs prior to setting the required PW. However, this would require substantial changes in the existing PW setup procedures f. If even one of the PEs does not support "Dynamic Capability Announcement", the existing targeted LDP session would have to be torn down and re-established again. This would probably have serious implications for the ICCP-based redundancy mechanism. 2. A similar scenario could be encountered if the operator employs dynamic setup of multi-segment PWs, and the PW routing mechanism decides that one of the segments of a new MS-PW to be set up should run between PE1 and PE2. Such a situation could be probably prevented if the PW routing mechanism could learn that PE1 and PE2 cannot be "directly connected", but, to the best of my understanding, it would require changes in the already standardized MS-PW routing mechanism. I have discussed these cases with the authors, but we have not reached an agreement on them yet. From my point of view, the Applicability Statement section should address these concerns. Consider now the case described in Section 5.2 of the draft, when a targeted LDP session between PE1 and PE2 is initially used just for distribution of setup of PWs, so that distribution of Prefix-FECs is disabled. The following (valid from my point of view) scenario would make such a setting highly problematic: 1. The operator uses LDP for setting "Tunnel LSPs" in its network 2. LFA-based LDP FRR (as per RFC 5286 and Remote LFA draft ) is used as the mechanism for fast protection in the operator's network. 3. Initially PE1 can protect all the LSPs passing through it using just local LFA. 4. The network topology changes (e.g., because new LSRs are added to it), and in order to provide the required coverage, PE1 has to use PE2 as its "remote LFA" for some destinations. a. This would require distribution of Prefix-FECs across the targeted LDP session between PE1 and PE2 - but it has been disabled b. If PE2 does not support "Dynamic Announcement Capability", then the only way to amend the situation would be to tear down the targeted LDP session between PE1 and PE2 and to set it up again - but this would negatively affect PW traffic between PE1 and PE2. I have discussed this case with the authors. To the best of my understanding, they have agreed that combining LDP FRR based on Remote LFAs with the mechanisms defined in the draft would be highly problematic, and will add some suitable text to the Applicability Statement section in the next revision of the draft. Minor Issues: 1. The draft states (in section 4.2) that desire of a given LSR of reception of unnecessary state from the peer is "unilateral and unidirectional by nature". a. IMO this makes perfect sense for Prefix-FECs. b. However, PW FECs must always be exchange in both directions of a targeted LDP session, so that disabling their distribution in just one direction would effectively prevent setup of PWs between the given pair of PEs 2. I concur with Adrian's comment in his AD review of the draft about proposed encoding of states of non-interest. 3. I also wonder whence the need for 16 potential states of non-interest in the draft that, to the best of my understanding, deals with exactly 4 "old" LDP applications. I hope that this does not imply possibility of developing new "old-style' LDP applications in future (or discovering some forgotten old ones?). I have not yet discussed these issues with the authors (as we concentrated on the major ones). Nits: None found by the IDNITS tool. Spelling and Grammar: I defer to the English Language review team. Hopefully these comments will be useful. Regards, Sasha Email: Alexander.Vainshtein@ecitele.com Mobile: +972-54-9266302 ------=_NextPart_001_00F2_01CFB230.22C1BC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Very grateful for the = time and effort you all put into resolving this.

 

Adrian

 

From: Alexander = Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: 06 = August 2014 20:02
To: Kamran Raza (skraza); Sami Boutros = (sboutros)
Cc: rtg-dir@ietf.org; = draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; = rtg-ads@tools.ietf.org; Adrian Farrel
Subject: RE: RTG-DIR = Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

Kamran, Sami,

Lots of thanks for your = cooperation.

I = believe that we have successfully resolved all the = remaining issues at our WebEx call today.

I will be waiting for the next = revision of the draft to formally = confirm that.

 

Adrian and all,

It took more time than we originally planned - = but we did it!

 

Regards,

Sasha  

From: Kamran = Raza (skraza) <skraza@cisco.com>
Sent: Wednesday, August = 6, 2014 8:56 PM
To: adrian@olddog.co.uk
Cc: = rtg-dir@ietf.org; Sami Boutros (sboutros); = draft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; Alexander = Vainshtein; rtg-ads@tools.ietf.org
Subject: Re: RTG-DIR = Review: draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

Hi Adrian,

 

We (authors) just had a webex call with Sasha to = discuss/close on his comments [ which we had also discussed over the = email starting May ].

We all are in agreement/sync on the points that were = raised during this review . Almost all, if not all,  of the = points/comments will be addressed by

clarifying the  scope of the extension in a new = “Applicability" section with risk and recommendations = highlighted.

 

We will work on updating the draft and post a new = rev shortly.

 

We thank you Sasha for his detailed review and = useful comments and thank you for your = patience.

—

Kamran and Sami

 

From: Adrian = Farrel <adrian@olddog.co.uk>
Rep= ly-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Dat= e: Wednesday, July 30, 2014 at 6:16 PM
To: Syed Kamran = Raza <skraza@cisco.com>
Cc: = "rtg-dir@ietf.org" = <rtg-dir@ietf.org>, = "Sami Boutros (sboutros)" <sboutros@cisco.com>, "d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" <d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, = 'Alexander Vainshtein' <Alexander.Vainshtein@eci= tele.com>, "rtg-ads@tools.ietf.org" = <rtg-ads@tools.ietf.org>
= Subject: RE: RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

This is very excellent. = Thank you for going the extra mile to sort things out.

 

A

 

From: Kamran Raza (skraza) [mailto:skraza@cisco.com] =
Sent: 30 July 2014 19:00
To: adrian@olddog.co.uk
Cc:= rtg-dir@ietf.org; Sami Boutros = (sboutros); d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; 'Alexander = Vainshtein'; rtg-ads@tools.ietf.org
S= ubject: Re: RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

Hi = Adrian,

 

Yes, = authors wanted to have a f2f meeting with Sasha @ IETF but we had to = schedule the meeting post IETF as Sasha did not attend.

We are = meeting tomorrow with Sasha to clarify/converge.

 

Thanks.

 

= Kamran Raza=
TECHNICAL LEADER.ENGINEERING
Product Development
skraza@c= isco.com
Phone: +1 613 254 = 4520

=
Cisco.co= m

 

Cisco Systems Canada Co, 181 Bay St., Suite 3400, Toronto, ON, Canada, = M5J 2T3. Phone: 416-306-7000; Fax: 416-306-7099.
Preferences - Unsubscribe – Privacy<= /a>
=
3D"Image Think before you = print.

= This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this = message.

= Please click = here for Company Registration = Information.

 

 

From: Adrian Farrel <adrian@olddog.co.uk>
Rep= ly-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Dat= e: Wednesday, July 30, 2014 at 9:02 AM
To: Syed Kamran = Raza <skraza@cisco.com>
Cc: = "rtg-dir@ietf.org" = <rtg-dir@ietf.org>, = "Sami Boutros (sboutros)" <sboutros@cisco.com>, "d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org" <d= raft-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org>, = 'Alexander Vainshtein' <Alexander.Vainshtein@eci= tele.com>, "rtg-ads@tools.ietf.org" = <rtg-ads@tools.ietf.org>
= Subject: RE: RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

Kamran,

 

Thanks for responding to the question in the = GenArt review.

 

Do you have any responses to Sasha's review = (copied below)?

 

cheers,

Adrian

 

From: Alexander Vainshtein [mailto:Alexander.Vainsht= ein@ecitele.com]
Sent: 11 May 2014 15:09
To: rtg-ads@tools.ietf.org
C= c: rtg-dir@ietf.org; = drafts-ietf-mpls-ldp-ip-pw-capability.all@tools.ietf.org; skraza@cisco.com; Sami Boutros (sboutros@cisco.com)
Subject:= RTG-DIR Review: = draft-ietf-mpls-ldp-ip-pw-capability-07.txt

 

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. 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-ietf-mpls-ldp-ip-pw-capability-07.txt

Reviewer: Alexander (“Sasha”) = Vainshtein   

Review date: 11-May-14

IETF LC End Date: 12-May-14

Intended status: Standards Track

 

Summary:

 

I have significant concerns about this document = and recommend that the Routing ADs discuss these issues further with the = authors.

These concerns mainly deal with potential = negative impact of the mechanisms (introduced in the draft) for = disabling “non-negotiable” capabilities of LDP sessions =  with the techniques that could dynamically change the state of = “interest” in these capabilities for a given LDP = session. 

Some of these mechanisms are already = standardized by the IETF, e.g.,   L2VPN auto-discovery (RFC 6074) and =  dynamic placement of multi-segment pseudo-wires (draft-ietf-pwe3-dynamic-ms-pw) while others - =  LDP FRR using remote loop-free adjacencies (draft-ietf-rtgwg-remote-lfa)- are in advanced stages = of the IETF process.   

 

 

I must admit that I did not follow closely the = discussion of  the draft in question in the MPLS WG; so it may well = be that some of my concerns have been already raised, considered and = found not relevant.

I also do not know if the draft has ever been = discussed in the PWE3, L2VPN and RTG WGs.

 

One possible way to address these concerns = would be by adding an Applicability Statement section to the draft and = discussing potentially problematic combinations of mechanisms = there.

I have discussed this option with the authors = and, to the best of my understanding, they have in general agreed to add = such a section to the next revision of the draft.

 

General comments:

To the best of my = understanding the sole purpose of the draft is  prevention of = “ wasteful” distribution of state dealing with two = non-negotiable classes of FECs: Prefix FECs (i.e., FECs defined by IPv4 = and IPv6 prefixes defined in RFC 5036) and PW FECs = (i.e. PW Id FEC and Generalized PW Id FEC defined in RFC 4447) to LDP peers = that are “not interested’ in this state. Such unnecessary = distribution would result in unnecessary waste of resources (memory = and/or CPU cycles) and hence should be avoided.  

 

The draft mentions = that:

<quote>

  To avoid this = unnecessary state advertisement and exchange, currently

  an operator is = typically required to configure and define filtering

  policies on the = LSR, which introduces unnecessary operational

  overhead and = complexity for such deployments. 

<end = quote>

 

The draft, however, does = not mention that filtering policies provide much finer granularity of = control over distribution of labels than that supported by the mechanism = introduced in the draft.

E.g., in a scenario when = LDP is supposed to set up only “tunnel LSPs” between PEs for = L2 and L3 VPN applications, an appropriate policy allow distribution of = the just the FECs associated with Router IDs of the PEs but not, say = FECs associated with the subnets of their core-facing interfaces. IMHO = and FWIW this means that support of the mechanism defined in the draft = would not eliminate the need for the filtering policies.

 

I have discussed this = point with the authors and they have agreed to add some clarifying = text.

 

I have also failed to = understand how distribution of PW FECs could be wasteful. Section 5.3.3 =  “Signaling Procedures” of RFC 4447 explicitly = states that:

<quote>

   In order for =
PE1 to begin signaling PE2, PE1 must know the address of
   the remote =
PE2, and a TAI.  This information may have been =
configured
   at PE1, or it =
may have been learned dynamically via some
   autodiscovery =
procedure.
 
   The egress PE =
(PE1), which has knowledge of the ingress PE, initiates
   the setup by =
sending a Label Mapping Message to the ingress PE (PE2).

<end = quote>

 

My reading of the quoted = text is that PW FECs are only distributed across targeted LDP sessions = with the known Remote PEs for specific PWs.

AFAIK, this is what = actually happens in most existing implementations of PW signaling with = RFC 4447.

What’s more, many = implementations, when required to set up a PW with a specific remote PE, = check for existence of a targeted LDP session with this PE, and set it = up implicitly if it does not exist; then they distribute PW FEC-to-label = binding via this session only. Implicit targeted LDP sessions are also = implicitly torn down when the last PW between  the given pair of = PEs is torn down.

I have discussed this = point with the authors, but, as of the moment of writing this review, =  we did not yet reach full agreement on it.  

 

Readability of the = draft:

 

Initially I have failed to = understand the following text fragment in the draft (the problematic = statements are marked with italics):

<quote>

   For =
Prefix-LSPs application type, the non-interesting state refers =

   to any =
state related to IP Prefix FEC (such as FEC label bindings, 
   LDP =
Status). This document, however, does not classify IP address =

   bindings =
as a non-interesting state and allows the advertisement of =

   IP =
Address bindings to facilitate other LDP applications (such as =

   mLDP) =
that depend on learning of peer addresses over an LDP session =

   for =
their correct operation.

<end = quote>

After discussing this = point with the authors I’ve understood that they refer to exchange = of the LSR addresses in the Address and Address Withdraw = messages that is required for mapping Next Hop IP addresses = computed by the IGP to Next Hop LSR. While initial misunderstanding may = be specific to me,  I have suggested to the authors to clarify this = point with explicit references to specific LDP messages and sections of = RFC 5036.

 

Major = Issue:

 

The draft, which builds on = the mechanisms defined in RFC = 5561,  defines two ways to manipulate distribution of = “non-interesting state”, since by default it would be = enabled

·   &nb= sp;     In the Initialization = message. I assume that in this case the only valid use case would be = disabling distribution of non-interesting state

·   &nb= sp;     In the Capability message. = This method could be both to disable and re-enable distribution of = state, but it could only be used if the peer supports “Dynamic = Announcement Capability”.

 

My concern stems from the = fact that the draft deals with “old” LDP applications, so = that the possibility that distribution of FEC-to-Label bindings can be = unilaterally disabled for PW- and Prefix-FECs is not taken into account = in the existing deployments and mechanisms.

 

Here is a couple of = examples:

 

Consider the case when a = targeted LDP session between PE1 and PE2 has been set just for the = purpose of running ICCP between these devices (i.e., in the terms of the = ICCP draft they belong to the same RG). According to the example in = Section 5.1 of the draft, the PEs could then disable distribution of = both PW FECs and Prefix-FECs across such a session in their appropriate = Initialization messages.

 

The following (valid from = my point of view) scenarios would make such a setting highly = problematic:

1.   &nb= sp;   The operator that manages = both PE1 and PE2:

a.   &nb= sp;   Maintains some  VPLS = instances in its network

b.   &nb= sp;  Initially maintains VPLS = instances in both E1 and PE2, but without overlap between the sets of = these instances (so that there is no need to setup PWs between PE1 and = PE2)

c.   &nb= sp;   Uses BGP-based = autodiscovery mechanisms for VPLS in its network as described in RFC = 6074

d.   &nb= sp;  Is required to extend one = of the VPLS instances it maintains and that already has presence in PE1 = to have presence also in PE2:

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           = i.   &nb= sp;  With BGP-based = autodiscovery, explicit configuration of just PE2 should suffice, the = person (or management application) that extends this instance does not = have to know about the rest of the locations where this VPLS instance is = present

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;          ii.   &nb= sp;  The autodiscovery process = (which does not depend on LDP) identifies PE1 as a peer for the VPLS = instance being defined in PE2, so that a PW between PE1 and PE2 is now = required

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        iii.   &nb= sp;  The PW setup process finds = a targeted LDP session between PE1 and PE2 and tries to use it for = setting up the required PW

   &nb= sp;           &nbs= p;            = ;            =             &= nbsp;        iv.   &nb= sp;  However, PW setup would = fails because distribution of PW FECs across the already existing = targeted LDP session between PE1 and PE2 has been disabled.

e.   &nb= sp;  If PE1 and PE2 support = “Dynamic Capability Announcement”, this could be amended by = enabling distribution of PW FECs prior to setting the required PW. = However, this would require substantial changes in the existing PW setup = procedures

f.   &nb= sp;    If even one of the PEs = does not support “Dynamic Capability Announcement”, the = existing targeted LDP session would have to be torn down and = re-established again. This would probably have serious implications for = the ICCP-based redundancy mechanism.

2.   &nb= sp;   A similar scenario could = be encountered if the operator employs dynamic setup of multi-segment = PWs, and the PW routing mechanism decides that one of the segments of a = new MS-PW to be set up should run between PE1 and PE2.   Such = a situation could be probably prevented if the PW routing mechanism = could learn that PE1 and PE2 cannot be “directly connected”, = but, to the best of my understanding, it would require changes in the = already standardized MS-PW routing mechanism.

 

I have discussed these = cases with the authors, but we have not reached an agreement on them = yet. From my point of view, the Applicability Statement section should = address these concerns.

 

Consider now the case = described in Section 5.2 of the draft, when a targeted LDP session = between PE1 and PE2 is initially used just for distribution of setup of = PWs, so that distribution of Prefix-FECs is disabled.

 

The following (valid from = my point of view) scenario would make such a setting highly = problematic:

1.   &nb= sp;   The operator uses LDP for = setting “Tunnel LSPs” in its network

2.   &nb= sp;   LFA-based LDP FRR (as per = RFC = 5286 and Remote LFA draft) is used as the mechanism for fast = protection in the operator’s network.

3.   &nb= sp;   Initially PE1 can protect = all the LSPs passing through it using just local LFA.

4.   &nb= sp;   The network topology = changes (e.g., because new LSRs are added to it), and in order to = provide the required coverage, PE1 has to use PE2 as its “remote = LFA” for some destinations.

a.   &nb= sp;   This would require = distribution of Prefix-FECs across the targeted LDP session between PE1 = and PE2 – but it has been disabled

b.   &nb= sp;  If PE2 does not support = “Dynamic Announcement Capability”, then the only way to = amend the situation would be to tear down the targeted LDP session = between PE1 and PE2 and to set it up again – but this would = negatively affect PW traffic between PE1 and PE2.

 

I have discussed this case = with the authors. To the best of my understanding, they have agreed that = combining LDP FRR based on Remote LFAs with the mechanisms defined in = the draft would be highly problematic, and will add some suitable text = to the Applicability Statement section in the next revision of the = draft.

 

 

Minor = Issues:

 

1.       = The draft states (in = section 4.2) that desire of a given LSR  of reception of = unnecessary state from the peer is “unilateral and unidirectional = by nature”.

a.       = IMO this makes perfect = sense for Prefix-FECs.

b.      However, PW = FECs must always be exchange in both directions of  a targeted LDP = session, so that disabling their distribution in just one direction = would effectively prevent setup of PWs between the given pair of = PEs

2.       = I concur with = Adrian’s comment in his AD review of the draft about proposed = encoding of states of non-interest.

3.       =  I also wonder whence = the need for 16 potential states of non-interest in the draft that, = to the best of my understanding, deals with exactly 4 “old” = LDP applications. I hope that this does not imply possibility of = developing new “old-style’ LDP applications in future (or = discovering some forgotten old ones?).

 

I have not yet discussed = these issues with the authors (as we concentrated on the major = ones).

 

Nits:

None found by the IDNITS = tool.

 

 

Spelling and = Grammar:

I defer to the English = Language review team.

 

Hopefully these comments = will be useful.

 

Regards,

    &nb= sp;  Sasha

Email: Alexander.Vainshtein@eci= tele.com

Mobile: = +972-54-9266302

 

------=_NextPart_001_00F2_01CFB230.22C1BC10-- ------=_NextPart_000_00F1_01CFB230.22C19500 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== ------=_NextPart_000_00F1_01CFB230.22C19500-- From nobody Fri Aug 8 08:04: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 7ABC21B2C31; Fri, 8 Aug 2014 08:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.702 X-Spam-Level: X-Spam-Status: No, score=0.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=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 wNBgJB3LqGVa; Fri, 8 Aug 2014 08:04:35 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA011B2C2D; Fri, 8 Aug 2014 08:04:35 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id z10so7192917pdj.2 for ; Fri, 08 Aug 2014 08:04:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:mime-version:message-id:content-type; bh=vEATZZqdjzN+1yG7/hcqqxHwQzkK3tN0rYLxOh/GvQU=; b=Tutq1vXA+EPl09ryBV2UNw0KD1mDPS9OzXNNc5Wibc1Uz/WWMci0p58ER6kRZl9KwD QlYXJeR9O2eiQNsxS3ERFit98Nsgy5NpXzm5rH7yb2a2cb0jxyeZnRwndvr2ibUTHjE2 7AsCkCAchKN383Hg/7rLmPYuObyXRSQU9wpAkaXYyoWS7wnI3XdR7auQN8fDHhNhu9pU K//0IP1JKCKCcTdGMHAes8KqusQ4b8zTTnMB7N3uEukZNP5R85XenzYG+JHc1cq2oce4 oxkZbtc7ZztMkmrZ0w9rMIvxi+eIVQYxP30NRVvnOGb8EczjkzmiJCmerxwz4j7TIvKK H1lg== X-Received: by 10.70.118.9 with SMTP id ki9mr24843304pdb.104.1407510274971; Fri, 08 Aug 2014 08:04:34 -0700 (PDT) Received: from Lizhong-PC ([114.62.200.249]) by mx.google.com with ESMTPSA id qt2sm3283511pbb.29.2014.08.08.08.04.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Aug 2014 08:04:34 -0700 (PDT) Date: Fri, 8 Aug 2014 23:04:32 +0800 From: "Lizhong Jin" To: rtg-ads X-Priority: 3 X-GUID: 7AB829CD-0C92-4D4B-AEFF-DB1711572CCD X-Has-Attach: no X-Mailer: Foxmail 7, 2, 5, 136[cn] Mime-Version: 1.0 Message-ID: <2014080822341929710226@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart125340167708_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/47FTMApsUXflsEOmaQC0_HImTEU Cc: draft-ietf-mpls-mldp-in-band-wildcard-encoding , rtg-dir , mpls Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.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: Fri, 08 Aug 2014 15:04:38 -0000 This is a multi-part message in MIME format. ------=_001_NextPart125340167708_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8NCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHJl dmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0byBy ZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBhc3Mg dGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24g c3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUg YXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91 dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSDigItodHRwOi8vdHJhYy50b29s cy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kvUnRnRGlyDQpBbHRob3VnaCB0aGVzZSBjb21t ZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291 bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBv dGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBhbmQgc3RyaXZl IHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRpbmcgdGhlIGRy YWZ0Lg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtbXBscy1tbGRwLWluLWJhbmQtd2lsZGNhcmQtZW5j b2RpbmctMDEgKG1MRFAgSW4tQmFuZCBTaWduYWxpbmcgd2l0aCBXaWxkY2FyZHMpDQpSZXZpZXdl cjogTGl6aG9uZyBKaW4NClJldmlldyBEYXRlOiBBdWcuIDgsIDIwMTQuDQpJRVRGIExDIEVuZCBE YXRlOiBBdWcuIDgsIDIwMTQuDQpJbnRlbmRlZCBTdGF0dXM6IFN0YW5kYXJkcyBUcmFjaw0KU3Vt bWFyeToNCkkgaGF2ZSBzb21lIG1pbm9yIGNvbmNlcm5zIGFib3V0IHRoaXMgZG9jdW1lbnQgdGhh dCBJIHRoaW5rIHNob3VsZCBiZSByZXNvbHZlZCBiZWZvcmUgcHVibGljYXRpb24uDQoNCkNvbW1l bnRzOg0KQmVmb3JlIFdHIGRyYWZ0IGFkb3B0aW9uLCBJIGFsc28gcmV2aWV3ZWQgdGhpcyBkcmFm dCBhcyBNUExTIFJUIHJldmlldy4gVGhpcyBkcmFmdCBzb2x2ZXMgYSByZWFsIHByb2JsZW0sIGFu ZCBpdCBpcyBlYXN5IHRvIHJlYWQgYW5kIHVuZGVyc3RhbmQuIEkgb25seSBoYXZlIHNvbWUgbWlu b3IgY29uY2VybnMgYW5kIHNvbWUgZWRpdG9yaWFsIGlzc3Vlcy4gDQoNCk1ham9yIElzc3VlczoN Ck5vbmUuDQoNCk1pbm9yIElzc3VlczogDQpTZWN0aW9uIDEgDQpXaGVuIGFuIE1QLUxTUCBpcyBi ZWluZyBzZXQgdXAsIHRoZSBwcm9jZWR1cmVzIG9mIFtSRkM2ODI2XSBhbmQgDQpbSS1ELmlldGYt bDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmddICwga25vd24gYXMgIm1MRFAgSW4tQmFu ZCANClNpZ25hbGluZyIsIGFsbG93IHRoZSBFZ3Jlc3MgTFNScyBvZiB0aGUgTVAtTFNQIHRvIGVu Y29kZSB0aGUgDQppZGVudGlmaWVyIG9mIGFuIElQIG11bHRpY2FzdCB0cmVlIGluIHRoZSAiT3Bh cXVlIFZhbHVlIiBmaWVsZCBvZiB0aGUgDQptTERQIEZFQyBFbGVtZW50IHRoYXQgaWRlbnRpZmll cyB0aGUgTVAtTFNQLiANCltMaXpob25nXSBUaGUgcmVmZXJlbmNlIFtJLUQuaWV0Zi1sM3Zwbi1t bGRwLXZyZi1pbi1iYW5kLXNpZ25hbGluZ10gc2hvdWxkIGJlIG1vdmVkIHRvIHRoZSBuZXh0IHNl Y3Rpb24sIHJpZ2h0PyBUaGlzIHNlY3Rpb24gaXMgdGFsa2luZyBhYm91dCBSRkM2ODI2LiANCg0K U2VjdGlvbiAzLjIgDQpQbGVhc2Ugbm90ZSB0aGF0LCBhcyBhbHdheXMsIHRoZSBzdHJ1Y3R1cmUg b2YgdGhlIE9wYXF1ZSANClZhbHVlIFRMVnMgZG9lcyBub3QgYWN0dWFsbHkgYWZmZWN0IHRoZSBv cGVyYXRpb24gb2YgbUxEUCwgYnV0IG9ubHkgDQphZmZlY3RzIHRoZSBpbnRlcmZhY2UgYmV0d2Vl biBtTERQIGFuZCBJUCBtdWx0aWNhc3QgYXQgdGhlIEluZ3Jlc3MgDQpMU1IuIA0KW0xpemhvbmdd IHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBtTERQIGFuZCBJUCBtdWx0aWNhc3QgYXQgdGhlIGVncmVz cyBMU1IgaXMgYWxzbyBhZmZlY3RlZC4gU28gaXQgaXMgYmV0dGVyIHRvIHNheSAiLi4uYXQgdGhl IEluZ3Jlc3MgYW5kIEVncmVzcyBMU1IiLiANCg0KU2VjdGlvbiAzLjIgDQpOb3RlIHRoYXQgdGhl IEJpZGlyIFRMVnMgZG8gbm90IGhhdmUgYSAiU291cmNlIEFkZHJlc3MiIHN1Yi1maWVsZCwgDQph bmQgaGVuY2UgdGhlIG5vdGlvbiBvZiBhIHdpbGRjYXJkIHNvdXJjZSBpcyBub3QgYXBwbGljYWJs ZSB0byB0aGVtLiANCltMaXpob25nXSBzaW5jZSBCaWRpciBUTFYgaXMgb3V0IG9mIHRoZSBzY29w ZSwgdGhlbiBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIGhhdmUgdGhlIGFib3ZlIG5vdGUuIA0KDQpT ZWN0aW9uIDMuMyANCkhvd2V2ZXIsIGlmIGFuIEluZ3Jlc3MgTFNSIHN1cHBvcnRzIA0KW1JGQzY4 MjZdIGFuZC9vciBbSS1ELmlldGYtbDN2cG4tbWxkcC12cmYtaW4tYmFuZC1zaWduYWxpbmddLCBi dXQgDQpkb2VzIG5vdCBzdXBwb3J0IHRoaXMgZG9jdW1lbnQsIGl0IGhhcyBubyBjaG9pY2UgYnV0 IHRvIHRyZWF0IGFueSANCnN1Y2ggcmVjZWl2ZWQgRkVDIGVsZW1lbnRzIGFzIGludmFsaWQ7IHRo ZSBwcm9jZWR1cmVzIHNwZWNpZmllZCBpbiANCltSRkM2ODI2XSBhbmQgW0ktRC5pZXRmLWwzdnBu LW1sZHAtdnJmLWluLWJhbmQtc2lnbmFsaW5nXSBkbyBub3Qgd29yayANCndoZW4gdGhlIE9wYXF1 ZSB2YWx1ZXMgY29udGFpbiB6ZXJvZXMgaW4gdGhlIFNvdXJjZSBBZGRyZXNzIG9yIEdyb3VwIA0K QWRkcmVzcyBzdWItZmllbGRzLiANCltMaXpob25nXSBJIHdlbnQgdGhyb3VnaHQgUkZDNjgyNiBh bmQgUkZDNzI0NiwgdGhlcmUgaXMgbm8gZGVmaW5pdGlvbiBvZiAiemVyb2VzIi4gVGhlbiB0aGUg YWJvdmUgc3RhdGVtZW50IHdpbGwgYmUgdHJlYXRlZCBhcyBhbiB1cGRhdGUgdG8gUkZDNjgyNiBh bmQgUkZDNzI0Ni4gSWYgdGhhdCBpcyB0cnVlLCB0aGVuIHRoZSBkcmFmdCBoZWFkZXIgbmVlZHMg dG8gaW5kaWNhdGUgdGhhdCB1cGRhdGUuIA0KDQpTZWN0aW9uIDUuIA0KSWYgUElNIGlzIG5vdCBl bmFibGVkIGZvciB0aGUgaWRlbnRpZmllZCBncm91cCwgdGhlIEluZ3Jlc3MgTFNSIA0KYWN0cyBh cyBpZiBpdCBoYWQgcmVjZWl2ZWQgYSAoKixHKSBJR01QL01MRCByZXBvcnQgZnJvbSBhIA0KZG93 bnN0cmVhbSBub2RlLCBhbmQgdGhlIHByb2NlZHVyZXMgYXMgZGVmaW5lZCBpbiBbUkZDNDYwNV0g YXJlIA0KZm9sbG93ZWQuDQpbTGl6aG9uZ10gSXQgc2VlbXMgdGhlIGRhdGFwbGFuZSBwcm9jZXNz aW5nIGlzIG1pc3NpbmcgaGVyZS4gRS5nLiwgYWRkIHNvbWV0aGluZyBsaWtlLCB0aGUgaW5ncmVz cyBMU1Igc2hvdWxkIGZvcndhcmQgdGhlIHNwZWNpZmllZCBtdWx0aWNhc3Qgc3RyZWFtIHRvIHRo ZSBkb3duc3RyZWFtIG5vZGUgdGhyb3VnaCB0aGUgTVAtTFNQIGlkZW50aWZpZWQgYnkgdGhlIE9w YXF1ZSBWYWx1ZSBUTFYuIFRoYXQgaXMgbm90IGRlc2NyaWJlZCBpbiBSRkM0NjA1Lg0KDQpOaXRz Og0KU2VjdGlvbiAxLg0Kcy91c2luZy91c2UNCg0KU2VjdGlvbiAxIGlzIGEgYml0IHRvbyBsb25n LCBhbmQgaW5jbHVkZSBib3RoIGludHJvZHVjdGlvbiBhbmQgcHJvYmxlbSBzdGF0ZW1lbnQuIEl0 IGlzIHN1Z2dlc3RlZCB0byBzZXBhcmF0ZSB0d28gc2VjdGlvbnMuIEJ1dCBJIHdpbGwgbm90IG9i amVjdCBpZiB5b3Ugd2FudCB0byBrZWVwIGl0LiANCg0KU2VjdGlvbiA0LjINCnMvbmVzc2VzYXJ5 L25lY2Vzc2FyeQ0KIA0KUmVnYXJkcw0KTGl6aG9uZyBKaW4NCg== ------=_001_NextPart125340167708_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A
=

Hello

I hav= e been selected as the Routing Directorate reviewer for this draft. The Ro= uting Directorate seeks to review all routing or routing-related drafts as= they pass through IETF last call and IESG review, and sometimes on specia= l request. The purpose of the review is to provide assistance to the Routi= ng ADs.  For more information about the Routing Directorate, please s= ee =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

Although these= comments are primarily for the use of the Routing ADs, it would be helpfu= l 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 upda= ting the draft.

Documen= t: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01 (mLDP In-Band Signaling with Wildcards)
= Reviewer: Lizhong Jin
Review Date: Aug. 8, 2014.
IETF LC End Date: A= ug. 8, 2014.
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I thi= nk should be resolved before publication.

<= br>

Comments:

Before WG draft adoption, I also reviewed this draft as MPLS RT = review. This draft solves a real problem, and it is easy to read and under= stand. I only have some minor concerns and some editorial issues. 


Major Issues:

None.

Minor Issues: 

Section 1=0A
When an MP-LSP is being set up, the procedures of [RFC6= 826] and=0A
[I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "= mLDP In-Band=0A
Signaling", allow the Egress LSRs of the MP-LSP to e= ncode the=0A
identifier of an IP multicast tree in the "Opaque Value= " field of the=0A
mLDP FEC Element that identifies the MP-LSP.=0A[Lizhong] The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] shoul= d be moved to the next section, right? This section is talking about RFC68= 26.=0A
=0A
Section 3.2=0A
Please note that, as always, the struct= ure of the Opaque=0A
Value TLVs does not actually affect the operati= on of mLDP, but only=0A
affects the interface between mLDP and IP mu= lticast at the Ingress =0A
LSR.=0A
[Lizhong] the interface betwee= n mLDP and IP multicast at the egress LSR is also affected. So it is bette= r to say "...at the Ingress and Egress LSR".=0A
=0A
Section 3.2=0A Note that the Bidir TLVs do not have a "Source Address" sub-field,=0A=
and hence the notion of a wildcard source is not applicable to them= .=0A
[Lizhong] since Bidir TLV is out of the scope, then it is not nece= ssary to have the above note.=0A
=0A
Section 3.3=0A
However, if a= n Ingress LSR supports=0A
[RFC6826] and/or [I-D.ietf-l3vpn-mldp-vrf-= in-band-signaling], but=0A
does not support this document, it has no= choice but to treat any=0A
such received FEC elements as invalid; t= he procedures specified in=0A
[RFC6826] and [I-D.ietf-l3vpn-mldp-vrf= -in-band-signaling] do not work=0A
when the Opaque values contain ze= roes in the Source Address or Group=0A
Address sub-fields.=0A
[Li= zhong] I went throught RFC6826 and RFC7246, there is no definition of "zer= oes". Then the above statement will be treated as an update to RFC6826 and= RFC7246. If that is true, then the draft header needs to indicate that up= date.=0A
=0A
Section 5.=0A
If PIM is= not enabled for the identified group, the Ingress LSR 

= acts as if it had received a (*,G) IGMP/MLD report from a=0A
= downstream node, and the procedures as defined in [RFC4605] are=0A
= followed.

[Lizhong] It seems the dataplane p= rocessing is missing here. E.g., add something like, the ingress LSR shoul= d forward the specified multicast stream to the downstream node through th= e MP-LSP identified by the Opaque Value TLV. That is not = described in RFC4605.

=0A


Nits:

Section 1.

s/using/use

Section 1 is a bit too long, and = include both introduction and problem statement. It is suggested to separa= te two sections. But I will not object if you want to keep it. 


Section 4.2

s/nessesary/necessary

<= p class=3D"MsoCommentText" style=3D"margin: 0px 0cm; font-size: 10.5pt; fo= nt-family: Calibri, sans-serif;"> 

=0A
=0A
=0A
= Regards
Lizhong= Jin
=0A ------=_001_NextPart125340167708_=------ From nobody Sat Aug 9 23:02: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 A6A3C1A064D; Sat, 9 Aug 2014 23:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 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, 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 I7HVR9UNt7i2; Sat, 9 Aug 2014 23:02:37 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE5F1A064B; Sat, 9 Aug 2014 23:02:37 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id ey11so9290578pad.24 for ; Sat, 09 Aug 2014 23:02:36 -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=MqcGKxiL151WCv0IF0Il17Wj6cKk7Ih7o+YKKOIC41g=; b=Dbu7GTzSj8FHOYqS8Q7YiB4EZQGnxzSS9gvtKv/WmqC1f59buCReVcaNOSrEkmN5fb MwN/MlYKB92r6WIW8Zi6orWhvUyeIL4lj/mhLXLYvbhVoPRJf7aABgNrpDfpEeMTPM29 BbUcd05sy0uiCWY4H1odonWvHUW457ak3pcIzjZgEHPuM1bxFvE0Ar5TLLdKHle+uI8b aRWbem4CUhkfu1v3ZuWp1ztUYJw+uIcaUsBnKLZG7hSrwESdgIbnmmuh7lhGwysYZ7dc b9F6KtmTGQUwJkJknUwxFgX5RqrudzUNFVqNv1lkmFY7j1HsM1sdlOGKgdbkp4zPHk1T e/5Q== X-Received: by 10.69.31.234 with SMTP id kp10mr91592pbd.138.1407650556713; Sat, 09 Aug 2014 23:02:36 -0700 (PDT) Received: from LIZHONGJ ([140.206.240.94]) by mx.google.com with ESMTPSA id h10sm43391190pat.11.2014.08.09.23.02.32 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Aug 2014 23:02:35 -0700 (PDT) From: "Lizhong Jin" To: References: Your message of Fri, 08 Aug 2014 23:04:32 +0800. <2014080822341929710226@gmail.com> <15748.1407626562@erosen-lnx> In-Reply-To: <15748.1407626562@erosen-lnx> Date: Sun, 10 Aug 2014 14:02:24 +0800 Message-ID: <00de01cfb460$ad881330$08983990$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFIqxe5Dba3fqCarBZcv6GMRQA8ApzXZMYQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/SjqvabLOHD6W9dKqQ7xNRuJof-w Cc: 'draft-ietf-mpls-mldp-in-band-wildcard-encoding' , 'rtg-dir' , 'mpls' , 'rtg-ads' Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.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: Sun, 10 Aug 2014 06:02:39 -0000 Hi Eric, Thanks for the prompt reply. See inline below. Regards Lizhong > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 2014=C4=EA8=D4=C210=C8=D5 7:23 > To: Lizhong Jin > Cc: rtg-ads; draft-ietf-mpls-mldp-in-band-wildcard-encoding; rtg-dir; = mpls > Subject: Re: [mpls] RtgDir review: = draft-ietf-mpls-mldp-in-band-wildcard- > encoding-01.txt >=20 > Many thanks for your review and comments! >=20 > Section 1 >=20 > When an MP-LSP is being set up, the procedures of [RFC6826] and > [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "mLDP = In-Band > Signaling", allow the Egress LSRs of the MP-LSP to encode the identifier > of an IP multicast tree in the "Opaque Value" field of the mLDP = FEC > Element that identifies the MP-LSP. >=20 > Lizhong> The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] > Lizhong> should be moved to the next section, right? This section is > Lizhong> talking about RFC6826. >=20 > I think the material in this paragraph is applicable in VRF context as well as in > non-VRF context. Thus it is appropriate to reference both RFC 6826 = (which > discusses in-band signaling in non-VRF context) and RFC 7246 (formerly draft- > ietf-l3vpn-mldp-vrf-in-band-signaling), which discusses in-band = signaling in > VRF context. >=20 > The material in the following paragraph only applies in VRF context. = I will add > a reference to RFC 7246 to that paragraph. [Lizhong] OK >=20 >=20 > Section 3.2 >=20 > Please note that, as always, the structure of the Opaque Value = TLVs does > not actually affect the operation of mLDP, but only affects the > interface between mLDP and IP multicast at the Ingress LSR. >=20 > Lizhong> the interface between mLDP and IP multicast at the egress LSR > Lizhong> is also affected. So it is better to say "...at the Ingress = and > Lizhong> Egress LSR". >=20 > How about: >=20 > Please note that, as always, the structure of an Opaque Value TLV = does > not affect the operation of mLDP. The structure is meaningful = only to > the IP multicast modules at the ingress and egress LSRs. [Lizhong] OK with that. >=20 >=20 > Section 3.2 >=20 > Note that the Bidir TLVs do not have a "Source Address" sub-field, = and > hence the notion of a wildcard source is not applicable to them. >=20 > Lizhong> since Bidir TLV is out of the scope, then it is not necessary > Lizhong> to have the above note. >=20 > Section 3.2 states earlier that procedures for the use of the wildcard group in > the Bidir TLVs are out of scope. The sentence cited above says that = the Bidir > TLVs cannot have a wildcard source. I think it is useful to make both > statements, since neither one implies the other. [Lizhong] OK >=20 > Section 3.3 >=20 > However, if an Ingress LSR supports [RFC6826] and/or > [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but does not support = this > document, it has no choice but to treat any such received FEC = elements > as invalid; the procedures specified in [RFC6826] and > [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work when the Opaque > values contain zeroes in the Source Address or Group Address sub-fields. >=20 > Lizhong> I went throught RFC6826 and RFC7246, there is no definition = of > Lizhong> "zeroes". Then the above statement will be treated as an = update > Lizhong> to > Lizhong> RFC6826 and RFC7246. If that is true, then the draft header > Lizhong> needs to indicate that update. >=20 > I believe you are correct. I will add this to the draft header and = the abstract. [Lizhong] OK >=20 > Section 5. >=20 > If PIM is not enabled for the identified group, the Ingress LSR = acts as > if it had received a (*,G) IGMP/MLD report from a downstream node, = and > the procedures as defined in [RFC4605] are followed. >=20 > Lizhong> It seems the dataplane processing is missing here. E.g., add > Lizhong> something like, the ingress LSR should forward the specified > Lizhong> multicast stream to the downstream node through the MP-LSP > Lizhong> identified by the Opaque Value TLV. That is not described in > Lizhong> RFC4605. >=20 > This is discussed in section 4.2 of the document; I think it will be adequate to > just add a reference here to section 4.2. [Lizhong] The description in section 4.2 is also implicit for the packet forwarding behavior. Did I miss something? Section 6 has very clear description:=20 All these streams SHOULD be forwarded down the MP-LSP identified by the Opaque Value TLV. Regards Lizhong From nobody Mon Aug 11 01:20: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 E04131A03AA; Sat, 9 Aug 2014 16:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.469 X-Spam-Level: X-Spam-Status: No, score=-12.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 vJgZiz0LbFWM; Sat, 9 Aug 2014 16:22:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BC21A03A9; Sat, 9 Aug 2014 16:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3681; q=dns/txt; s=iport; t=1407626564; x=1408836164; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=0dDeHoJOwVBj39qeOurbrc9D2/15AJtk4jgbuqbHTaQ=; b=ALm7ClWaeNeGSGSrOTeF9ctjWU71ytiGfehXcn72gBb3dYNbVEj2WnHg wxeZuTr53S/N9ZidYMAkVAFnn06wNxnVex3fB8EqybjunXl+GLkPMysme EllusaGJ+m8CaxP8YWYbBhXxv5kEu3cdlywNgydjsCSJYyL74LPSRFKwW 0=; X-IronPort-AV: E=Sophos;i="5.01,834,1400025600"; d="scan'208";a="346356153" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 09 Aug 2014 23:22:43 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s79NMhpq015675; Sat, 9 Aug 2014 23:22:43 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id E8FF6748; Sat, 9 Aug 2014 19:22:42 -0400 (EDT) From: Eric Rosen To: Lizhong Jin In-reply-to: Your message of Fri, 08 Aug 2014 23:04:32 +0800. <2014080822341929710226@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15747.1407626562.1@erosen-lnx> Date: Sat, 09 Aug 2014 19:22:42 -0400 Message-ID: <15748.1407626562@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/OfxmE5kr5DRzoHKWKz2eM2jo3FY X-Mailman-Approved-At: Mon, 11 Aug 2014 01:20:15 -0700 Cc: draft-ietf-mpls-mldp-in-band-wildcard-encoding , rtg-dir , mpls , rtg-ads Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 23:22:50 -0000 Many thanks for your review and comments! Section 1 When an MP-LSP is being set up, the procedures of [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] , known as "mLDP In-Band Signaling", allow the Egress LSRs of the MP-LSP to encode the identifier of an IP multicast tree in the "Opaque Value" field of the mLDP FEC Element that identifies the MP-LSP. Lizhong> The reference [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] should be Lizhong> moved to the next section, right? This section is talking about Lizhong> RFC6826. I think the material in this paragraph is applicable in VRF context as well as in non-VRF context. Thus it is appropriate to reference both RFC 6826 (which discusses in-band signaling in non-VRF context) and RFC 7246 (formerly draft-ietf-l3vpn-mldp-vrf-in-band-signaling), which discusses in-band signaling in VRF context. The material in the following paragraph only applies in VRF context. I will add a reference to RFC 7246 to that paragraph. Section 3.2 Please note that, as always, the structure of the Opaque Value TLVs does not actually affect the operation of mLDP, but only affects the interface between mLDP and IP multicast at the Ingress LSR. Lizhong> the interface between mLDP and IP multicast at the egress LSR is Lizhong> also affected. So it is better to say "...at the Ingress and Egress Lizhong> LSR". How about: Please note that, as always, the structure of an Opaque Value TLV does not affect the operation of mLDP. The structure is meaningful only to the IP multicast modules at the ingress and egress LSRs. Section 3.2 Note that the Bidir TLVs do not have a "Source Address" sub-field, and hence the notion of a wildcard source is not applicable to them. Lizhong> since Bidir TLV is out of the scope, then it is not necessary to Lizhong> have the above note. Section 3.2 states earlier that procedures for the use of the wildcard group in the Bidir TLVs are out of scope. The sentence cited above says that the Bidir TLVs cannot have a wildcard source. I think it is useful to make both statements, since neither one implies the other. Section 3.3 However, if an Ingress LSR supports [RFC6826] and/or [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling], but does not support this document, it has no choice but to treat any such received FEC elements as invalid; the procedures specified in [RFC6826] and [I-D.ietf-l3vpn-mldp-vrf-in-band-signaling] do not work when the Opaque values contain zeroes in the Source Address or Group Address sub-fields. Lizhong> I went throught RFC6826 and RFC7246, there is no definition of Lizhong> "zeroes". Then the above statement will be treated as an update to Lizhong> RFC6826 and RFC7246. If that is true, then the draft header needs Lizhong> to indicate that update. I believe you are correct. I will add this to the draft header and the abstract. Section 5. If PIM is not enabled for the identified group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures as defined in [RFC4605] are followed. Lizhong> It seems the dataplane processing is missing here. E.g., add Lizhong> something like, the ingress LSR should forward the specified Lizhong> multicast stream to the downstream node through the MP-LSP Lizhong> identified by the Opaque Value TLV. That is not described in Lizhong> RFC4605. This is discussed in section 4.2 of the document; I think it will be adequate to just add a reference here to section 4.2. From nobody Mon Aug 11 08:37: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 CFABA1A04B8; Mon, 11 Aug 2014 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 I5DSL-AWmz8C; Mon, 11 Aug 2014 08:26:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47FD1A04F6; Mon, 11 Aug 2014 08:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=449; q=dns/txt; s=iport; t=1407770808; x=1408980408; h=from:to:cc:subject:in-reply-to:reply-to:mime-version: content-id:date:message-id; bh=Vp59Ap44VzBiknVktuVl/abR3WH5ErubG4VSjtxTOm0=; b=R8MYEJPTDZN6eKR6QeOWS583FKhoHYe5kl8r0sn3bbgLXkBm8CMuY/oB U/66DrnEaz7Hv1ibN2mkVtmdpkMHT7E5UXzKXU51HZp+J7wrICpxct51S 8McNPa7URETNfk9DptM5KvFybENgIo2A6RacQdclOHmuNu3KM+PXRxIQR g=; X-IronPort-AV: E=Sophos;i="5.01,842,1400025600"; d="scan'208";a="343535869" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 11 Aug 2014 15:26:48 +0000 Received: from erosen-lnx.cisco.com (erosen-lnx.cisco.com [161.44.71.19]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7BFQlJj003079; Mon, 11 Aug 2014 15:26:48 GMT Received: from erosen-lnx (localhost [127.0.0.1]) by erosen-lnx.cisco.com (Postfix) with ESMTP id AD8EC756; Mon, 11 Aug 2014 11:26:47 -0400 (EDT) From: Eric Rosen To: Lizhong Jin In-reply-to: Your message of Sun, 10 Aug 2014 14:02:24 +0800. <00de01cfb460$ad881330$08983990$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <13787.1407770807.1@erosen-lnx> Date: Mon, 11 Aug 2014 11:26:47 -0400 Message-ID: <13788.1407770807@erosen-lnx> Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/t06v8MhJCE6vrmcAYkgi0hocYEc X-Mailman-Approved-At: Mon, 11 Aug 2014 08:37:36 -0700 Cc: 'draft-ietf-mpls-mldp-in-band-wildcard-encoding' , 'rtg-dir' , 'mpls' , 'rtg-ads' Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: erosen@cisco.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:26:54 -0000 How about if I change bullet point 3 of section 5 to: 3. If PIM is not enabled for the identified group, the Ingress LSR acts as if it had received a (*,G) IGMP/MLD report from a downstream node, and the procedures as defined in [RFC4605] are followed. The ingress LSR should forward the (*,G) packets to the egress LSR through the MP-LSP identified by the Opaque Value TLV. (See also Section 4.2.) From nobody Mon Aug 11 18:53: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 415551A005C; Mon, 11 Aug 2014 18:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.45 X-Spam-Level: X-Spam-Status: No, score=0.45 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, 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 wvDcSK-oThC9; Mon, 11 Aug 2014 18:53:05 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28E61A0056; Mon, 11 Aug 2014 18:53:04 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so11761938pdj.28 for ; Mon, 11 Aug 2014 18:53:04 -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=EX9z/sqzrwOWejokaypKdIplwvPDk675H1Vlc2Vuz8o=; b=z7yNeT726raX/j4ANpjVtICVfx3LmeUJXiDd6mmpZWSVDzPn2d63zhEQJdivbjJhhr USqj+84czZxzt4n/wPSIndosHTAjIrYd8kIYtAkohIvo2TcqG7WK9vZe8Xiswltv7z+Z GwH8bpWcB9i4ygZIjP/FjaAW57shBQqpiogTTbQJbpo3NuGzThuHQ1OjwgtOM6yucuX7 p5h48fY15Miu2W10viJDRPHp0vnBwUs7KFbSYi8jSIBE99gDyWD06boEtQKksIvqyO+3 FU8xyWQR26Bn1Kd/vyx85CvGYco+GXjhEgbN4Gi+8rhgNXtvowXqR/DorqneKQMkg+oX PjPg== X-Received: by 10.66.161.41 with SMTP id xp9mr1460166pab.120.1407808384521; Mon, 11 Aug 2014 18:53:04 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id fs6sm1434318pdb.60.2014.08.11.18.53.01 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Aug 2014 18:53:03 -0700 (PDT) From: "Lizhong Jin" To: References: Your message of Sun, 10 Aug 2014 14:02:24 +0800. <00de01cfb460$ad881330$08983990$@gmail.com> <13788.1407770807@erosen-lnx> In-Reply-To: <13788.1407770807@erosen-lnx> Date: Tue, 12 Aug 2014 09:52:58 +0800 Message-ID: <001f01cfb5d0$2736c6c0$75a45440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGJG4ckmN2t+jshHptfO2YxqmI8oJxZaQQQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Pc3u3krwPIX1oJVZTBIPkqJ_9WI Cc: 'draft-ietf-mpls-mldp-in-band-wildcard-encoding' , 'rtg-dir' , 'mpls' , 'rtg-ads' Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-mldp-in-band-wildcard-encoding-01.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: Tue, 12 Aug 2014 01:53:10 -0000 I am fine with the new text. Thank you, Eric. Regards Lizhong > -----Original Message----- > From: Eric Rosen [mailto:erosen@cisco.com] > Sent: 2014=C4=EA8=D4=C211=C8=D5 23:27 > To: Lizhong Jin > Cc: 'rtg-ads'; 'draft-ietf-mpls-mldp-in-band-wildcard-encoding'; 'rtg-dir'; > 'mpls' > Subject: Re: [mpls] RtgDir review: = draft-ietf-mpls-mldp-in-band-wildcard- > encoding-01.txt >=20 > How about if I change bullet point 3 of section 5 to: >=20 > 3. If PIM is not enabled for the identified group, the Ingress LSR > acts as if it had received a (*,G) IGMP/MLD report from a > downstream node, and the procedures as defined in [RFC4605] are > followed. The ingress LSR should forward the (*,G) packets to > the egress LSR through the MP-LSP identified by the Opaque = Value > TLV. (See also Section 4.2.) From nobody Wed Aug 20 07:45: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 815F11A0400; Wed, 20 Aug 2014 07:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP_XS5N2WqCc; Wed, 20 Aug 2014 07:45:34 -0700 (PDT) Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C051A03F0; Wed, 20 Aug 2014 07:45:34 -0700 (PDT) Received: by mail-yh0-f43.google.com with SMTP id 29so6996949yhl.16 for ; Wed, 20 Aug 2014 07:45:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iRoMrR9Mkpm7ogJ2laMoZlG6upDysEQi5UmUFtA3RlU=; b=EMvb+TGzh7bw65PS815LGBCdczp5Cc4r1RK7ISz8RtEA3pW68ZiXC5w5hPV22CfziZ f1dVB73VQyNr+CPi3sFw05qwToanD26VK9UVTi668l0sP+3+5caW3QwKFKWyVKuJkiUC B7YsGcmN4Vhvl7o/1ruu8kDvBDdMp7Kfl+qZfAJaTva7ffj8AYvAWN8gbvyyffN55wGj bWC6IH4fv45EDJJauTrwPk79HVCyQM/oJQXqS6mpIa/MKGoUzDhE1ZzymCx7W3v6uPof 5ChW2Z29X7V5TpSSrNxEa494pW3pZlb3ytd9Ci9kEyKbkcw7jJzwgkoZd5Ugkctttoml 7JfA== MIME-Version: 1.0 X-Received: by 10.236.70.105 with SMTP id o69mr72283555yhd.25.1408545933991; Wed, 20 Aug 2014 07:45:33 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Wed, 20 Aug 2014 07:45:33 -0700 (PDT) Date: Wed, 20 Aug 2014 10:45:33 -0400 Message-ID: From: Alia Atlas To: "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Content-Type: multipart/alternative; boundary=089e016355d80ba7ff050110a8f1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/MUdXFxjOa8MytTaLBbgdEWgldNE Subject: [RTG-DIR] Please start using the Document QA process now 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, 20 Aug 2014 14:45:36 -0000 --089e016355d80ba7ff050110a8f1 Content-Type: text/plain; charset=UTF-8 Hi to all the Routing Area WG Chairs and Secretaries, As Adrian and I discussed prior to IETF 90 and in the Routing Area meeting at IETF 90, we would like to start using the new Draft Quality Assurance process ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all drafts that are being considered for WG adoption. Drafts that are already WG drafts do not need to go through this process - but chairs can ask if it seems desirable. As with many processes in the IETF, this process is intended to be used for the spirit of the goal, subject to common-sense and technical perspective. In particular, none of this process is intended to gate or otherwise impede the normal progression of documents through IETF working groups: rather, it is intended to provide additional input, review, and comments that the working groups can use to help improve the quality of their documents, and to help chairs determine quality and consensus for documents. We do not expect IETF process to wait for reviews to happen. As described on the wiki page, the detailed process is: 1. The WG Chair or Secretary emails the Routing Directorate Coordinators ( Deborah Brungard ) and Jonathan Hardwick ). The subject should be WG Draft QA Requested: >. 1. The WG Chair or Secretary marks a draft in the datatracker as "Candidate for Adoption" and specifies the date on which WG Draft QA was requested. 1. The Routing Directorate Coordinators and WG Chairs agree and find a QA Reviewer. The review can be done during the WG Call for Adoption. The WG Chair or Secretary adds a comment in the draft's datatracker history page indicating whom is the QA Reviewer. Please start doing this now. After IETF-91, we can discuss how this is going and its usefulness. Thanks, Alia --089e016355d80ba7ff050110a8f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi to all the Routing =C2=A0Area WG Chairs and Secretaries,

As Adrian and I discussed prior to IETF 90 and in the Routing Area meeting = at IETF 90,
we would like to start using the new Draft Quality Assurance process (=C2= =A0http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa=C2=A0) for all drafts that are being
considered for W= G adoption. =C2=A0 Drafts that are already WG drafts do not need to go thro= ugh this process - but chairs can ask if it seems desirable.

As with many processes in the IETF, this process is intend= ed to be used for the spirit of the goal, subject to common-sense and techn= ical perspective. In particular, none of this process is intended to gate o= r otherwise impede the normal progression of documents through IETF working= groups: rather, it is intended to provide additional input, review, and co= mments that the working groups can use to help improve the quality of their= documents, and to help chairs determine quality and consensus for document= s. We do not expect IETF process to wait for reviews to happen.

=
As described on = the wiki page, the detailed process is:
  1. The WG Chair or Secreta= ry emails the Routing Directorate Coordinators ( Deborah Brungard <db354= 6 at=C2=A0att.com>) an= d Jonathan Hardwick <jonathan.hardwick at=C2=A0metaswitch.com>). The subject should be = WG Draft QA Requested: <d= raft-name>.
  1. The WG= Chair or Secretary marks a draft in the datatracker as "Candidate for= Adoption" and specifies the date on which WG Draft QA was requested.<= /li>
  1. The Ro= uting Directorate Coordinators and WG Chairs agree and find a QA Reviewer. = The review can be done during the WG Call for Adoption. The WG Chair or Sec= retary adds a comment in the draft's datatracker history page indicatin= g whom is the QA Reviewer.
Pleas= e start doing this now. =C2=A0

After IETF-91, we can discuss how this is going and its usefulness.

Thanks,
Alia
--089e016355d80ba7ff050110a8f1-- From nobody Wed Aug 20 08:42: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 57AE11A0AD7; Wed, 20 Aug 2014 08:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.268 X-Spam-Level: ** X-Spam-Status: No, score=2.268 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, 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 J98uhEiTf81z; Wed, 20 Aug 2014 08:39:14 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D7A991A0AE5; Wed, 20 Aug 2014 08:38:54 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.01,903,1400040000"; d="scan'208,217";a="464403407" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 20 Aug 2014 11:38:35 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 20 Aug 2014 11:38:53 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "rtg-ads@tools.ietf.org" Date: Wed, 20 Aug 2014 11:38:57 -0400 Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D019124D2BF6Dwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/I-ukli6HSBAvUFEgpGdFyvKOf7U X-Mailman-Approved-At: Wed, 20 Aug 2014 08:42:14 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Wed, 20 Aug 2014 15:39:18 -0000 --_000_D019124D2BF6Dwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx2YXJvLCB0aGFuayB5b3UgZm9yIHRoZSB0aG9yb3VnaCByZXZpZXcuIFBsZWFzZSBmaW5kIG15 IHJlc3BvbnNlcyBiZWxvdyBpbmxpbmUgb24gYmVoYWxmIG9mIHRoZSBhdXRob3IgdGVhbS4gV2Ug aGF2ZSBhbiB1cGRhdGUgaW4gdGhlIGVkaXQgYnVmZmVyLCBhd2FpdGluZyBhIGZldyB1cGRhdGVz IHRvIHRoZSBFVlBOIHNlY3Rpb24gYW5kIHBvc3NpYmx5IHRoZSBMMlZQTiBzZWN0aW9uICh0byBp bmNvcnBvcmF0ZSBhbnkgbmVjZXNzYXJ5IGRpc2N1c3Npb24gb2YgUkZDIDcxMTcpLCBidXQgSSB3 YW50ZWQgdG8gZ28gYWhlYWQgYW5kIHJlc3BvbmQgbm93IHRoYXQgbW9zdCBvZiB0aGUgY29tbWVu dHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBvdXIgZWRpdHMgYXQgbGVhc3QuDQoNClRoYW5rcywN Cg0KV2VzIEdlb3JnZQ0KDQpGcm9tOiAiQWx2YXJvIFJldGFuYSAoYXJldGFuYSkiIDxhcmV0YW5h QGNpc2NvLmNvbTxtYWlsdG86YXJldGFuYUBjaXNjby5jb20+Pg0KRGF0ZTogVHVlc2RheSwgQXVn dXN0IDUsIDIwMTQgYXQgMjo0NCBQTQ0KVG86ICJydGctYWRzQHRvb2xzLmlldGYub3JnPG1haWx0 bzpydGctYWRzQHRvb2xzLmlldGYub3JnPiIgPHJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRv OnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc+Pg0KQ2M6ICJydGctZGlyQGlldGYub3JnPG1haWx0bzpy dGctZGlyQGlldGYub3JnPiIgPHJ0Zy1kaXJAaWV0Zi5vcmc8bWFpbHRvOnJ0Zy1kaXJAaWV0Zi5v cmc+PiwgImRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLmFsbEB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPiIg PGRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLmFsbEB0b29scy5pZXRmLm9yZzxtYWlsdG86 ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPj4sICJtcGxz QGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1w bHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW21wbHNdIFJ0Z0RpciByZXZpZXc6IGRyYWZ0LWlldGYt bXBscy1pcHY2LW9ubHktZ2FwLTAxDQoNCg0KQ29tbWVudHM6DQoNCkkgZG8gaGF2ZSBhIGNvdXBs ZSBvZiBoaWdoLWxldmVsIGl0ZW1zIEkgd2FudCB0byBicmluZyB1cC4gIEJlY2F1c2UgSSBhc3N1 bWUgdGhhdCB0aGVzZSBtYXkgaGF2ZSBhbHJlYWR5IGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBhcHBy b3ByaWF0ZSBXRyhzKSBJJ20gbm90IGxpc3RpbmcgdGhlbSBhcyBtYWpvciBpc3N1ZXMsIGFuZCB3 aWxsIGRlZmVyIHRvIHdoYXQgdGhlIGNvbnNlbnN1cyBoYXMgYmVlbiBzbyBmYXIuDQoNCiAxLiAg V2h5IGRvIHdlIG5lZWQgdG8gcHVibGlzaCB0aGlzIGRvY3VtZW50PyAgQXMgSSBzYWlkIGFib3Zl LCBJIGJlbGlldmUgdGhlIHdvcmsgaXMgdmFsdWFibGUsIGJ1dCBpdCBjYXB0dXJlcyB0aGUgc3Rh dGUgaW4gdGltZSAodG9kYXkhKSBvZiB0aGUgZ2FwcyDigJQgaXQgcG9pbnRzIHRvIHdvcmsgdGhh dCBhbHJlYWR5IHNvbHZlZCBhIHBvdGVudGlhbCBnYXAsIG9yIGlzIGluIHRoZSBwcm9jZXNzIG9m IHNvbHZpbmcgdGhlbS4gIEEgc2lnbmlmaWNhbnQgcG9ydGlvbiBvZiB0aGUgZ2FwcyBhcmUgYWxy ZWFkeSBiZWluZyBhZGRyZXNzZWQuICBHaXZlbiB0aGUgaW1wb3J0YW5jZSBvZiBJUHY2LCBpZiBw dWJsaXNoZWQsIHNvb24gdGhpcyBkb2N1bWVudCB3aWxsIGhhdmUgdG8gYmUgdXBkYXRlZCB0byBz YXkgIm5vdGhpbmcgYnJlYWtzIi4gIEFnYWluLCB0aGUgd29yayBpcyBpbXBvcnRhbnQsIGJ1dCBp dCBtYXkgYmUgYmV0dGVyIHN1aXRlZCB0byBiZSBhICJsaXZpbmcgZG9jdW1lbnQiIGFzIGEgZ3Vp ZGUgZm9yIHdoYXQgc3RpbGwgbmVlZHMgdG8gYmUgYWRkcmVzc2VkLiAgSWYgaXQgaXMgdG8gYmUg cHVibGlzaGVkLCBJIHdvdWxkIHN1Z2dlc3QgYXZvaWRpbmcgbGlua3MgdG8gd29yayBpbiBwcm9n cmVzcywgYnV0IGxpbWl0aW5nIHRoZSBjb250ZW50IHRvIGlkZW50aWZ5aW5nIHRoZSBnYXBzLi5h bmQgdGhlbiBsZXR0aW5nIHRoZSBzb2x1dGlvbiBkcmFmdHMvUkZDcyBwb2ludCBiYWNrIHRvIHRo aXMgZG9jdW1lbnQuLiAgKGFsYSByZXF1aXJlbWVudHMgLT4gc29sdXRpb24pDQogMi4gIEl0IGlz IGludGVyZXN0aW5nIHRvIG1lIHRoYXQgdGhpcyBkcmFmdCBjYW1lIHRocm91Z2ggdGhlIG1wbHMg V0csIGFuZCBub3Qgb25lIG9mIHRoZSBvcGVyYXRpb25zLWZvY3VzZWQgZ3JvdXBzLi53aGljaCBw cmVzdW1hYmx5IHdvdWxkIGJlIGluIGEgYmV0dGVyIHBvc2l0aW9uIHRvIGV2YWx1YXRlIHRoZSBu ZWVkcyBkZXNjcmliZWQuICBHaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBpcyBhbHJlYWR5IGluIFdH IExhc3QgQ2FsbCwgSSdtIGFzc3VtaW5nIHRoYXQgdGhlIGFsaWdubWVudCBoYXMgYWxyZWFkeSBi ZWVuIGRpc2N1c3NlZCBhbmQgdGhhdCBwcm9wZXIgY3Jvc3MtV0cgcmV2aWV3cyBoYXZlIG9jY3Vy cmVkLg0KDQpXR10gQ3Jvc3MtV0cgcmV2aWV3cyBoYXZlbid0IG9jY3VycmVkLCBidXQgd2Ugdmll dyBNUExTJ3MgYWN0aXZlIHBhcnRpY2lwYW50cyBhcyBhIHN1cGVyc2V0IG9mIHRoZSBwYXJ0aWNp cGFudHMgb2YgbW9zdCBvZiB0aGUgTVBMUy1kZXBlbmRlbnQgV0dzLCBhbmQgYWxzbyBhIGdvb2Qg c291cmNlIG9mIGNyb3NzLVdHIGdlbmVyYWxpc3RzIGFuZCBleHBlcnRzIG9uIE1QTFMuIEl0J3Mg dW5jbGVhciB0byBtZSB3aGF0IG5lZWRzIHNob3VsZCBiZSBldmFsdWF0ZWQgYnkgdGhlIG9wZXJh dGlvbnMtZm9jdXNlZCBXR3MsIGdpdmVuIHRoYXQgdGhlIGlzc3VlIGNhbWUgZnJvbSBhIHByb2Js ZW0gdGhhdCBhbiBhY3R1YWwgb3BlcmF0b3IgZXhwZXJpZW5jZWQgKG5hbWVseSwgbWUpIGFuZCBJ IGRvbid0IHRoaW5rIHRoYXQgdGhlIG5lZWQgZm9yIE1QTFMgdG8gd29yayBvbiBhbiBJUHY2LW9u bHkgb3IgSVB2Ni1wcmltYXJ5IG5ldHdvcmsgaXMgcGFydGljdWxhcmx5IGNvbnRyb3ZlcnNpYWwg YW55d2F5LiBJZiBwZW9wbGUgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzbid0IGVub3VnaCBvdmVybGFw LCB3ZSBjYW4gY2VydGFpbmx5IHNvbGljaXQgcmV2aWV3cyBmcm9tIHNvbWUgb2YgdGhlIG90aGVy IFdHcyBpbnZvbHZlZC4gQXdhaXRpbmcgQUQvV0cgY2hhaXIgZ3VpZGFuY2UuDQoNCldlJ3ZlIGRp c2N1c3NlZCB0aGlzIHF1ZXN0aW9uIGFib3V0IHdoZXRoZXIgdG8gcHVibGlzaCBhIGdhcCBhbmFs eXNpcyBhdCBhbGwgc29tZXdoYXQgb2ZmbGluZSwgYnV0IEknbSBpbmNsdWRpbmcgYSBmZXcgcG9p bnRzIGZvciB0aGUgcmVjb3JkIGFuZCBmb3IgV0cgY29tbWVudCBoZXJlLiBGaXJzdCwgbXkgZXhw ZWN0YXRpb24gaXMgdGhhdCB0aGUgZ2FwIGFuYWx5c2lzIHNob3VsZG4ndCBwcm9jZWVkIHRvIFJG QyB1bnRpbCBhIGNvbnNlbnN1cyBleGlzdHMgdGhhdCB3ZSBoYXZlIHJlYXNvbmFibHkgY2FwdHVy ZWQgYWxsIG9mIHRoZSBleGlzdGluZyBnYXBzLiBJbiBvdGhlciB3b3JkcywgdGhpcyBpcyBhIGRv Y3VtZW50YXRpb24gb2YgYWxsIG9mIHRoZSBnYXBzIHRoYXQgd2UgYXMgYSBjb2xsZWN0aXZlIGdy b3VwIG9mIHRoZSBTbWFydCBQZW9wbGUgV2hvIEtub3cgQWJvdXQgU3VjaCBUaGluZ3MgY291bGQg dGhpbmsgb2YsIGFuZCBleHBsaWNpdCBkb2N1bWVudGF0aW9uIG9mIGFyZWFzIHdpdGhvdXQgZ2Fw cyB0byBjb25maXJtIHRoYXQgd2UgcmV2aWV3ZWQgdGhlbSB0byB2YWxpZGF0ZSB0aGlzLiBOZXcg Z2FwcyBTSE9VTEQgTk9UIGRldmVsb3AsIGFzIG9uY2UgYSBnYXAgYW5hbHlzaXMgbGlrZSB0aGlz IGlzIHBlcmZvcm1lZCwgaXQgcmFpc2VzIGF3YXJlbmVzcyBzbyB0aGF0IHBlb3BsZSBpbiB0aGUg V0cgKGFuZCBBRHMpIHdpbGwgYXNrIG9mIGZ1dHVyZSB3b3JrLCAiZG9lcyB0aGlzIHdvcmsgb24g YW4gSVB2Ni1vbmx5IE1QTFMgbmV0d29yaywgZG9lcyBpdCBkZXBlbmQgb24ga25vd24gZ2FwcyBk b2N1bWVudGVkIGluIFJGQ25ubm4gYmVpbmcgYWRkcmVzc2VkLCBvciBhcmUgYWRkaXRpb25hbCBj aGFuZ2VzIG5lY2Vzc2FyeSB0byBtYWtlIHRoaXMgd29yayBwcm9wZXJseSBvbiBJUHY2LW9ubHk/ Ig0KU2Vjb25kLCBJIHRoaW5rIHRoaXMgZ2VuZXJhbGx5IGhpZ2hsaWdodHMgYSBwcm9ibGVtIElF VEYtd2lkZSB3aGVuIGl0IGNvbWVzIHRvIGdhcCBhbmFseXNlcy4gRWl0aGVyIHRoZSB3b3JrIGlz IGFscmVhZHkgaW4gcHJvZ3Jlc3MsIGFuZCBpdCBzZXJ2ZXMgYXMgYSBtZXRob2QgdG8gY2F0YWxv ZyB0aGUgaXNzdWVzIHRvIG1ha2Ugc3VyZSB3ZSBoYXZlIHRoZW0gYWxsIGJlaW5nIGFkZHJlc3Nl ZCwgb3IgaXQgc2VydmVzIHRvIGlkZW50aWZ5IHBsYWNlcyB3aGVyZSBmdXR1cmUgd29yayBpcyBu ZWVkZWQuIFRoZSBwcm9ibGVtIGlzIHRoYXQgdGhlIElFVEYgaGFzIG5vIG1ldGhvZCBkZWZpbmVk IHRvIGZvbGxvdyB1cCBvbiBnYXAgYW5hbHlzZXMgdG8gZW5zdXJlIHRoYXQgZnV0dXJlIHdvcmsg aWRlbnRpZmllZCBhY3R1YWxseSBnZXRzIGNvbXBsZXRlZCwgc2hvcnQgb2YgdGhlIFdHIGFkZGlu ZyBpdGVtcyB0byBpdHMgY2hhcnRlciB0byBleHBsaWNpdGx5IGFkZHJlc3MgdGhlc2UgdGhpbmdz LiBJZiB0aGUgZ2FwIGFuYWx5c2lzIHNwYW5zIFdHcywgb3IgdGhlcmUgaXNuJ3QgYW55b25lIGlu dGVyZXN0ZWQgaW4gYWRkcmVzc2luZyB0aGUgaWRlbnRpZmllZCBnYXAsIGl0IGNhbiBzb3J0IG9m IHJvdCBpbnNpZGUgdGhlIGFuYWx5c2lzIGFuZCBncmFkdWFsbHkgYmUgZm9yZ290dGVuLiBXZSdy ZSBkZWFsaW5nIHdpdGggdGhpcyBxdWVzdGlvbiBpbiBzdW5zZXQ0IG9uIHRoZSBvcmlnaW5hbCBz ZXQgb2YgSVB2NiBnYXAgYW5hbHlzZXMgdGhhdCB3ZXJlIGRvbmUgb24gUkZDcyAzNzkwLTk2LCBi ZWNhdXNlIG5vIG9uZSBoYXMgYSBnb29kIHNlbnNlIGZvciB3aGV0aGVyIGFsbCBvZiB0aGUgZ2Fw cyBpZGVudGlmaWVkIGluIHRob3NlIGRvY3VtZW50cyB3ZXJlIGFkZHJlc3NlZCwgb3IgYXJlIGlu ZGVlZCBzdGlsbCByZWxldmFudC4gVGhpcyBkcmFmdCBjYXRhbG9ncyBnYXBzIHdpdGggcG9pbnRl cnMgdG8gd2hlcmUgdGhlIGF1dGhvcnMga25vdyB0aGVyZSBpcyBhbHJlYWR5IHdvcmsgYmVpbmcg ZG9uZSwgd2hpY2ggc2VydmVzIHRvIGxpbmsgdGhlIHR3bywgYW5kIGVuc3VyZXMgdGhhdCBpdCdz IGFzIGNsZWFyIGFzIHBvc3NpYmxlIHdoZXJlIHRoZXJlIGFyZSBzdGlsbCBvdXRzdGFuZGluZyBn YXBzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQsIGFuZCBpdCdkIGJlIHJlYXNvbmFibGUgdG8g ZXhwZWN0IGFueSBmb2xsb3ctb24gZG9jdW1lbnRzIHRoYXQgYWRkcmVzcyBnYXBzIGlkZW50aWZp ZWQgYXMgVEJEIGluIHRoaXMgZG9jdW1lbnQgdG8gZm9ybWFsbHkgdXBkYXRlIHRoaXMgZG9jdW1l bnQgc28gdGhhdCB0aGUgbGluayBpcyBwcmVzZW50IGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQg dGhlIGZ1dHVyZSBkb2N1bWVudHMgYWRkcmVzc2luZyBzb21lIG9mIHRoZSBnYXBzIHRoYXQgaXQg aWRlbnRpZmllZCBhcyBub3QgaGF2aW5nIGZpeGVzIGluIHByb2dyZXNzLiBJdCdzIHRoZSBiZXN0 IHdlIGNhbiBkbyB3aXRoICJmcm96ZW4gaW4gdGltZSIgZG9jdW1lbnRzIGxpa2UgdGhpcywgYnV0 IEkgdGhpbmsgaXQncyBhY2NlcHRhYmxlLg0KVWx0aW1hdGVseSwgSSB0aGluayB5b3VyIHF1ZXN0 aW9uIGlzIGEgbGFyZ2VyIGlzc3VlIGFuZCB0aGlzIGdhcCBhbmFseXNpcyBpcyBubyBkaWZmZXJl bnQgdGhhbiBhbnkgb3RoZXIg4oCTIHRoZSBxdWVzdGlvbiBvZiAic2hvdWxkIHdlIHB1Ymxpc2gi IGlzIHJlYWxseSAic2hvdWxkIHdlIHB1Ymxpc2ggYW55IGdhcCBhbmFseXNpcyBhcyBhbiBSRkMg Z2l2ZW4gdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBzZXJpZXM/IiBhbmQgdGhhdCdzIG5vdCBzb21l dGhpbmcgd2UncmUgZ29pbmcgdG8gc29sdmUgaGVyZSwgc28gSSB0aGluayBpdCdzIGEgbWF0dGVy IG9mIHB1Ymxpc2hpbmcgdGhlIGRvY3VtZW50IGlmIHRoZSBjb250ZW50IGlzIGhlbHBmdWwuDQoN Cg0KTWlub3IgSXNzdWVzOg0KDQogKiAgIFNvbWUgdGVybWlub2xvZ3kgd2FzIG5vdCBleHBhbmRl ZCBiZWZvcmUvd2hlbiBpdCB3YXMgZmlyc3QgdXNlZDogd2UgYWxsIGtub3cgd2hhdCBNUExTIGlz LCBidXQgb3RoZXJzIGxpa2UgTFNSLCBMRVIsIEZFQywgTDJWUE4sIEVWUE4sIE5HLW1WUE4sIGV0 Yy4gc2hvdWxkIGJlIGV4cGFuZGVkLg0KDQpXR10gSSBiZWxpZXZlIHRoaXMgaXMgZml4ZWQgbm93 DQoNCiAqICAgU2VjdGlvbiAzLjEgKE1QTFMgRGF0YSBQbGFuZSk6ICJJbiB0aGUgY2FzZSB3aGVy ZSBhbiBJUHY0IHByZWZpeCBpcyByZXNvbHZlZCBvdmVyIGFuIElQdjYgTFNQLCBhbiBJUHY2IEV4 cGxpY2l0IE51bGwgbGFiZWwgY2Fubm90IGltbWVkaWF0ZWx5IHByZWNlZWQgYW4gSVB2NCBwYWNr ZXQuIiAgSXMgdGhlcmUgYSByZWZlcmVuY2UgZm9yIHRoaXMgc3RhdGVtZW50IG9yIGlzIHRoaXMg YSByZXF1aXJlbWVudCB0byBmaWxsIGluIHRoZSBnYXA/ICBJZiBpdCBpcyBhIHJlcXVpcmVtZW50 LCBkbyB3ZSBuZWVkIHRvIGFkZCAyMTE5IGxhbmd1YWdlPw0KDQotLUl0IHJlYWxseSBjb21lcyBm cm9tIFJGQyAzMDMyLCBhbmQgdGhlbiBSRkMgNDE4Mi4gT25lIGV4YW1wbGUgaXMgcHJlc2VudCBp biBSRkM0Nzk4DQoNCkhvd2V2ZXIsIGFmdGVyIHJldmlldywgd2UndmUgcmVtb3ZlZCB0aGlzIHRl eHQsIGJlY2F1c2Ugd2UgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIGlzIGFjdHVhbGx5IGEgZ2FwLCBh bmQgdGhlIHRleHQgd2FzIGNvbmZ1c2luZyAoZXZlbiB0byB5b3VyIGh1bWJsZSBlZGl0b3IpLg0K DQogKiAgIFdoZW4gYSBnYXAgZXhpc3RzLCB5b3UgY2xhc3NpZnkgaXQgYXMgIm1ham9yIiBvciAi bWlub3IiLiAgV2hhdCBpcyB0aGUgY3JpdGVyaWEgdXNlZD8gIEkgd291bGQgaW1hZ2luZSB0aGF0 IGdpdmVuIHRoYXQgaXQgaXMgYSBnYXAgYW5hbHlzaXMsIHRoZSBvYmplY3RpdmUgaXMgdG8gcG9p bnQgb3V0IHRoZSBuZWVkcywgbm90IGNoYXJhY3Rlcml6ZSB0aGVtIChpZiBJIG5lZWQgYSAibWlu b3IiIGdhcCB0byBiZSBmaWxsZWQgaW4gb3JkZXIgZm9yIG15IG5ldHdvcmsgZGVwbG95bWVudCB0 byBvcGVyYXRlLCBpdCBiZWNvbWVzICJtYWpvciIgdG8gbWUpLg0KDQpXR10gQWRkZWQgdGV4dCB0 byB0aGUgYmVnaW5uaW5nIG9mIHNlY3Rpb24gMyBleHBsYWluaW5nIHRoZSB0ZXJtczoNCg0KIkEg bm90ZSBhYm91dCB0ZXJtaW5vbG9neTogR2FwcyBhcmUgdHlwaWNhbGx5IGNoYXJhY3Rlcml6ZWQg YXMgIk1ham9yIiwgIk1pbm9yIiBvciAibm9uZSIuIE1ham9yIGdhcHMgcmVmZXIgdG8gc2lnbmlm aWNhbnQgY2hhbmdlcyBuZWNlc3NhcnkgaW4gb25lIG9yIG1vcmUgc3RhbmRhcmRzIHRvIGFkZHJl c3MgdGhlIGdhcCBkdWUgdG8gZXhpc3Rpbmcgc3RhbmRhcmRzIGxhbmd1YWdlIGhhdmluZyBlaXRo ZXIgbWlzc2luZyBmdW5jdGlvbmFsaXR5IGZvciBJUHY2LW9ubHkgb3BlcmF0aW9uIG9yIGV4cGxp Y2l0IGxhbmd1Z2UgcmVxdWlyaW5nIHRoZSB1c2Ugb2YgSVB2NCB3aXRoIG5vIElQdjYgYWx0ZXJu YXRpdmVzIGRlZmluZWQuIE1pbm9yIGdhcHMgcmVmZXIgdG8gY2hhbmdlcyBuZWNlc3NhcnkgcHJp bWFyaWx5IHRvIGNsYXJpZnkgZXhpc3Rpbmcgc3RhbmRhcmRzIGxhbmd1YWdlLiBVc3VhbGx5IHRo ZXNlIGNoYW5nZXMgYXJlIG5lZWRlZCBpbiBvcmRlciB0byBleHBsaWNpdGx5IGNvZGlmeSBJUHY2 IHN1cHBvcnQgaW4gcGxhY2VzIHdoZXJlIGl0IGlzIGVpdGhlciBpbXBsaWNpdCBvciBvbWl0dGVk IHRvZGF5LCBidXQgdGhlIG9taXNzaW9uIGlzIHVubGlrZWx5IHRvIHByZXZlbnQgSVB2Ni1vbmx5 IG9wZXJhdGlvbi4iDQoNCg0KICogICBUaGUgaW50cm9kdWN0aW9uIHRvIHRoZSBkcmFmdCB0YWxr cyBhYm91dCAiZ2FwcyB0aGF0IG11c3QgYmUgYWRkcmVzc2VkIGluIG9yZGVyIHRvIGFsbG93IE1Q TFMtcmVsYXRlZCBwcm90b2NvbHMgYW5kIGFwcGxpY2F0aW9ucyB0byBiZSB1c2VkIHdpdGggSVB2 Ni1vbmx5IG5ldHdvcmtzIiAoIklQdjYtb25seSAobm8gSVB2NCBwcm92aXNpb25lZCBvbiB0aGUg ZGV2aWNlKSIpLCB3aGljaCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IG5vIElQdjQgaXMgcHJl c2VudCBpbiB0aGUgbmV0d29yayBhdCBhbGwuICAgSG93ZXZlciwgc2V2ZXJhbCBnYXBzIGFyZSBp ZGVudGlmaWVkIHRoYXQgb2NjdXIgaW4gIm1peGVkIiBuZXR3b3Jrcywgd2hlcmUgaXNsYW5kcyBv ZiBJUHY0L0lQdjYgZXhpc3QuICBJIHdvdWxkIHN1Z2dlc3QgY2xhcmlmeWluZyB0aGUgc2NvcGUg b2YgdGhlIGRvY3VtZW50IGluIHRoZSBpbnRyb2R1Y3Rpb24uICBTb21lIG9mIHRoZSBwbGFjZXMg d2hlcmUgdGhlc2Ugc2NlbmFyaW9zIGFyZSBkaXNjdXNzZWQgaW5jbHVkZTogIDMuMi4yLiAoTXVs dGlwb2ludCBMRFApLCAzLjMuMi4gKEwzVlBOKSwgIDMuNC4xLiAoRXh0ZW5kZWQgSUNNUCkgYW5k IDMuNC4yLiAoTFNQIFBpbmcpLg0KDQpXR10gYSBmZXcgc2VudGVuY2VzIGJlZm9yZSwgdGhlIGRv Y3VtZW50IHNheXMgImFueSBuZXR3b3JrcyB3aWxsIG5lZWQgdG8gc3RhcnQgb3BlcmF0aW5nIHNv bWUgb3IgYWxsIG9mIHRoZWlyIG5ldHdvcmsgbm9kZXMgZWl0aGVyIGFzIHByaW1hcmlseSBJUHY2 IChtb3N0IGZ1bmN0aW9ucyB1c2UgSVB2NiwgYSBmZXcgbGVnYWN5IGZlYXR1cmVzIHVzZSBJUHY0 KSwgb3IgYXMgSVB2Ni1vbmx5IChubyBJUHY0IHByb3Zpc2lvbmVkIG9uIHRoZSBkZXZpY2UpIiBE byB3ZSBzaW1wbHkgbmVlZCB0byBhZGQgc2ltaWxhciBsYW5ndWFnZSB0byB0aGUgbmV4dC10by1s YXN0IHNlbnRlbmNlLCBkb2VzIHRoZSBleGlzdGluZyB0ZXh0IG1ha2UgaXQgY2xlYXIgbm93IHRo YXQgSSd2ZSBoaWdobGlnaHRlZCBpdCwgb3IgaXMgbW9yZSByZXF1aXJlZD8NCg0KDQogKiAgIDMu My4xLjEuIChFVlBOKSAgSWYgdGhlIEVWUE4gd29yayBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIHRo ZSBkb2N1bWVudCwgdGhlbiB0YWtlIGl0IG91dC4gIEFub3RoZXIgb3B0aW9uIG1heSBiZSB0byB0 YWxrIGFib3V0IGFueSBnYXBzIGluIHRoZSBjdXJyZW50IHdvcmsuICBTYW1lIGNvbW1lbnQgZm9y IHNlY3Rpb24gMy4zLjIuNC4zLiAoUEUtUEUgTXVsdGljYXN0IFJvdXRpbmcgUHJvdG9jb2wpLg0K DQpXR10gRVZQTiBkcmFmdCBpcyBwZW5kaW5nIElFU0cvSUVURiBMQywgc28gaXQncyBub3Qgc28g bXVjaCBvZiBhIHdvcmsgaW4gcHJvZ3Jlc3MgYW55bW9yZSwgYW5kIHdpbGwgbGlrZWx5IGhpdCBw dWJsaWNhdGlvbiBwcmlvciB0byB0aGlzIGRvY3VtZW50LiBJIGhhdmUgZW1haWxlZCBFVlBOIGF1 dGhvcnMgdG8gcmVxdWVzdCB0aGF0IHRoZXkgY29uc2lkZXIgRVZQTiBpbiB0aGUgSVB2Ni1vbmx5 IG9wZXJhdGlvbiBjb250ZXh0IG9mIHRoaXMgZHJhZnQsIGFuZCBlaXRoZXIgY29uZmlybSB0aGF0 IHRoZXJlIGFyZSBubyBnYXBzLCB0aGF0IHRoZXJlIGFyZSBkZXBlbmRlbmNpZXMgb24gZ2FwcyBh bHJlYWR5IGlkZW50aWZpZWQsIG9yIHJlc29sdmUgYW55IGdhcHMgcHJlc2VudCB0aGF0IGFyZSB1 bmlxdWUgdG8gRVZQTiBwcmlvciB0byBMQy4gVGhlIHNlY3Rpb24gd2lsbCBiZSB1cGRhdGVkIGFj Y29yZGluZ2x5IHRvIHJlbW92ZSB0aGUgY29tbWVudHMgYWJvdXQgaXQgYmVpbmcgb3V0IG9mIHNj b3BlIGFuZCBhZGQgYSBicmllZiBnYXAgYW5hbHlzaXMgYmFzZWQgb24gdGhlIHJlc3VsdHMgb2Yg dGhhdCBkaXNjdXNzaW9uLg0KDQoNCiAqICAgMy4zLjIuIChMM1ZQTikgIHRoZSB0ZXh0IHNheXMg dGhhdCB0aGUgZ2FwcyBpbiBSRkM0MzY0IChubyBWUE4tSVB2NiBhZGRyZXNzIGFuZCBhIDEyOCBi aXQgbmV4dC1ob3ApIGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gUkZDIDQ2NTksIGJ1dCBpdCB0aGVu IGlkZW50aWZpZXMgdGhlIGdhcCBhbmQgc2F5cyB0aGF0ICJSRkM0MzY0IG11c3QgYmUgdXBkYXRl ZCIuICBXaGF0IHdvdWxkIHRoYXQgdXBkYXRlIGJlPw0KDQpXR10gWW91J3JlIHJpZ2h0LCB0aGlz IHdhcyByZWFsbHkgY29uZnVzaW5nIGFzIHdyaXR0ZW4uIE1hZGUgc2lnbmlmaWNhbnQgY2hhbmdl cyB0byB0aGlzIHNlY3Rpb24uIFRoZXJlIGFyZSBubyBnYXBzIGluIDQzNjQuIFRoZSByZWFsIHBy b2JsZW0gaXMgdGhhdCA0NjU5IHVwZGF0ZXMgNDM2NCBhbmQgZml4ZXMgdGhvc2UgZ2FwcywgYnV0 IGl0IGRvZXNuJ3QgZm9ybWFsbHkgdXBkYXRlIDQzNjQgaW4gdGhlIG1ldGFkYXRhLCBzbyBpdCBs b29rcyBsaWtlIHRoZXJlIGFyZSBnYXBzIGV4dGFudCBpbiA0MzY0LiBJdCBhbHNvIGV4cGxpY2l0 bHkgY2FsbHMgdXNlIGNhc2UgIzIgb3V0IG9mIHNjb3BlLg0KDQpJIGZpbGVkIGFuIGVycmF0dW0g dG8gZml4IDQ2NTkncyBtZXRhZGF0YTogaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFf c2VhcmNoLnBocD9yZmM9NDY1OSZlaWQ9NDA4Nw0KDQoNCiAqICAgU2VjdGlvbnMgMy4zLjIuNC4z LiAoUEUtUEUgTXVsdGljYXN0IFJvdXRpbmcgUHJvdG9jb2wpLCAzLjMuMy4gKE1QTFMtVFApIGFu ZCAzLjQuNS4gKE1QTFMtVFAgT0FNKSBhcmUgaW5jbHVkZWQsIGJ1dCBvdXQgb2Ygc2NvcGUuLiAg U2hvdWxkIHRoZXkgYmUgcmVtb3ZlZD8gIElmIG5vdCwgdGhlbiBhIHNob3J0IGp1c3RpZmljYXRp b24gaW4gdGhlIHRleHQgd291bGQgYmUgbmljZS4NCg0KV0ddIGNsYXJpZmllZA0KDQoNCiAqICAg My40LiAoTVBMUyBPQU0pICBUaGlzIHNlbnRlbmNlICJBbGwgb2YgdGhlc2UgbWVjaGFuaXNtcyB3 b3JrIGluIHB1cmUgSVB2NiBlbnZpcm9ubWVudHMuIiBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0 IGFsbCB0aGUgbWVjaGFuaXNtcyB3b3JrIGNvcnJlY3RseSBhbmQgdGhhdCB0aGVyZSBhcmUgbm8g Z2Fwcy4uYnV0IHRoZW4gc2V2ZXJhbCBnYXBzIGFyZSBsaXN0ZWQuDQoNCldHXSBNYWRlIHNvbWUg d29yZGluZyBjaGFuZ2VzIGluIDMuNCBhbmQgTFNQIHBpbmcgc2VjdGlvbiAzLjQuMiBmb3IgY2xh cml0eS4NCg0KDQogKiAgIFRhYmxlIDE6IElQdjYtb25seSBNUExTIEdhcHMuICBUaGUgdGFibGUg ZG9lc24ndCBpbmNsdWRlIGFsbCB0aGUgZ2FwcyBpZGVudGlmaWVkLiAgRm9yIGV4YW1wbGUsIDMu Mi4yLiAoTXVsdGlwb2ludCBMRFApIGlzIG5vdCBpbmNsdWRlZCBpbiB0aGUgdGFibGUsIGV2ZW4g dGhvdWdoIGEgbWFqb3IgZ2FwIHdhcyBpZGVudGlmaWVkLiAgSW4gdGhpcyBjYXNlLCB0aGUgd29y ayBpbiB0aGUgdGFibGUgZm9yIExEUCBtYXkgYWxzbyBhZGRyZXNzIHRoZSBnYXAgaW4gbUxEUCwg YnV0IHRoYXQgaXMgbm90IHBvaW50ZWQgb3V0IGluIHRoZSB0YWJsZS4uICBJbiBzaG9ydCwgdGhl IHRhYmxlIGlzIG5vdCBjb21wbGV0ZS4NCg0KV0ddIEZpeGVkDQoNCg0KICogICBTZWN1cml0eSBD b25zaWRlcmF0aW9ucy4gIFRoaXMgc2VjdGlvbiB0YWxrcyBhYm91dCBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBpbiBjdXJyZW50IHNwZWNpZmljYXRpb25zLi5idXQgaXQgbGVhdmVzIG91dCBtZW50 aW9uIG9mIHRoZSBmYWN0IHRoYXQgbmV3IHNwZWNpZmljYXRpb25zICh0byBjbG9zZSB0aGUgZ2Fw cykgc2hvdWxkIChNVVNUID8pIGNvbnNpZGVyIHRoZSBlZmZlY3Qgb2YgSVB2Ni4NCg0KV0ddIEZp eGVkDQoNCg0KTml0czoNCg0KR2xvYmFsIEFDSy4gQ291cGxlIG9mIHNwZWNpZmljIGNvbW1lbnRz Og0KDQogKiAgIFNlY3Rpb24gMyAoR2FwIEFuYWx5c2lzKS4gIFlvdSB3cm90ZTogIlRoaXMgZ2Fw IGFuYWx5c2lzIGFpbXMgdG8gYW5zd2VyIHRoZSBxdWVzdGlvbiwgIndoYXQgYnJlYWtzIHdoZW4g b25lIGF0dGVtcHRzIHRvIHVzZSBNUExTIGZlYXR1cmVzIG9uIGEgbmV0d29yayBvZiBJUHY2LW9u bHkgZGV2aWNlcz8iICBXaGlsZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UncmUgYXNraW5nLCBpbiBy ZWFsaXR5IHlvdSdyZSB0cnlpbmcgdG8gYW5zd2VyICJ3aGF0IGRvZXNuJ3Qgd29yay4uIi4gIEJy ZWFraW5nIGltcGxpZXMgdGhhdCBpdCBtYXkgd29yayBmb3IgYSB3aGlsZSBhbmQgdGhlbiBzdG9w IGRvaW5nIHNvLg0KDQpXR10gY2hhbmdlZCB0byBmYWlscw0KDQoNCiAqICAgMy4zLjIuIChMM1ZQ TikgICBUaGUgZ2FwIHNlY3Rpb24gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyB0ZXh0OiAiRGlzY3Vz c2VkIGluIGZ1cnRoZXIgZGV0YWlsIGJlbG93Ii4gIEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBh biBhY3R1YWwgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9uIGluc3RlYWQgb2YgdGhlIHRleHQuDQoN CldHXSBJdCdzIGluIHRoZSBuZXh0IHBhcmFncmFwaCwgaXMgZnVydGhlciBndWlkYW5jZSByZWFs bHkgbmVjZXNzYXJ5Pw0KDQogKiAgIEV2ZW4gdGhvdWdoIHNlY3Rpb25zIDMuMy4yLjEgYW5kIDMu My4yLjIgYXJlIHN1YnNlY3Rpb25zIG9mIDMuMy4yLCB3aXRoIHNvIG1hbnkgc2NlbmFyaW9zIGJl aW5nIGNvdmVyZWQsIGl0IGdldHMgaGFyZCB0byBrZWVwIHRyYWNrIG9mIHdoZXJlIHNvbWV0aGlu ZyB3YXMgZGVzY3JpYmVkLiAgSXQgd291bGQgYmUgdmVyeSBuaWNlIHRvIGluY2x1ZGUgcmVmZXJl bmNlcyB0byB3aGVyZSAidXNlIGNhc2UgIzIiIHdhcyBkZWZpbmVkIGluIHNhYyBvZiB0aG9zZSBz dWJzZWN0aW9ucy4NCg0KV0ddIHdoaWxlIHRoZXNlIHJlZmVyZW5jZXMgY291bGQgYmUgYWRkZWQs IGl0IGNvdmVycyBsZXNzIHRoYW4gYSBwYWdlIG9mIHRleHQgd2l0aGluIG9uZSBzdWJzZWN0aW9u LiBJJ20gbm90IGNvbnZpbmNlZCB0aGlzIGlzIGFuIGFjdHVhbCBwcm9ibGVtDQoNCg0KICogICAz LjMuMi40LjIuIChQLVR1bm5lbCBJbnN0YW50aWF0aW9uKQ0KICAgICogICAiLiAuIC5jb3ZlcmVk IGluIHByZXZpb3VzIHNlY3Rpb25zIi4gIFJlZmVyZW5jZXMgcGxlYXNlLg0KDQpXR10gYWNrDQoN CiAgICAqICAgIlBJTSBUcmVlIGFuZCBJbmdyZXNzIFJlcGxpY2F0aW9uIGFyZSBvdXQgb2YgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuLiIgYmVjYXVzZS4uICBFaXRoZXIgZXhwbGFpbiB3aHkg b3IgcmVtb3ZlIHRoZW0gZnJvbSB0aGUgbGlzdCByaWdodCBiZWZvcmUuDQoNCldHXSBmaXhlZCwg ZGlzY3Vzc2lvbiBhZGRlZA0KDQoNCiAqICAgMy40LjIuIChMU1AgUGluZykgIHMvTFNQIFBpbmcg cGFja2V0cyBhcmUgVURQIHBhY2tldHMgb3ZlciBib3RoIElQdjQgYW5kIElQdjYvTFNQIFBpbmcg cGFja2V0cyBhcmUgVURQIHBhY2tldHMgb3ZlciBlaXRoZXIgSVB2NCBvciBJUHY2DQoNCldHXSBh Y2sNCg0KICogICBUaGVyZSBpcyBzb21lIHVuZXZlbiB0cmVhdG1lbnQgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSBzdXBwb3J0L2dhcHMuICBJdCB3b3VsZCBiZSBuaWNlIHRvIHByb3ZpZGUgdGhl IHNhbWUgbGV2ZWwgb2YgZGV0YWlsIGV2ZXJ5d2hlcmUgKGlmIG5lZWRlZCkuICBGb3IgZXhhbXBs ZSwgMy4yLjMuMiAoUlNWUC1URS1QMk1QKSBwbGFpbmx5IG1lbnRpb25zIHRoYXQgUkZDNDg3NSBj b3ZlcnMgdGhlIHN1cHBvcnQgZm9yIElQdjYuLndoaWxlIDMuNC4zIChCRkQgT0FNKSBtZW50aW9u cyB3aGVyZSBJUHY2IHN1cHBvcnQgdXMgZGVmaW5lZCBidXQgaXQgYWxzbyBwb2ludHMgdG8gdGhl IHNwZWNpZmljIHNlY3Rpb25zLiAgSU1ITywgdGhlIGFkZGl0aW9uYWwgZGV0YWlsIGlzIG5vdCBu ZWVkZWQgKHVubGVzcyB2ZXJ5IHNwZWNpZmljIHBvaW50cyBuZWVkIHRvIGJlIG1hZGUpLg0KDQpX R10gYXV0aG9ycyBiZWxpZXZlIHRoYXQgdGhlIGRldGFpbCBpcyBwcm9iYWJseSBub3QgYWJzb2x1 dGVseSBuZWNlc3NhcnksIGJ1dCBkbyBzZWUgaXQgYXMgdXNlZnVsIGFuZCB0aGVyZWZvcmUgbm8g cmVhc29uIHRvIHJlbW92ZSBpdC4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUg V2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1l IFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBh cmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwg Y29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQg bWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBk ZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHBy aW50b3V0Lg0K --_000_D019124D2BF6Dwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFsdmFybywgdGhhbmsgeW91IGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiBQbGVhc2UgZmlu ZCBteSByZXNwb25zZXMgYmVsb3cgaW5saW5lIG9uIGJlaGFsZiBvZiB0aGUgYXV0aG9yIHRlYW0u IFdlIGhhdmUgYW4gdXBkYXRlIGluIHRoZSBlZGl0IGJ1ZmZlciwgYXdhaXRpbmcgYSBmZXcgdXBk YXRlcyB0byB0aGUgRVZQTiBzZWN0aW9uIGFuZCBwb3NzaWJseSB0aGUgTDJWUE4gc2VjdGlvbiAo dG8gaW5jb3Jwb3JhdGUgYW55IG5lY2Vzc2FyeQ0KIGRpc2N1c3Npb24gb2YgUkZDIDcxMTcpLCBi dXQgSSB3YW50ZWQgdG8gZ28gYWhlYWQgYW5kIHJlc3BvbmQgbm93IHRoYXQgbW9zdCBvZiB0aGUg Y29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBvdXIgZWRpdHMgYXQgbGVhc3QuJm5ic3A7 PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyI+V2VzIEdlb3JnZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7 QWx2YXJvIFJldGFuYSAoYXJldGFuYSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5h QGNpc2NvLmNvbSI+YXJldGFuYUBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VHVlc2RheSwgQXVndXN0IDUsIDIwMTQgYXQg Mjo0NCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZx dW90OzxhIGhyZWY9Im1haWx0bzpydGctYWRzQHRvb2xzLmlldGYub3JnIj5ydGctYWRzQHRvb2xz LmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0Zy1hZHNAdG9vbHMuaWV0 Zi5vcmciPnJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpydGctZGly QGlldGYub3JnIj5ydGctZGlyQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ0Zy1kaXJAaWV0Zi5vcmciPnJ0Zy1kaXJAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtbXBscy1pcHY2LW9ubHktZ2FwLmFsbEB0b29scy5pZXRmLm9y ZyI+ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPC9hPiZx dW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAu YWxsQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC5hbGxAdG9v bHMuaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmci Pm1wbHNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9y ZyI+bXBsc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPlN1YmplY3Q6IDwvc3Bhbj5bbXBsc10gUnRnRGlyIHJldmlldzogZHJhZnQtaWV0Zi1tcGxz LWlwdjYtb25seS1nYXAtMDE8YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 ICI+DQo8cCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxzdHJvbmc+Q29tbWVudHM6PC9zdHJv bmc+PC9wPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCkkgZG8gaGF2ZSBhIGNvdXBs ZSBvZiBoaWdoLWxldmVsIGl0ZW1zIEkgd2FudCB0byBicmluZyB1cC4gJm5ic3A7QmVjYXVzZSBJ IGFzc3VtZSB0aGF0IHRoZXNlIG1heSBoYXZlIGFscmVhZHkgYmVlbiBkaXNjdXNzZWQgaW4gdGhl IGFwcHJvcHJpYXRlIFdHKHMpIEknbSBub3QgbGlzdGluZyB0aGVtIGFzIG1ham9yIGlzc3Vlcywg YW5kIHdpbGwgZGVmZXIgdG8gd2hhdCB0aGUgY29uc2Vuc3VzIGhhcyBiZWVuIHNvIGZhci48L2Rp dj4NCjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjxsaT5XaHkgZG8gd2UgbmVlZCB0byBw dWJsaXNoIHRoaXMgZG9jdW1lbnQ/ICZuYnNwO0FzIEkgc2FpZCBhYm92ZSwgSSBiZWxpZXZlIHRo ZSB3b3JrIGlzIHZhbHVhYmxlLCBidXQgaXQgY2FwdHVyZXMgdGhlIHN0YXRlIGluIHRpbWUgKHRv ZGF5ISkgb2YgdGhlIGdhcHMg4oCUIGl0IHBvaW50cyB0byB3b3JrIHRoYXQgYWxyZWFkeSBzb2x2 ZWQgYSBwb3RlbnRpYWwgZ2FwLCBvciBpcyBpbiB0aGUgcHJvY2VzcyBvZiBzb2x2aW5nIHRoZW0u ICZuYnNwO0Egc2lnbmlmaWNhbnQNCiBwb3J0aW9uIG9mIHRoZSBnYXBzIGFyZSBhbHJlYWR5IGJl aW5nIGFkZHJlc3NlZC4gJm5ic3A7R2l2ZW4gdGhlIGltcG9ydGFuY2Ugb2YgSVB2NiwgaWYgcHVi bGlzaGVkLCBzb29uIHRoaXMgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIGJlIHVwZGF0ZWQgdG8gc2F5 ICZxdW90O25vdGhpbmcgYnJlYWtzJnF1b3Q7LiAmbmJzcDtBZ2FpbiwgdGhlIHdvcmsgaXMgaW1w b3J0YW50LCBidXQgaXQgbWF5IGJlIGJldHRlciBzdWl0ZWQgdG8gYmUgYSAmcXVvdDtsaXZpbmcg ZG9jdW1lbnQmcXVvdDsgYXMgYSBndWlkZQ0KIGZvciB3aGF0IHN0aWxsIG5lZWRzIHRvIGJlIGFk ZHJlc3NlZC4gJm5ic3A7SWYgaXQgaXMgdG8gYmUgcHVibGlzaGVkLCBJIHdvdWxkIHN1Z2dlc3Qg YXZvaWRpbmcgbGlua3MgdG8gd29yayBpbiBwcm9ncmVzcywgYnV0IGxpbWl0aW5nIHRoZSBjb250 ZW50IHRvIGlkZW50aWZ5aW5nIHRoZSBnYXBzLi5hbmQgdGhlbiBsZXR0aW5nIHRoZSBzb2x1dGlv biBkcmFmdHMvUkZDcyBwb2ludCBiYWNrIHRvIHRoaXMgZG9jdW1lbnQuLiAmbmJzcDsoYWxhIHJl cXVpcmVtZW50cw0KIC0mZ3Q7IHNvbHV0aW9uKTwvbGk+PGxpPkl0IGlzIGludGVyZXN0aW5nIHRv IG1lIHRoYXQgdGhpcyBkcmFmdCBjYW1lIHRocm91Z2ggdGhlIG1wbHMgV0csIGFuZCBub3Qgb25l IG9mIHRoZSBvcGVyYXRpb25zLWZvY3VzZWQgZ3JvdXBzLi53aGljaCBwcmVzdW1hYmx5IHdvdWxk IGJlIGluIGEgYmV0dGVyIHBvc2l0aW9uIHRvIGV2YWx1YXRlIHRoZSBuZWVkcyBkZXNjcmliZWQu ICZuYnNwO0dpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGlzIGFscmVhZHkgaW4gV0cgTGFzdCBDYWxs LCBJJ20gYXNzdW1pbmcNCiB0aGF0IHRoZSBhbGlnbm1lbnQgaGFzIGFscmVhZHkgYmVlbiBkaXNj dXNzZWQgYW5kIHRoYXQgcHJvcGVyIGNyb3NzLVdHIHJldmlld3MgaGF2ZSBvY2N1cnJlZC48L2xp Pjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gQ3Jvc3MtV0cgcmV2aWV3 cyBoYXZlbid0IG9jY3VycmVkLCBidXQgd2UgdmlldyBNUExTJ3MgYWN0aXZlIHBhcnRpY2lwYW50 cyBhcyBhIHN1cGVyc2V0IG9mIHRoZSBwYXJ0aWNpcGFudHMgb2YgbW9zdCBvZiB0aGUgTVBMUy1k ZXBlbmRlbnQgV0dzLCBhbmQgYWxzbyBhIGdvb2Qgc291cmNlIG9mIGNyb3NzLVdHIGdlbmVyYWxp c3RzIGFuZCBleHBlcnRzIG9uIE1QTFMuIEl0J3MgdW5jbGVhciB0byBtZSB3aGF0IG5lZWRzIHNo b3VsZA0KIGJlIGV2YWx1YXRlZCBieSB0aGUgb3BlcmF0aW9ucy1mb2N1c2VkIFdHcywgZ2l2ZW4g dGhhdCB0aGUgaXNzdWUgY2FtZSBmcm9tIGEgcHJvYmxlbSB0aGF0IGFuIGFjdHVhbCBvcGVyYXRv ciBleHBlcmllbmNlZCAobmFtZWx5LCBtZSkgYW5kIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgbmVl ZCBmb3IgTVBMUyB0byB3b3JrIG9uIGFuIElQdjYtb25seSBvciBJUHY2LXByaW1hcnkgbmV0d29y ayBpcyBwYXJ0aWN1bGFybHkgY29udHJvdmVyc2lhbCBhbnl3YXkuDQogSWYgcGVvcGxlIGJlbGll dmUgdGhhdCB0aGVyZSBpc24ndCBlbm91Z2ggb3ZlcmxhcCwgd2UgY2FuIGNlcnRhaW5seSBzb2xp Y2l0IHJldmlld3MgZnJvbSBzb21lIG9mIHRoZSBvdGhlciBXR3MgaW52b2x2ZWQuIEF3YWl0aW5n IEFEL1dHIGNoYWlyIGd1aWRhbmNlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2Un dmUgZGlzY3Vzc2VkIHRoaXMgcXVlc3Rpb24gYWJvdXQgd2hldGhlciB0byBwdWJsaXNoIGEgZ2Fw IGFuYWx5c2lzIGF0IGFsbCBzb21ld2hhdCBvZmZsaW5lLCBidXQgSSdtIGluY2x1ZGluZyBhIGZl dyBwb2ludHMgZm9yIHRoZSByZWNvcmQgYW5kIGZvciBXRyBjb21tZW50IGhlcmUuIEZpcnN0LCBt eSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBnYXAgYW5hbHlzaXMgc2hvdWxkbid0IHByb2NlZWQg dG8gUkZDIHVudGlsIGEgY29uc2Vuc3VzDQogZXhpc3RzIHRoYXQgd2UgaGF2ZSByZWFzb25hYmx5 IGNhcHR1cmVkIGFsbCBvZiB0aGUgZXhpc3RpbmcgZ2Fwcy4gSW4gb3RoZXIgd29yZHMsIHRoaXMg aXMgYSBkb2N1bWVudGF0aW9uIG9mIGFsbCBvZiB0aGUgZ2FwcyB0aGF0IHdlIGFzIGEgY29sbGVj dGl2ZSBncm91cCBvZiB0aGUgU21hcnQgUGVvcGxlIFdobyBLbm93IEFib3V0IFN1Y2ggVGhpbmdz IGNvdWxkIHRoaW5rIG9mLCBhbmQgZXhwbGljaXQgZG9jdW1lbnRhdGlvbiBvZiBhcmVhcyB3aXRo b3V0DQogZ2FwcyB0byBjb25maXJtIHRoYXQgd2UgcmV2aWV3ZWQgdGhlbSB0byB2YWxpZGF0ZSB0 aGlzLiBOZXcgZ2FwcyBTSE9VTEQgTk9UIGRldmVsb3AsIGFzIG9uY2UgYSBnYXAgYW5hbHlzaXMg bGlrZSB0aGlzIGlzIHBlcmZvcm1lZCwgaXQgcmFpc2VzIGF3YXJlbmVzcyBzbyB0aGF0IHBlb3Bs ZSBpbiB0aGUgV0cgKGFuZCBBRHMpIHdpbGwgYXNrIG9mIGZ1dHVyZSB3b3JrLCAmcXVvdDtkb2Vz IHRoaXMgd29yayBvbiBhbiBJUHY2LW9ubHkgTVBMUyBuZXR3b3JrLA0KIGRvZXMgaXQgZGVwZW5k IG9uIGtub3duIGdhcHMgZG9jdW1lbnRlZCBpbiBSRkNubm5uIGJlaW5nIGFkZHJlc3NlZCwgb3Ig YXJlIGFkZGl0aW9uYWwgY2hhbmdlcyBuZWNlc3NhcnkgdG8gbWFrZSB0aGlzIHdvcmsgcHJvcGVy bHkgb24gSVB2Ni1vbmx5PyZxdW90OyZuYnNwOzwvZGl2Pg0KPGRpdj5TZWNvbmQsIEkgdGhpbmsg dGhpcyBnZW5lcmFsbHkgaGlnaGxpZ2h0cyBhIHByb2JsZW0gSUVURi13aWRlIHdoZW4gaXQgY29t ZXMgdG8gZ2FwIGFuYWx5c2VzLiBFaXRoZXIgdGhlIHdvcmsgaXMgYWxyZWFkeSBpbiBwcm9ncmVz cywgYW5kIGl0IHNlcnZlcyBhcyBhIG1ldGhvZCB0byBjYXRhbG9nIHRoZSBpc3N1ZXMgdG8gbWFr ZSBzdXJlIHdlIGhhdmUgdGhlbSBhbGwgYmVpbmcgYWRkcmVzc2VkLCBvciBpdCBzZXJ2ZXMgdG8g aWRlbnRpZnkNCiBwbGFjZXMgd2hlcmUgZnV0dXJlIHdvcmsgaXMgbmVlZGVkLiBUaGUgcHJvYmxl bSBpcyB0aGF0IHRoZSBJRVRGIGhhcyBubyBtZXRob2QgZGVmaW5lZCB0byBmb2xsb3cgdXAgb24g Z2FwIGFuYWx5c2VzIHRvIGVuc3VyZSB0aGF0IGZ1dHVyZSB3b3JrIGlkZW50aWZpZWQgYWN0dWFs bHkgZ2V0cyBjb21wbGV0ZWQsIHNob3J0IG9mIHRoZSBXRyBhZGRpbmcgaXRlbXMgdG8gaXRzIGNo YXJ0ZXIgdG8gZXhwbGljaXRseSBhZGRyZXNzIHRoZXNlIHRoaW5ncy4NCiBJZiB0aGUgZ2FwIGFu YWx5c2lzIHNwYW5zIFdHcywgb3IgdGhlcmUgaXNuJ3QgYW55b25lIGludGVyZXN0ZWQgaW4gYWRk cmVzc2luZyB0aGUgaWRlbnRpZmllZCBnYXAsIGl0IGNhbiBzb3J0IG9mIHJvdCBpbnNpZGUgdGhl IGFuYWx5c2lzIGFuZCBncmFkdWFsbHkgYmUgZm9yZ290dGVuLiBXZSdyZSBkZWFsaW5nIHdpdGgg dGhpcyBxdWVzdGlvbiBpbiBzdW5zZXQ0IG9uIHRoZSBvcmlnaW5hbCBzZXQgb2YgSVB2NiBnYXAg YW5hbHlzZXMgdGhhdCB3ZXJlDQogZG9uZSBvbiBSRkNzIDM3OTAtOTYsIGJlY2F1c2Ugbm8gb25l IGhhcyBhIGdvb2Qgc2Vuc2UgZm9yIHdoZXRoZXIgYWxsIG9mIHRoZSBnYXBzIGlkZW50aWZpZWQg aW4gdGhvc2UgZG9jdW1lbnRzIHdlcmUgYWRkcmVzc2VkLCBvciBhcmUgaW5kZWVkIHN0aWxsIHJl bGV2YW50LiBUaGlzIGRyYWZ0IGNhdGFsb2dzIGdhcHMgd2l0aCBwb2ludGVycyB0byB3aGVyZSB0 aGUgYXV0aG9ycyBrbm93IHRoZXJlIGlzIGFscmVhZHkgd29yayBiZWluZyBkb25lLA0KIHdoaWNo IHNlcnZlcyB0byBsaW5rIHRoZSB0d28sIGFuZCBlbnN1cmVzIHRoYXQgaXQncyBhcyBjbGVhciBh cyBwb3NzaWJsZSB3aGVyZSB0aGVyZSBhcmUgc3RpbGwgb3V0c3RhbmRpbmcgZ2FwcyB0aGF0IG5l ZWQgdG8gYmUgYWRkcmVzc2VkLCBhbmQgaXQnZCBiZSByZWFzb25hYmxlIHRvIGV4cGVjdCBhbnkg Zm9sbG93LW9uIGRvY3VtZW50cyB0aGF0IGFkZHJlc3MgZ2FwcyBpZGVudGlmaWVkIGFzIFRCRCBp biB0aGlzIGRvY3VtZW50IHRvIGZvcm1hbGx5DQogdXBkYXRlIHRoaXMgZG9jdW1lbnQgc28gdGhh dCB0aGUgbGluayBpcyBwcmVzZW50IGJldHdlZW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlIGZ1dHVy ZSBkb2N1bWVudHMgYWRkcmVzc2luZyBzb21lIG9mIHRoZSBnYXBzIHRoYXQgaXQgaWRlbnRpZmll ZCBhcyBub3QgaGF2aW5nIGZpeGVzIGluIHByb2dyZXNzLiBJdCdzIHRoZSBiZXN0IHdlIGNhbiBk byB3aXRoICZxdW90O2Zyb3plbiBpbiB0aW1lJnF1b3Q7IGRvY3VtZW50cyBsaWtlIHRoaXMsIGJ1 dCBJIHRoaW5rIGl0J3MNCiBhY2NlcHRhYmxlLiZuYnNwOzwvZGl2Pg0KPGRpdj5VbHRpbWF0ZWx5 LCBJIHRoaW5rIHlvdXIgcXVlc3Rpb24gaXMgYSBsYXJnZXIgaXNzdWUgYW5kIHRoaXMgZ2FwIGFu YWx5c2lzIGlzIG5vIGRpZmZlcmVudCB0aGFuIGFueSBvdGhlciDigJMgdGhlIHF1ZXN0aW9uIG9m ICZxdW90O3Nob3VsZCB3ZSBwdWJsaXNoJnF1b3Q7IGlzIHJlYWxseSAmcXVvdDtzaG91bGQgd2Ug cHVibGlzaA0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OiBib2xkOyI+YW55PC9zcGFuPiZuYnNw O2dhcCBhbmFseXNpcyBhcyBhbiBSRkMgZ2l2ZW4gdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBzZXJp ZXM/JnF1b3Q7IGFuZCB0aGF0J3Mgbm90IHNvbWV0aGluZyB3ZSdyZSBnb2luZyB0byBzb2x2ZSBo ZXJlLCBzbyBJIHRoaW5rIGl0J3MgYSBtYXR0ZXIgb2YgcHVibGlzaGluZyB0aGUgZG9jdW1lbnQg aWYgdGhlIGNvbnRlbnQgaXMgaGVscGZ1bC4mbmJzcDs8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JD X0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8YnI+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8cCBzdHlsZT0ibWFyZ2lu OiAwcHggMHB4IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+PGI+TWlub3IgSXNzdWVzOjwv Yj48L3A+DQo8dWw+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJy aTsiPlNvbWUgdGVybWlub2xvZ3kgd2FzIG5vdCBleHBhbmRlZCBiZWZvcmUvd2hlbiBpdCB3YXMg Zmlyc3QgdXNlZDogd2UgYWxsIGtub3cgd2hhdCBNUExTIGlzLCBidXQgb3RoZXJzIGxpa2UgTFNS LCBMRVIsIEZFQywgTDJWUE4sIEVWUE4sIE5HLW1WUE4sIGV0Yy4gc2hvdWxkIGJlIGV4cGFuZGVk Lg0KPC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJy aTsiPldHXSBJIGJlbGlldmUgdGhpcyBpcyBmaXhlZCBub3c8L3A+DQo8dWw+DQo8bGkgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPlNlY3Rpb24gMy4xIChNUExTIERh dGEgUGxhbmUpOiAmcXVvdDtJbiB0aGUgY2FzZSB3aGVyZSBhbiBJUHY0IHByZWZpeCBpcyByZXNv bHZlZCBvdmVyIGFuIElQdjYgTFNQLCBhbiZuYnNwO0lQdjYgRXhwbGljaXQgTnVsbCBsYWJlbCBj YW5ub3QgaW1tZWRpYXRlbHkgcHJlY2VlZCBhbiBJUHY0IHBhY2tldC4mcXVvdDsgJm5ic3A7SXMg dGhlcmUgYSByZWZlcmVuY2UgZm9yIHRoaXMgc3RhdGVtZW50IG9yDQogaXMgdGhpcyBhIHJlcXVp cmVtZW50IHRvIGZpbGwgaW4gdGhlIGdhcD8gJm5ic3A7SWYgaXQgaXMgYSByZXF1aXJlbWVudCwg ZG8gd2UgbmVlZCB0byBhZGQgMjExOSBsYW5ndWFnZT8NCjwvbGk+PC91bD4NCjxwIHN0eWxlPSJt YXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij4tLTxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPkl0IHJlYWxseSBjb21lcyBmcm9tIFJGQyAzMDMy LCBhbmQgdGhlbiBSRkMgNDE4Mi4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+T25lIGV4YW1wbGUgaXMgcDwvc3Bhbj5yZXNlbnQgaW4g UkZDNDc5ODwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2Pkhvd2V2ZXIsIGFmdGVy IHJldmlldywgd2UndmUgcmVtb3ZlZCB0aGlzIHRleHQsIGJlY2F1c2Ugd2UgZG9uJ3QgdGhpbmsg dGhhdCB0aGlzIGlzIGFjdHVhbGx5IGEgZ2FwLCBhbmQgdGhlIHRleHQgd2FzIGNvbmZ1c2luZyAo ZXZlbiB0byB5b3VyIGh1bWJsZSBlZGl0b3IpLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9E WV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyAiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsgIj4NCjx1bD4NCjxs aSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+V2hlbiBhIGdhcCBl eGlzdHMsIHlvdSBjbGFzc2lmeSBpdCBhcyAmcXVvdDttYWpvciZxdW90OyBvciAmcXVvdDttaW5v ciZxdW90Oy4gJm5ic3A7V2hhdCBpcyB0aGUgY3JpdGVyaWEgdXNlZD8gJm5ic3A7SSB3b3VsZCBp bWFnaW5lIHRoYXQgZ2l2ZW4gdGhhdCBpdCBpcyBhIGdhcCBhbmFseXNpcywgdGhlIG9iamVjdGl2 ZSBpcyB0byBwb2ludCBvdXQgdGhlIG5lZWRzLCBub3QgY2hhcmFjdGVyaXplIHRoZW0gKGlmIEkN CiBuZWVkIGEgJnF1b3Q7bWlub3ImcXVvdDsgZ2FwIHRvIGJlIGZpbGxlZCBpbiBvcmRlciBmb3Ig bXkgbmV0d29yayBkZXBsb3ltZW50IHRvIG9wZXJhdGUsIGl0IGJlY29tZXMgJnF1b3Q7bWFqb3Im cXVvdDsgdG8gbWUpLg0KPC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZh bWlseTogQ2FsaWJyaTsiPldHXSBBZGRlZCB0ZXh0IHRvIHRoZSBiZWdpbm5pbmcgb2Ygc2VjdGlv biAzIGV4cGxhaW5pbmcgdGhlIHRlcm1zOjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9u dC1mYW1pbHk6IENhbGlicmk7Ij4mcXVvdDtBIG5vdGUgYWJvdXQgdGVybWlub2xvZ3k6IEdhcHMg YXJlIHR5cGljYWxseSBjaGFyYWN0ZXJpemVkIGFzICZxdW90O01ham9yJnF1b3Q7LCAmcXVvdDtN aW5vciZxdW90OyBvciAmcXVvdDtub25lJnF1b3Q7LiBNYWpvciBnYXBzIHJlZmVyIHRvIHNpZ25p ZmljYW50IGNoYW5nZXMgbmVjZXNzYXJ5IGluIG9uZSBvciBtb3JlIHN0YW5kYXJkcyB0byBhZGRy ZXNzIHRoZSBnYXAgZHVlIHRvIGV4aXN0aW5nIHN0YW5kYXJkcw0KIGxhbmd1YWdlIGhhdmluZyBl aXRoZXIgbWlzc2luZyBmdW5jdGlvbmFsaXR5IGZvciBJUHY2LW9ubHkgb3BlcmF0aW9uIG9yIGV4 cGxpY2l0IGxhbmd1Z2UgcmVxdWlyaW5nIHRoZSB1c2Ugb2YgSVB2NCB3aXRoIG5vIElQdjYgYWx0 ZXJuYXRpdmVzIGRlZmluZWQuIE1pbm9yIGdhcHMgcmVmZXIgdG8gY2hhbmdlcyBuZWNlc3Nhcnkg cHJpbWFyaWx5IHRvIGNsYXJpZnkgZXhpc3Rpbmcgc3RhbmRhcmRzIGxhbmd1YWdlLiBVc3VhbGx5 IHRoZXNlIGNoYW5nZXMNCiBhcmUgbmVlZGVkIGluIG9yZGVyIHRvIGV4cGxpY2l0bHkgY29kaWZ5 IElQdjYgc3VwcG9ydCBpbiBwbGFjZXMgd2hlcmUgaXQgaXMgZWl0aGVyIGltcGxpY2l0IG9yIG9t aXR0ZWQgdG9kYXksIGJ1dCB0aGUgb21pc3Npb24gaXMgdW5saWtlbHkgdG8gcHJldmVudCBJUHY2 LW9ubHkgb3BlcmF0aW9uLiZxdW90OzwvcD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1m YW1pbHk6IENhbGlicmk7IG1pbi1oZWlnaHQ6IDE3cHg7Ij48YnI+DQo8L3A+DQo8dWw+DQo8bGkg c3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPlRoZSBpbnRyb2R1Y3Rp b24gdG8gdGhlIGRyYWZ0IHRhbGtzIGFib3V0ICZxdW90O2dhcHMgdGhhdCBtdXN0IGJlIGFkZHJl c3NlZCBpbiBvcmRlciB0byBhbGxvdyBNUExTLXJlbGF0ZWQgcHJvdG9jb2xzJm5ic3A7YW5kIGFw cGxpY2F0aW9ucyB0byBiZSB1c2VkIHdpdGggSVB2Ni1vbmx5IG5ldHdvcmtzJnF1b3Q7ICgmcXVv dDtJUHY2LW9ubHkgKG5vIElQdjQmbmJzcDtwcm92aXNpb25lZCBvbiB0aGUgZGV2aWNlKSZxdW90 OyksDQogd2hpY2ggZ2l2ZXMgdGhlIGltcHJlc3Npb24gdGhhdCBubyBJUHY0IGlzIHByZXNlbnQg aW4gdGhlIG5ldHdvcmsgYXQgYWxsLiAmbmJzcDsmbmJzcDtIb3dldmVyLCBzZXZlcmFsIGdhcHMg YXJlIGlkZW50aWZpZWQgdGhhdCBvY2N1ciBpbiAmcXVvdDttaXhlZCZxdW90OyBuZXR3b3Jrcywg d2hlcmUgaXNsYW5kcyBvZiBJUHY0L0lQdjYgZXhpc3QuICZuYnNwO0kgd291bGQgc3VnZ2VzdCBj bGFyaWZ5aW5nIHRoZSBzY29wZSBvZiB0aGUmbmJzcDtkb2N1bWVudCBpbiB0aGUgaW50cm9kdWN0 aW9uLiAmbmJzcDtTb21lDQogb2YgdGhlIHBsYWNlcyB3aGVyZSB0aGVzZSBzY2VuYXJpb3MgYXJl IGRpc2N1c3NlZCBpbmNsdWRlOiAmbmJzcDszLjIuMi4gKE11bHRpcG9pbnQgTERQKSwmbmJzcDsz LjMuMi4gKEwzVlBOKSwgJm5ic3A7My40LjEuIChFeHRlbmRlZCBJQ01QKSBhbmQmbmJzcDszLjQu Mi4gKExTUCBQaW5nKS4NCjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1m YW1pbHk6IENhbGlicmk7Ij5XR10gYSBmZXcgc2VudGVuY2VzIGJlZm9yZSwgdGhlIGRvY3VtZW50 IHNheXMgJnF1b3Q7YW55IG5ldHdvcmtzIHdpbGwgbmVlZCB0byBzdGFydCBvcGVyYXRpbmcgc29t ZSBvciBhbGwgb2YgdGhlaXIgbmV0d29yayBub2RlcyBlaXRoZXIgYXMgcHJpbWFyaWx5IElQdjYg KG1vc3QgZnVuY3Rpb25zIHVzZSBJUHY2LCBhIGZldyBsZWdhY3kgZmVhdHVyZXMgdXNlIElQdjQp LCBvcg0KIGFzIElQdjYtb25seSAobm8gSVB2NCBwcm92aXNpb25lZCBvbiB0aGUgZGV2aWNlKSZx dW90OyBEbyB3ZSBzaW1wbHkgbmVlZCB0byBhZGQgc2ltaWxhciBsYW5ndWFnZSB0byB0aGUgbmV4 dC10by1sYXN0IHNlbnRlbmNlLCBkb2VzIHRoZSBleGlzdGluZyB0ZXh0IG1ha2UgaXQgY2xlYXIg bm93IHRoYXQgSSd2ZSBoaWdobGlnaHRlZCBpdCwgb3IgaXMgbW9yZSByZXF1aXJlZD88L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0OiAx N3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1p bHk6IENhbGlicmk7Ij4zLjMuMS4xLiAoRVZQTikgJm5ic3A7SWYgdGhlIEVWUE4gd29yayBpcyBv dXQgb2YgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCwgdGhlbiB0YWtlIGl0IG91dC4gJm5ic3A7 QW5vdGhlciBvcHRpb24gbWF5IGJlIHRvIHRhbGsgYWJvdXQgYW55IGdhcHMgaW4gdGhlIGN1cnJl bnQgd29yay4gJm5ic3A7U2FtZSBjb21tZW50IGZvciBzZWN0aW9uJm5ic3A7My4zLjIuNC4zLiAo UEUtUEUgTXVsdGljYXN0DQogUm91dGluZyBQcm90b2NvbCkuIDwvbGk+PC91bD4NCjxwIHN0eWxl PSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij5XR10gRVZQTiBkcmFmdCBpcyBw ZW5kaW5nIElFU0cvSUVURiBMQywgc28gaXQncyBub3Qgc28gbXVjaCBvZiBhIHdvcmsgaW4gcHJv Z3Jlc3MgYW55bW9yZSwgYW5kIHdpbGwgbGlrZWx5IGhpdCBwdWJsaWNhdGlvbiBwcmlvciB0byB0 aGlzIGRvY3VtZW50LiBJIGhhdmUgZW1haWxlZCBFVlBOIGF1dGhvcnMgdG8gcmVxdWVzdCB0aGF0 IHRoZXkgY29uc2lkZXIgRVZQTiBpbg0KIHRoZSBJUHY2LW9ubHkgb3BlcmF0aW9uIGNvbnRleHQg b2YgdGhpcyBkcmFmdCwgYW5kIGVpdGhlciBjb25maXJtIHRoYXQgdGhlcmUgYXJlIG5vIGdhcHMs IHRoYXQgdGhlcmUgYXJlIGRlcGVuZGVuY2llcyBvbiBnYXBzIGFscmVhZHkgaWRlbnRpZmllZCwg b3IgcmVzb2x2ZSBhbnkgZ2FwcyBwcmVzZW50IHRoYXQgYXJlIHVuaXF1ZSB0byBFVlBOIHByaW9y IHRvIExDLiBUaGUgc2VjdGlvbiB3aWxsIGJlIHVwZGF0ZWQgYWNjb3JkaW5nbHkgdG8gcmVtb3Zl DQogdGhlIGNvbW1lbnRzIGFib3V0IGl0IGJlaW5nIG91dCBvZiBzY29wZSBhbmQgYWRkIGEgYnJp ZWYgZ2FwIGFuYWx5c2lzIGJhc2VkIG9uIHRoZSByZXN1bHRzIG9mIHRoYXQgZGlzY3Vzc2lvbi4m bmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBt aW4taGVpZ2h0OiAxN3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBw eDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij4zLjMuMi4gKEwzVlBOKSAmbmJzcDt0aGUgdGV4dCBz YXlzIHRoYXQgdGhlIGdhcHMgaW4gUkZDNDM2NCAobm8mbmJzcDtWUE4tSVB2NiBhZGRyZXNzIGFu ZCBhJm5ic3A7MTI4IGJpdCBuZXh0LWhvcCkgaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiBSRkMgNDY1 OSwgYnV0IGl0IHRoZW4gaWRlbnRpZmllcyB0aGUgZ2FwIGFuZCBzYXlzIHRoYXQgJnF1b3Q7UkZD NDM2NCBtdXN0IGJlIHVwZGF0ZWQmcXVvdDsuICZuYnNwO1doYXQNCiB3b3VsZCB0aGF0IHVwZGF0 ZSBiZT8gPC9saT48L3VsPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaTsiPldHXSBZb3UncmUgcmlnaHQsIHRoaXMgd2FzIHJlYWxseSBjb25mdXNpbmcgYXMgd3Jp dHRlbi4gTWFkZSBzaWduaWZpY2FudCBjaGFuZ2VzIHRvIHRoaXMgc2VjdGlvbi4gVGhlcmUgYXJl IG5vIGdhcHMgaW4gNDM2NC4gVGhlIHJlYWwgcHJvYmxlbSBpcyB0aGF0IDQ2NTkgdXBkYXRlcyA0 MzY0IGFuZCBmaXhlcyB0aG9zZSBnYXBzLCBidXQgaXQgZG9lc24ndCBmb3JtYWxseQ0KIHVwZGF0 ZSA0MzY0IGluIHRoZSBtZXRhZGF0YSwgc28gaXQgbG9va3MgbGlrZSB0aGVyZSBhcmUgZ2FwcyBl eHRhbnQgaW4gNDM2NC4gSXQgYWxzbyBleHBsaWNpdGx5IGNhbGxzIHVzZSBjYXNlICMyIG91dCBv ZiBzY29wZS4mbmJzcDs8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBD b25zb2xhczsgY29sb3I6IHJnYig0LCA0NiwgMjM4KTsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPkkgZmlsZWQgYW4gZXJyYXR1bSB0byBm aXggNDY1OSdzIG1ldGFkYXRhOg0KPGEgaHJlZj0iaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9l cnJhdGFfc2VhcmNoLnBocD9yZmM9NDY1OSZhbXA7ZWlkPTQwODciPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogQ29uc29sYXM7Ij5odHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YV9zZWFy Y2gucGhwP3JmYz00NjU5JmFtcDtlaWQ9NDA4Nzwvc3Bhbj48L2E+PC9zcGFuPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7IG1pbi1oZWlnaHQ6IDE3cHg7 Ij48YnI+DQo8L3A+DQo8dWw+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTog Q2FsaWJyaTsiPlNlY3Rpb25zIDMuMy4yLjQuMy4gKFBFLVBFIE11bHRpY2FzdCBSb3V0aW5nIFBy b3RvY29sKSwmbmJzcDszLjMuMy4gKE1QTFMtVFApIGFuZCZuYnNwOzMuNC41LiAoTVBMUy1UUCBP QU0pJm5ic3A7YXJlIGluY2x1ZGVkLCBidXQgb3V0IG9mIHNjb3BlLi4gJm5ic3A7U2hvdWxkIHRo ZXkgYmUgcmVtb3ZlZD8gJm5ic3A7SWYgbm90LCB0aGVuIGEgc2hvcnQganVzdGlmaWNhdGlvbiBp biB0aGUgdGV4dCB3b3VsZA0KIGJlIG5pY2UuIDwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46 IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij5XR10gY2xhcmlmaWVkPC9wPg0KPHAgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxi cj4NCjwvcD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxp YnJpOyI+My40LiAoTVBMUyBPQU0pICZuYnNwO1RoaXMgc2VudGVuY2UgJnF1b3Q7QWxsIG9mIHRo ZXNlJm5ic3A7bWVjaGFuaXNtcyB3b3JrIGluIHB1cmUgSVB2NiBlbnZpcm9ubWVudHMuJnF1b3Q7 IGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQgYWxsIHRoZSBtZWNoYW5pc21zIHdvcmsgY29ycmVj dGx5IGFuZCB0aGF0IHRoZXJlIGFyZSBubyBnYXBzLi5idXQgdGhlbiBzZXZlcmFsIGdhcHMgYXJl IGxpc3RlZC4NCjwvbGk+PC91bD4NCjxwIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6 IENhbGlicmk7Ij5XR10gTWFkZSBzb21lIHdvcmRpbmcgY2hhbmdlcyBpbiAzLjQgYW5kIExTUCBw aW5nIHNlY3Rpb24gMy40LjIgZm9yIGNsYXJpdHkuJm5ic3A7PC9wPg0KPHAgc3R5bGU9Im1hcmdp bjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxicj4NCjwv cD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ VGFibGUgMTogSVB2Ni1vbmx5IE1QTFMgR2Fwcy4gJm5ic3A7VGhlIHRhYmxlIGRvZXNuJ3QgaW5j bHVkZSBhbGwgdGhlIGdhcHMgaWRlbnRpZmllZC4gJm5ic3A7Rm9yIGV4YW1wbGUsJm5ic3A7My4y LjIuIChNdWx0aXBvaW50IExEUCkgaXMgbm90IGluY2x1ZGVkIGluIHRoZSB0YWJsZSwgZXZlbiB0 aG91Z2ggYSBtYWpvciBnYXAgd2FzIGlkZW50aWZpZWQuICZuYnNwO0luIHRoaXMgY2FzZSwgdGhl IHdvcmsNCiBpbiB0aGUgdGFibGUgZm9yIExEUCBtYXkgYWxzbyBhZGRyZXNzIHRoZSBnYXAgaW4g bUxEUCwgYnV0IHRoYXQgaXMgbm90IHBvaW50ZWQgb3V0IGluIHRoZSB0YWJsZS4uICZuYnNwO0lu IHNob3J0LCB0aGUgdGFibGUgaXMgbm90Jm5ic3A7Y29tcGxldGUuDQo8L2xpPjwvdWw+DQo8cCBz dHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+V0ddIEZpeGVkPC9wPg0K PHAgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDog MTdweDsiPjxicj4NCjwvcD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyI+U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMuICZuYnNwO1RoaXMgc2VjdGlv biB0YWxrcyBhYm91dCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiBjdXJyZW50IHNwZWNpZmlj YXRpb25zLi5idXQgaXQgbGVhdmVzIG91dCBtZW50aW9uIG9mIHRoZSBmYWN0IHRoYXQgbmV3IHNw ZWNpZmljYXRpb25zICh0byBjbG9zZSB0aGUgZ2Fwcykgc2hvdWxkIChNVVNUID8pIGNvbnNpZGVy IHRoZQ0KIGVmZmVjdCBvZiBJUHY2LiA8L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+V0ddIEZpeGVkPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjog MHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxicj4NCjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij48 Yj5OaXRzOjwvYj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDE0cHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyI+PGI+R2xvYmFsIEFDSy4gQ291cGxlIG9mIHNwZWNpZmljIGNvbW1lbnRz OjwvYj48L3A+DQo8dWw+DQo8bGkgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaTsiPlNlY3Rpb24gMyAoR2FwIEFuYWx5c2lzKS4gJm5ic3A7WW91IHdyb3RlOiAmcXVvdDtU aGlzIGdhcCBhbmFseXNpcyBhaW1zIHRvIGFuc3dlciB0aGUgcXVlc3Rpb24sICZxdW90O3doYXQg YnJlYWtzIHdoZW4gb25lJm5ic3A7YXR0ZW1wdHMgdG8gdXNlIE1QTFMgZmVhdHVyZXMgb24gYSBu ZXR3b3JrIG9mIElQdjYtb25seSBkZXZpY2VzPyZxdW90OyAmbmJzcDtXaGlsZSBJIHVuZGVyc3Rh bmQgd2hhdCB5b3UncmUgYXNraW5nLA0KIGluIHJlYWxpdHkgeW91J3JlIHRyeWluZyB0byBhbnN3 ZXIgJnF1b3Q7d2hhdCBkb2Vzbid0IHdvcmsuLiZxdW90Oy4gJm5ic3A7QnJlYWtpbmcgaW1wbGll cyB0aGF0IGl0IG1heSB3b3JrIGZvciBhIHdoaWxlIGFuZCB0aGVuIHN0b3AgZG9pbmcgc28uDQo8 L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ V0ddIGNoYW5nZWQgdG8gZmFpbHM8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyBtaW4taGVpZ2h0OiAxN3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0 eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij4zLjMuMi4gKEwzVlBOKSAm bmJzcDsgVGhlIGdhcCBzZWN0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgdGV4dDogJnF1b3Q7 RGlzY3Vzc2VkIGluIGZ1cnRoZXImbmJzcDtkZXRhaWwgYmVsb3cmcXVvdDsuICZuYnNwO0l0IHdv dWxkIGJlIG5pY2UgdG8gaGF2ZSBhbiBhY3R1YWwgcmVmZXJlbmNlIHRvIHRoZSBzZWN0aW9uIGlu c3RlYWQgb2YgdGhlIHRleHQuDQo8L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PGRpdj5XR10gSXQncyBpbiB0aGUgbmV4dCBwYXJhZ3JhcGgsIGlzIGZ1cnRoZXIgZ3VpZGFuY2Ug cmVhbGx5IG5lY2Vzc2FyeT88L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8dWw+DQo8bGkgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPkV2ZW4gdGhvdWdoIHNlY3Rpb25zIDMu My4yLjEgYW5kIDMuMy4yLjIgYXJlIHN1YnNlY3Rpb25zIG9mIDMuMy4yLCB3aXRoIHNvIG1hbnkg c2NlbmFyaW9zIGJlaW5nIGNvdmVyZWQsIGl0IGdldHMgaGFyZCB0byBrZWVwIHRyYWNrIG9mIHdo ZXJlIHNvbWV0aGluZyB3YXMmbmJzcDtkZXNjcmliZWQuICZuYnNwO0l0IHdvdWxkIGJlIHZlcnkg bmljZSB0byBpbmNsdWRlIHJlZmVyZW5jZXMNCiB0byB3aGVyZSAmcXVvdDt1c2UgY2FzZSAjMiZx dW90OyB3YXMgZGVmaW5lZCBpbiZuYnNwO3NhYyZuYnNwO29mIHRob3NlIHN1YnNlY3Rpb25zLiA8 L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+ V0ddIHdoaWxlIHRoZXNlIHJlZmVyZW5jZXMgY291bGQgYmUgYWRkZWQsIGl0IGNvdmVycyBsZXNz IHRoYW4gYSBwYWdlIG9mIHRleHQgd2l0aGluIG9uZSBzdWJzZWN0aW9uLiBJJ20gbm90IGNvbnZp bmNlZCB0aGlzIGlzIGFuIGFjdHVhbCBwcm9ibGVtPC9wPg0KPHAgc3R5bGU9Im1hcmdpbjogMHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaTsgbWluLWhlaWdodDogMTdweDsiPjxicj4NCjwvcD4NCjx1 bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyI+My4zLjIu NC4yLiAoUC1UdW5uZWwgSW5zdGFudGlhdGlvbikgJm5ic3A7DQo8dWw+DQo8bGkgc3R5bGU9Im1h cmdpbjogMHB4OyBmb250LWZhbWlseTogQ2FsaWJyaTsiPiZxdW90Oy4gLiAuY292ZXJlZCZuYnNw O2luIHByZXZpb3VzIHNlY3Rpb25zJnF1b3Q7LiAmbmJzcDtSZWZlcmVuY2VzIHBsZWFzZS48L2xp PjwvdWw+DQo8L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13 ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj4NCjxkaXYgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7ICI+DQo8 ZGl2PldHXSBhY2s8L2Rpdj4NCjx1bD4NCjx1bD4NCjxsaSBzdHlsZT0ibWFyZ2luOiAwcHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpOyI+JnF1b3Q7UElNIFRyZWUgYW5kIEluZ3Jlc3MgUmVwbGljYXRp b24gYXJlIG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyZuYnNwO2RvY3VtZW50Li4mcXVvdDsmbmJz cDtiZWNhdXNlLi4gJm5ic3A7RWl0aGVyIGV4cGxhaW4gd2h5IG9yIHJlbW92ZSB0aGVtIGZyb20g dGhlIGxpc3QgcmlnaHQgYmVmb3JlLg0KPC9saT48L3VsPg0KPC91bD4NCjxwIHN0eWxlPSJtYXJn aW46IDBweDsgZm9udC1mYW1pbHk6IENhbGlicmk7Ij5XR10gZml4ZWQsIGRpc2N1c3Npb24gYWRk ZWQ8L3A+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpOyBtaW4t aGVpZ2h0OiAxN3B4OyI+PGJyPg0KPC9wPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsg Zm9udC1mYW1pbHk6IENhbGlicmk7Ij4zLjQuMi4gKExTUCBQaW5nKSAmbmJzcDtzL0xTUCBQaW5n IHBhY2tldHMgYXJlIFVEUCBwYWNrZXRzIG92ZXIgYm90aCBJUHY0IGFuZCZuYnNwO0lQdjYvTFNQ IFBpbmcgcGFja2V0cyBhcmUgVURQIHBhY2tldHMgb3ZlciBlaXRoZXIgSVB2NCBvciZuYnNwO0lQ djY8L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gYWNrPC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRw eDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2IHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyAiPg0KPHVsPg0KPGxpIHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1mYW1pbHk6 IENhbGlicmk7Ij5UaGVyZSBpcyBzb21lIHVuZXZlbiB0cmVhdG1lbnQgaW4gdGhlIGRlc2NyaXB0 aW9uIG9mIHRoZSBzdXBwb3J0L2dhcHMuICZuYnNwO0l0IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlk ZSB0aGUgc2FtZSBsZXZlbCBvZiBkZXRhaWwgZXZlcnl3aGVyZSAoaWYgbmVlZGVkKS4gJm5ic3A7 Rm9yIGV4YW1wbGUsIDMuMi4zLjIgKFJTVlAtVEUtUDJNUCkgcGxhaW5seSBtZW50aW9ucyB0aGF0 IFJGQzQ4NzUNCiBjb3ZlcnMgdGhlIHN1cHBvcnQgZm9yIElQdjYuLndoaWxlIDMuNC4zIChCRkQg T0FNKSBtZW50aW9ucyB3aGVyZSBJUHY2IHN1cHBvcnQgdXMgZGVmaW5lZCBidXQgaXQgYWxzbyBw b2ludHMgdG8gdGhlIHNwZWNpZmljIHNlY3Rpb25zLiAmbmJzcDtJTUhPLCB0aGUgYWRkaXRpb25h bCBkZXRhaWwgaXMgbm90IG5lZWRlZCAodW5sZXNzIHZlcnkgc3BlY2lmaWMgcG9pbnRzIG5lZWQg dG8gYmUgbWFkZSkuDQo8L2xpPjwvdWw+DQo8cCBzdHlsZT0ibWFyZ2luOiAwcHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpOyI+V0ddIGF1dGhvcnMgYmVsaWV2ZSB0aGF0IHRoZSBkZXRhaWwgaXMgcHJv YmFibHkgbm90IGFic29sdXRlbHkgbmVjZXNzYXJ5LCBidXQgZG8gc2VlIGl0IGFzIHVzZWZ1bCBh bmQgdGhlcmVmb3JlIG5vIHJlYXNvbiB0byByZW1vdmUgaXQuJm5ic3A7PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvc3Bhbj48YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXki IHNpemU9IjEiPlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2lu ZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5DQog Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk ZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUt bWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNv bnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D019124D2BF6Dwesleygeorgetwcablecom_-- From nobody Wed Aug 20 09:03: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 A75931A03CF; Wed, 20 Aug 2014 09:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 W9CEWlixhx0R; Wed, 20 Aug 2014 09:03:35 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B34921A0453; Wed, 20 Aug 2014 09:03:34 -0700 (PDT) Received: from [192.168.0.101] (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 EA7961801586; Wed, 20 Aug 2014 18:03:32 +0200 (CEST) Message-ID: <53F4C6D4.2000505@pi.nu> Date: Wed, 20 Aug 2014 18:03:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/n8GboQnhzhlaX9KUx1tfQor3yo0 Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 20 Aug 2014 16:03:38 -0000 Alia A few quick questions on this. In the message that the RTG ADs sent to the wg chairs and directorate when the discussion on re-org started you said "First, we intend to use our Routing Directorate more proactively by introducing a Working Group Draft Quality Assurance (WG Draft QA) process where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call. The process will be documented on the Routing Area wiki. This should allow directorate reviews to report technical issues that can actually get fixed early in the process (equiv of bug reports) as opposed to just noting the concerns in the drafts (equiv of release notes)." It seems that there are a changes from what was said at that time and what is said now. "... where the same selected routing directorate member will review a draft during WG draft adoption and during WG last call" while we now say "...for all drafts that are being considered for WG adoption." What motivated this change? Second, some wg's have review teams that does something similar to the WG Draft QA process just prior to that the the call for working group adoption is started. Do we do the WG Draft QA in addition to, instead of these reviews, or can we continue doing the review team reviews instead of WG Draft QA? /Loa On 2014-08-20 16:45, Alia Atlas wrote: > Hi to all the Routing Area WG Chairs and Secretaries, > > As Adrian and I discussed prior to IETF 90 and in the Routing Area > meeting at IETF 90, > we would like to start using the new Draft Quality Assurance process ( > http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all > drafts that are being > considered for WG adoption. Drafts that are already WG drafts do not > need to go through this process - but chairs can ask if it seems desirable. > > As with many processes in the IETF, this process is intended to be used > for the spirit of the goal, subject to common-sense and technical > perspective. In particular, none of this process is intended to gate or > otherwise impede the normal progression of documents through IETF > working groups: rather, it is intended to provide additional input, > review, and comments that the working groups can use to help improve the > quality of their documents, and to help chairs determine quality and > consensus for documents. We do not expect IETF process to wait for > reviews to happen. > > As described on the wiki page, the detailed process is: > > 1. The WG Chair or Secretary emails the Routing Directorate > Coordinators ( Deborah Brungard >) and Jonathan Hardwick metaswitch.com >). The subject should be WG > Draft QA Requested: >. > > 2. The WG Chair or Secretary marks a draft in the datatracker as > "Candidate for Adoption" and specifies the date on which WG Draft QA > was requested. > > 3. The Routing Directorate Coordinators and WG Chairs agree and find a > QA Reviewer. The review can be done during the WG Call for Adoption. > The WG Chair or Secretary adds a comment in the draft's datatracker > history page indicating whom is the QA Reviewer. > > Please start doing this now. > > After IETF-91, we can discuss how this is going and its usefulness. > > Thanks, > Alia -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Aug 20 09:32: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 30B8D1A06FA; Wed, 20 Aug 2014 09:32:07 -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 TgSkUcjuAVdD; Wed, 20 Aug 2014 09:32:04 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91161A06A8; Wed, 20 Aug 2014 09:32:04 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so6756383ykq.35 for ; Wed, 20 Aug 2014 09:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XQZDvHhZD17M+BBHhzMyo/S9nPgE77STYDryB7bvRr8=; b=T/nA0lcCMDcZbt0yJ/xoz8mfwuGMeH7UBbadQTaCFkXDHe1P+E7EguV5L9tN1be/jl rbiD7OsKxVAv7rxF3hWfInzOyxTfUbYdNWdqIbrMpeaoGlQZtehpnet2IXVg0d5mHZKY sIueo9QNpL05aNGpdbKVeMQJ8leuwlb2RuvQTkEL+AcgJORh5m3f9SNUm8xHXLmkxmxD dUwCpABytMwCW2emEbBc5DN7kKmqPaY/nohJF1ZqWVIVjKSD1f2Vobu/P6a7VeRK5ys1 zI3DEyXVBB4sqasvgAEAZV+7Yr/u3U7hFG+8zvkKlfx8wb73/creTT7wUwTV5rpBlEO3 eBww== MIME-Version: 1.0 X-Received: by 10.236.164.70 with SMTP id b46mr74057970yhl.16.1408552323832; Wed, 20 Aug 2014 09:32:03 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Wed, 20 Aug 2014 09:32:03 -0700 (PDT) In-Reply-To: <53F4C6D4.2000505@pi.nu> References: <53F4C6D4.2000505@pi.nu> Date: Wed, 20 Aug 2014 12:32:03 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf30434c58e8e84d0501122453 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/TGbpSerRcvaoikKctlL7ax0opL4 Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 20 Aug 2014 16:32:07 -0000 --20cf30434c58e8e84d0501122453 Content-Type: text/plain; charset=UTF-8 Hi Loa, On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson wrote: > Alia > > A few quick questions on this. In the message that the RTG ADs sent > to the wg chairs and directorate when the discussion on re-org started > you said > > "First, we intend to use our Routing Directorate more proactively by > introducing a Working Group Draft Quality Assurance (WG Draft QA) > process where the same selected routing directorate member will review > a draft during WG draft adoption and during WG last call. The process > will be documented on the Routing Area wiki. This should allow > directorate reviews to report technical issues that can actually get > fixed early in the process (equiv of bug reports) as opposed to just > noting the concerns in the drafts (equiv of release notes)." > > It seems that there are a changes from what was said at that time > and what is said now. > > "... where the same selected routing directorate member will review > a draft during WG draft adoption and during WG last call" > > while we now say > > "...for all drafts that are being considered for WG adoption." > > What motivated this change? > This isn't intended to be a change. A draft that is going to have a WG call for adoption issued should get a QA reviewer so that the review can happen ideally before the WG call for adoption ends. Basically, I see the process as: 1. Individual draft submitted and discussed. 2. WG Chairs decide to issue a call for adoption. 2.1 WG Chairs get a QA reviewer with review 2.2 WG Chairs issue a call for adoption (can be before QA reviewer is assigned if that is taking too much time) 2.3 Ideally, QA reviewer contributes the review to the WG mailing list 2.4 WG Chairs decide if there is active consensus to adopt the draft. 3. Draft is improved based upon reviews and comments. Where MPLS has additional process between considering a draft and doing a WG call for adoption that is treating those early reviews as gating, I can understand that you may see a difference between the two states. Second, some wg's have review teams that does something similar to > the WG Draft QA process just prior to that the the call for working > group adoption is started. > Right - that is intended really for review inside the WG and before the call for WG adoption is started. The WG Draft QA is intended more for cross-WG review and expected to take place in parallel with the call for adoption. > Do we do the WG Draft QA in addition to, instead of these reviews, > or can we continue doing the review team reviews instead of WG Draft QA? > I believe that they are addressing slightly different problems. For MPLS, I think that some of the drafts could benefit from early review that considers cross-WG concerns as well as usefulness of the draft. That said, the process does allow for WG chairs to decide not to request a QA reviewer or to request one who isn't part of the routing directorate. We just ask that it's documented so that we can tell the difference between a decision not to request and a failure to remember to do so. I'd prefer to see the QA reviews done so we can determine how much value is being added rather than simply say it's not needed for a particular WG. Regards, Alia /Loa > > > > > On 2014-08-20 16:45, Alia Atlas wrote: > >> Hi to all the Routing Area WG Chairs and Secretaries, >> >> As Adrian and I discussed prior to IETF 90 and in the Routing Area >> meeting at IETF 90, >> we would like to start using the new Draft Quality Assurance process ( >> http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all >> drafts that are being >> considered for WG adoption. Drafts that are already WG drafts do not >> need to go through this process - but chairs can ask if it seems >> desirable. >> >> As with many processes in the IETF, this process is intended to be used >> for the spirit of the goal, subject to common-sense and technical >> perspective. In particular, none of this process is intended to gate or >> otherwise impede the normal progression of documents through IETF >> working groups: rather, it is intended to provide additional input, >> review, and comments that the working groups can use to help improve the >> quality of their documents, and to help chairs determine quality and >> consensus for documents. We do not expect IETF process to wait for >> reviews to happen. >> >> As described on the wiki page, the detailed process is: >> >> 1. The WG Chair or Secretary emails the Routing Directorate >> >> Coordinators ( Deborah Brungard > >) and Jonathan Hardwick > metaswitch.com >). The subject should be WG >> Draft QA Requested: > >. >> >> 2. The WG Chair or Secretary marks a draft in the datatracker as >> >> "Candidate for Adoption" and specifies the date on which WG Draft QA >> was requested. >> >> 3. The Routing Directorate Coordinators and WG Chairs agree and find a >> >> QA Reviewer. The review can be done during the WG Call for Adoption. >> The WG Chair or Secretary adds a comment in the draft's datatracker >> history page indicating whom is the QA Reviewer. >> >> Please start doing this now. >> >> After IETF-91, we can discuss how this is going and its usefulness. >> >> Thanks, >> Alia >> > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --20cf30434c58e8e84d0501122453 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Loa,

On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson &l= t;loa@pi.nu> w= rote:
Alia

A few quick questions on this. In the message that the RTG ADs sent
to the wg chairs and directorate when the discussion on re-org started
you said

"First, we intend to use our Routing Directorate more proactively by =C2=A0introducing a Working Group Draft Quality Assurance (WG Draft QA)
=C2=A0process where the same selected routing directorate member will revie= w
=C2=A0a draft during WG draft adoption and during WG last call.=C2=A0 The p= rocess
=C2=A0will be documented on the Routing Area wiki.=C2=A0 This should allow<= br> =C2=A0directorate reviews to report technical issues that can actually get<= br> =C2=A0fixed early in the process (equiv of bug reports) as opposed to just<= br> =C2=A0noting the concerns in the drafts (equiv of release notes)."

It seems that there are a changes from what was said at that time
and what is said now.

"... where the same selected routing directorate member will review =C2=A0a draft during WG draft adoption and during WG last call"

while we now say

"...for all drafts that are being considered for WG adoption."
What motivated this change?

This isn= 9;t intended to be a change. =C2=A0A draft that is going to have a WG call<= /div>
for adoption issued should get a QA reviewer so that the review c= an happen=C2=A0
ideally before the WG call for adoption ends.

Basically, I see =C2=A0the process as:

1. Individ= ual draft submitted and discussed.
2. WG Chairs decide to issue a= call for adoption.
2.1 WG Chairs get a QA reviewer with review
2.2 WG Chairs is= sue a call for adoption (can be before QA reviewer is assigned if
that is taking too much time)
2.3 Ideally, QA reviewer contribut= es the review to the WG mailing list
2.4 WG Chairs decide if there is active consensus to adopt the draft.<= /div>
3. Draft is improved based upon reviews and comments.
= =C2=A0
Where MPLS has additional process between considering a dr= aft and doing a WG=C2=A0
call for adoption that is treating those early reviews as gating, I ca= n understand
that you may see a difference between the two states= .

Second, some wg's have review teams that does something similar to
the WG Draft QA process just prior to that the the call for working
group adoption is started.

Right - that= is intended really for review inside the WG and before the call for
<= div>WG adoption is started.

The WG Draft QA is int= ended more for cross-WG review and expected to
take place in parallel with the call for adoption.
=C2=A0
Do we do the=C2=A0 WG Draft QA in additio= n to, instead of these reviews,
or can we continue doing the review team reviews instead of WG Draft QA?

I believe that they are addressing slight= ly different problems. =C2=A0For MPLS, I think
that some of the d= rafts could benefit from early review that considers cross-WG=C2=A0
concerns as well as usefulness of the draft.

= That said, the process does allow for WG chairs to decide not to request a = QA=C2=A0
reviewer or to request one who isn't part of the rou= ting directorate. =C2=A0We just ask=C2=A0
that it's documented so that we can tell the difference between a = decision not to=C2=A0
request and a failure to remember to do so.=

I'd prefer to see the QA reviews done so we c= an determine how much value is
being added rather than simply say it's not needed for a particula= r WG.=C2=A0

Regards,
Alia

=

/Loa




On 2014-08-20 16:45, Alia Atlas wrote:
Hi to all the Routing=C2=A0 Area WG Chairs and Secretaries,

As Adrian and I discussed prior to IETF 90 and in the Routing Area
meeting at IETF 90,
we would like to start using the new Draft Quality Assurance process (
http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDoc= Qa ) for all
drafts that are being
considered for WG adoption.=C2=A0 =C2=A0Drafts that are already WG drafts d= o not
need to go through this process - but chairs can ask if it seems desirable.=

As with many processes in the IETF, this process is intended to be used
for the spirit of the goal, subject to common-sense and technical
perspective. In particular, none of this process is intended to gate or
otherwise impede the normal progression of documents through IETF
working groups: rather, it is intended to provide additional input,
review, and comments that the working groups can use to help improve the quality of their documents, and to help chairs determine quality and
consensus for documents. We do not expect IETF process to wait for
reviews to happen.

As described on the wiki page, the detailed process is:

=C2=A01. The WG Chair or Secretary emails the Routing Directorate

=C2=A0 =C2=A0 Coordinators ( Deborah Brungard <db3546 at att.com
=C2=A0 =C2=A0 <http://att.= com/>>) and Jonathan Hardwick <jonathan.hardwick at
=C2=A0 =C2=A0 metaswitc= h.com <http://m= etaswitch.com/>>). The subject should be WG
=C2=A0 =C2=A0 Draft QA Requested: <draft-name
=C2=A0 =C2=A0 <http://tools.ietf.org/html/draft-name>>.

=C2=A02. The WG Chair or Secretary marks a draft in the datatracker as

=C2=A0 =C2=A0 "Candidate for Adoption" and specifies the date on = which WG Draft QA
=C2=A0 =C2=A0 was requested.

=C2=A03. The Routing Directorate Coordinators and WG Chairs agree and find = a

=C2=A0 =C2=A0 QA Reviewer. The review can be done during the WG Call for Ad= option.
=C2=A0 =C2=A0 The WG Chair or Secretary adds a comment in the draft's d= atatracker
=C2=A0 =C2=A0 history page indicating whom is the QA Reviewer.

Please start doing this now.

After IETF-91, we can discuss how this is going and its usefulness.

Thanks,
Alia

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--20cf30434c58e8e84d0501122453-- From nobody Wed Aug 20 10:42: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 95EE01A0687; Wed, 20 Aug 2014 10:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668] 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 fIu7lDrh5Rma; Wed, 20 Aug 2014 10:42:23 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACFD1A069D; Wed, 20 Aug 2014 10:42:23 -0700 (PDT) Received: from [2.64.100.82] (2.64.100.82.mobile.tre.se [2.64.100.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 94C3A1801586; Wed, 20 Aug 2014 19:42:21 +0200 (CEST) References: <53F4C6D4.2000505@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-F3992A8F-F007-472D-AD61-B838358713C6 Content-Transfer-Encoding: 7bit Message-Id: <9727E961-8EAD-429C-B3E6-243414F03543@pi.nu> X-Mailer: iPhone Mail (11D257) From: Loa Andersson Date: Wed, 20 Aug 2014 19:42:17 +0200 To: Alia Atlas Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/bPOK6VsMql15BitMYUAHjxlga7k Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 20 Aug 2014 17:42:27 -0000 --Apple-Mail-F3992A8F-F007-472D-AD61-B838358713C6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Alia, I think you missed the point. Initially we had two QA reviews intended. One a= t wg adoption poll and a second at wglc. The directive going out now only ta= lks about a RTG dir review at adoption poll intended or not it is a change. W= hy did we change.=20 /Loa Sent from my iPhone > On 20 aug 2014, at 18:32, Alia Atlas wrote: >=20 > Hi Loa, >=20 >> On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson wrote: >> Alia >>=20 >> A few quick questions on this. In the message that the RTG ADs sent >> to the wg chairs and directorate when the discussion on re-org started >> you said >>=20 >> "First, we intend to use our Routing Directorate more proactively by >> introducing a Working Group Draft Quality Assurance (WG Draft QA) >> process where the same selected routing directorate member will review >> a draft during WG draft adoption and during WG last call. The process >> will be documented on the Routing Area wiki. This should allow >> directorate reviews to report technical issues that can actually get >> fixed early in the process (equiv of bug reports) as opposed to just >> noting the concerns in the drafts (equiv of release notes)." >>=20 >> It seems that there are a changes from what was said at that time >> and what is said now. >>=20 >> "... where the same selected routing directorate member will review >> a draft during WG draft adoption and during WG last call" >>=20 >> while we now say >>=20 >> "...for all drafts that are being considered for WG adoption." >>=20 >> What motivated this change? >=20 > This isn't intended to be a change. A draft that is going to have a WG ca= ll > for adoption issued should get a QA reviewer so that the review can happen= =20 > ideally before the WG call for adoption ends. >=20 > Basically, I see the process as: >=20 > 1. Individual draft submitted and discussed. > 2. WG Chairs decide to issue a call for adoption. > 2.1 WG Chairs get a QA reviewer with review > 2.2 WG Chairs issue a call for adoption (can be before QA reviewer is assi= gned if > that is taking too much time) > 2.3 Ideally, QA reviewer contributes the review to the WG mailing list > 2.4 WG Chairs decide if there is active consensus to adopt the draft. > 3. Draft is improved based upon reviews and comments. > =20 > Where MPLS has additional process between considering a draft and doing a W= G=20 > call for adoption that is treating those early reviews as gating, I can un= derstand > that you may see a difference between the two states. >=20 >> Second, some wg's have review teams that does something similar to >> the WG Draft QA process just prior to that the the call for working >> group adoption is started. >=20 > Right - that is intended really for review inside the WG and before the ca= ll for > WG adoption is started. >=20 > The WG Draft QA is intended more for cross-WG review and expected to > take place in parallel with the call for adoption. > =20 >> Do we do the WG Draft QA in addition to, instead of these reviews, >> or can we continue doing the review team reviews instead of WG Draft QA? >=20 > I believe that they are addressing slightly different problems. For MPLS,= I think > that some of the drafts could benefit from early review that considers cro= ss-WG=20 > concerns as well as usefulness of the draft. >=20 > That said, the process does allow for WG chairs to decide not to request a= QA=20 > reviewer or to request one who isn't part of the routing directorate. We j= ust ask=20 > that it's documented so that we can tell the difference between a decision= not to=20 > request and a failure to remember to do so. >=20 > I'd prefer to see the QA reviews done so we can determine how much value i= s > being added rather than simply say it's not needed for a particular WG.=20= >=20 > Regards, > Alia >=20 >=20 >> /Loa >>=20 >>=20 >>=20 >>=20 >>> On 2014-08-20 16:45, Alia Atlas wrote: >>> Hi to all the Routing Area WG Chairs and Secretaries, >>>=20 >>> As Adrian and I discussed prior to IETF 90 and in the Routing Area >>> meeting at IETF 90, >>> we would like to start using the new Draft Quality Assurance process ( >>> http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all >>> drafts that are being >>> considered for WG adoption. Drafts that are already WG drafts do not >>> need to go through this process - but chairs can ask if it seems desirab= le. >>>=20 >>> As with many processes in the IETF, this process is intended to be used >>> for the spirit of the goal, subject to common-sense and technical >>> perspective. In particular, none of this process is intended to gate or >>> otherwise impede the normal progression of documents through IETF >>> working groups: rather, it is intended to provide additional input, >>> review, and comments that the working groups can use to help improve the= >>> quality of their documents, and to help chairs determine quality and >>> consensus for documents. We do not expect IETF process to wait for >>> reviews to happen. >>>=20 >>> As described on the wiki page, the detailed process is: >>>=20 >>> 1. The WG Chair or Secretary emails the Routing Directorate >>>=20 >>> Coordinators ( Deborah Brungard >> >) and Jonathan Hardwick >> metaswitch.com >). The subject should be WG >>> Draft QA Requested: >> >. >>>=20 >>> 2. The WG Chair or Secretary marks a draft in the datatracker as >>>=20 >>> "Candidate for Adoption" and specifies the date on which WG Draft QA= >>> was requested. >>>=20 >>> 3. The Routing Directorate Coordinators and WG Chairs agree and find a >>>=20 >>> QA Reviewer. The review can be done during the WG Call for Adoption.= >>> The WG Chair or Secretary adds a comment in the draft's datatracker >>> history page indicating whom is the QA Reviewer. >>>=20 >>> Please start doing this now. >>>=20 >>> After IETF-91, we can discuss how this is going and its usefulness. >>>=20 >>> Thanks, >>> Alia >>=20 >> --=20 >>=20 >>=20 >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 --Apple-Mail-F3992A8F-F007-472D-AD61-B838358713C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Alia,

I think you missed the point. Initially we had two QA reviews intended. One at wg adoption poll and a second at wglc. The directive going out now only talks about a RTG dir review at adoption poll intended or not it is a change. Why did we change. 

/Loa

Sent from my iPhone

On 20 aug 2014, at 18:32, Alia Atlas <akatlas@gmail.com> wrote:

Hi Loa,

On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson <loa@pi.nu> wrote:
Alia

A few quick questions on this. In the message that the RTG ADs sent
to the wg chairs and directorate when the discussion on re-org started
you said

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

It seems that there are a changes from what was said at that time
and what is said now.

"... where the same selected routing directorate member will review
 a draft during WG draft adoption and during WG last call"

while we now say

"...for all drafts that are being considered for WG adoption."

What motivated this change?

This isn't intended to be a change.  A draft that is going to have a WG call
for adoption issued should get a QA reviewer so that the review can happen 
ideally before the WG call for adoption ends.

Basically, I see  the process as:

1. Individual draft submitted and discussed.
2. WG Chairs decide to issue a call for adoption.
2.1 WG Chairs get a QA reviewer with review
2.2 WG Chairs issue a call for adoption (can be before QA reviewer is assigned if
that is taking too much time)
2.3 Ideally, QA reviewer contributes the review to the WG mailing list
2.4 WG Chairs decide if there is active consensus to adopt the draft.
3. Draft is improved based upon reviews and comments.
 
Where MPLS has additional process between considering a draft and doing a WG 
call for adoption that is treating those early reviews as gating, I can understand
that you may see a difference between the two states.

Second, some wg's have review teams that does something similar to
the WG Draft QA process just prior to that the the call for working
group adoption is started.

Right - that is intended really for review inside the WG and before the call for
WG adoption is started.

The WG Draft QA is intended more for cross-WG review and expected to
take place in parallel with the call for adoption.
 
Do we do the  WG Draft QA in addition to, instead of these reviews,
or can we continue doing the review team reviews instead of WG Draft QA?

I believe that they are addressing slightly different problems.  For MPLS, I think
that some of the drafts could benefit from early review that considers cross-WG 
concerns as well as usefulness of the draft.

That said, the process does allow for WG chairs to decide not to request a QA 
reviewer or to request one who isn't part of the routing directorate.  We just ask 
that it's documented so that we can tell the difference between a decision not to 
request and a failure to remember to do so.

I'd prefer to see the QA reviews done so we can determine how much value is
being added rather than simply say it's not needed for a particular WG. 

Regards,
Alia


/Loa




On 2014-08-20 16:45, Alia Atlas wrote:
Hi to all the Routing  Area WG Chairs and Secretaries,

As Adrian and I discussed prior to IETF 90 and in the Routing Area
meeting at IETF 90,
we would like to start using the new Draft Quality Assurance process (
http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all
drafts that are being
considered for WG adoption.   Drafts that are already WG drafts do not
need to go through this process - but chairs can ask if it seems desirable.

As with many processes in the IETF, this process is intended to be used
for the spirit of the goal, subject to common-sense and technical
perspective. In particular, none of this process is intended to gate or
otherwise impede the normal progression of documents through IETF
working groups: rather, it is intended to provide additional input,
review, and comments that the working groups can use to help improve the
quality of their documents, and to help chairs determine quality and
consensus for documents. We do not expect IETF process to wait for
reviews to happen.

As described on the wiki page, the detailed process is:

 1. The WG Chair or Secretary emails the Routing Directorate

    Coordinators ( Deborah Brungard <db3546 at att.com
    <http://att.com/>>) and Jonathan Hardwick <jonathan.hardwick at
    metaswitch.com <http://metaswitch.com/>>). The subject should be WG
    Draft QA Requested: <draft-name
    <http://tools.ietf.org/html/draft-name>>.

 2. The WG Chair or Secretary marks a draft in the datatracker as

    "Candidate for Adoption" and specifies the date on which WG Draft QA
    was requested.

 3. The Routing Directorate Coordinators and WG Chairs agree and find a

    QA Reviewer. The review can be done during the WG Call for Adoption.
    The WG Chair or Secretary adds a comment in the draft's datatracker
    history page indicating whom is the QA Reviewer.

Please start doing this now.

After IETF-91, we can discuss how this is going and its usefulness.

Thanks,
Alia

--


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64

--Apple-Mail-F3992A8F-F007-472D-AD61-B838358713C6-- From nobody Wed Aug 20 11:37: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 7B02A1A04E9; Wed, 20 Aug 2014 11:37:16 -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 JUDitbP0fUVg; Wed, 20 Aug 2014 11:37:13 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118F51A04A1; Wed, 20 Aug 2014 11:37:13 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id q200so6922214ykb.12 for ; Wed, 20 Aug 2014 11:37: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=PsTTFMy55v/yGc/5EeEeVpbZj7M180zdNK7p5oKesS0=; b=Ot34QMcBwgPXdQuXFwrlMHnjK6w1B3P0iM1Z7QtoUV1RR+Yh+3inDypVpK57I/G5Wa /OwYkTXsrUpnl4EHw+P3D3SBhEi9Lg2V54BzPw8WBKo2nNn0KKUEsDSpugeQt6FCtozd fxZu3BZ7J9hN0R+DAHq83wxCmdQwfNGkMr162A3wV793zUaEEPllg3nqZwP3r7oDEtK6 oZPJoXXJNs6mGdRaNHH2K2yPq53dtEfRMv5Kx4oEnneSySvYAQGFGwJatNrZ8IfSxvBC VQPjxBud5lCrCcP2rleKws7PBCyNONYfs+PH4rjaj8umwQRYIvLWopQYwWtWwJv2tgkT Rp+Q== MIME-Version: 1.0 X-Received: by 10.236.85.10 with SMTP id t10mr70973446yhe.86.1408559832230; Wed, 20 Aug 2014 11:37:12 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Wed, 20 Aug 2014 11:37:12 -0700 (PDT) In-Reply-To: <9727E961-8EAD-429C-B3E6-243414F03543@pi.nu> References: <53F4C6D4.2000505@pi.nu> <9727E961-8EAD-429C-B3E6-243414F03543@pi.nu> Date: Wed, 20 Aug 2014 14:37:12 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=20cf3010e6ad71f1a4050113e45b Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ZZaUFj0EroOcA6v6ZpkKUA2q40U Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 20 Aug 2014 18:37:16 -0000 --20cf3010e6ad71f1a4050113e45b Content-Type: text/plain; charset=UTF-8 Loa, On Wed, Aug 20, 2014 at 1:42 PM, Loa Andersson wrote: > Alia, > > I think you missed the point. Initially we had two QA reviews intended. > One at wg adoption poll and a second at wglc. The directive going out now > only talks about a RTG dir review at adoption poll intended or not it is a > change. Why did we change. > Oh - there isn't a change in terms of the QA reviews intended. At the WG adoption poll is when the QA reviewer is assigned - and this is talking about that process. Once the QA reviewer is assigned, he or she is expected to do both of the reviews. Please do read the wiki and make/suggest changes for clarification if necessary. Regards, Alia > /Loa > > Sent from my iPhone > > On 20 aug 2014, at 18:32, Alia Atlas wrote: > > Hi Loa, > > On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson wrote: > >> Alia >> >> A few quick questions on this. In the message that the RTG ADs sent >> to the wg chairs and directorate when the discussion on re-org started >> you said >> >> "First, we intend to use our Routing Directorate more proactively by >> introducing a Working Group Draft Quality Assurance (WG Draft QA) >> process where the same selected routing directorate member will review >> a draft during WG draft adoption and during WG last call. The process >> will be documented on the Routing Area wiki. This should allow >> directorate reviews to report technical issues that can actually get >> fixed early in the process (equiv of bug reports) as opposed to just >> noting the concerns in the drafts (equiv of release notes)." >> >> It seems that there are a changes from what was said at that time >> and what is said now. >> >> "... where the same selected routing directorate member will review >> a draft during WG draft adoption and during WG last call" >> >> while we now say >> >> "...for all drafts that are being considered for WG adoption." >> >> What motivated this change? >> > > This isn't intended to be a change. A draft that is going to have a WG > call > for adoption issued should get a QA reviewer so that the review can happen > ideally before the WG call for adoption ends. > > Basically, I see the process as: > > 1. Individual draft submitted and discussed. > 2. WG Chairs decide to issue a call for adoption. > 2.1 WG Chairs get a QA reviewer with review > 2.2 WG Chairs issue a call for adoption (can be before QA reviewer is > assigned if > that is taking too much time) > 2.3 Ideally, QA reviewer contributes the review to the WG mailing list > 2.4 WG Chairs decide if there is active consensus to adopt the draft. > 3. Draft is improved based upon reviews and comments. > > Where MPLS has additional process between considering a draft and doing a > WG > call for adoption that is treating those early reviews as gating, I can > understand > that you may see a difference between the two states. > > Second, some wg's have review teams that does something similar to >> the WG Draft QA process just prior to that the the call for working >> group adoption is started. >> > > Right - that is intended really for review inside the WG and before the > call for > WG adoption is started. > > The WG Draft QA is intended more for cross-WG review and expected to > take place in parallel with the call for adoption. > > >> Do we do the WG Draft QA in addition to, instead of these reviews, >> or can we continue doing the review team reviews instead of WG Draft QA? >> > > I believe that they are addressing slightly different problems. For MPLS, > I think > that some of the drafts could benefit from early review that considers > cross-WG > concerns as well as usefulness of the draft. > > That said, the process does allow for WG chairs to decide not to request a > QA > reviewer or to request one who isn't part of the routing directorate. We > just ask > that it's documented so that we can tell the difference between a decision > not to > request and a failure to remember to do so. > > I'd prefer to see the QA reviews done so we can determine how much value is > being added rather than simply say it's not needed for a particular WG. > > Regards, > Alia > > > /Loa >> >> >> >> >> On 2014-08-20 16:45, Alia Atlas wrote: >> >>> Hi to all the Routing Area WG Chairs and Secretaries, >>> >>> As Adrian and I discussed prior to IETF 90 and in the Routing Area >>> meeting at IETF 90, >>> we would like to start using the new Draft Quality Assurance process ( >>> http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all >>> drafts that are being >>> considered for WG adoption. Drafts that are already WG drafts do not >>> need to go through this process - but chairs can ask if it seems >>> desirable. >>> >>> As with many processes in the IETF, this process is intended to be used >>> for the spirit of the goal, subject to common-sense and technical >>> perspective. In particular, none of this process is intended to gate or >>> otherwise impede the normal progression of documents through IETF >>> working groups: rather, it is intended to provide additional input, >>> review, and comments that the working groups can use to help improve the >>> quality of their documents, and to help chairs determine quality and >>> consensus for documents. We do not expect IETF process to wait for >>> reviews to happen. >>> >>> As described on the wiki page, the detailed process is: >>> >>> 1. The WG Chair or Secretary emails the Routing Directorate >>> >>> Coordinators ( Deborah Brungard >> >) and Jonathan Hardwick >> metaswitch.com >). The subject should be WG >>> Draft QA Requested: >> >. >>> >>> 2. The WG Chair or Secretary marks a draft in the datatracker as >>> >>> "Candidate for Adoption" and specifies the date on which WG Draft QA >>> was requested. >>> >>> 3. The Routing Directorate Coordinators and WG Chairs agree and find a >>> >>> QA Reviewer. The review can be done during the WG Call for Adoption. >>> The WG Chair or Secretary adds a comment in the draft's datatracker >>> history page indicating whom is the QA Reviewer. >>> >>> Please start doing this now. >>> >>> After IETF-91, we can discuss how this is going and its usefulness. >>> >>> Thanks, >>> Alia >>> >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> > > --20cf3010e6ad71f1a4050113e45b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

On Wed, Aug 20, 2014 at 1:42 PM, Loa Andersson &l= t;loa@pi.nu> w= rote:
Alia,

<= /div>
I think you missed the point. Initially we had two QA reviews int= ended. One at wg adoption poll and a second at wglc. The directive going ou= t now only talks about a RTG dir review at adoption poll intended or not it= is a change. Why did we change.=C2=A0

Oh - there isn't a change in ter= ms of the QA reviews intended. =C2=A0At the WG adoption poll is when the QA= reviewer is assigned - and this is talking about that process. =C2=A0Once = the QA reviewer is assigned, he or she is expected to do both of the review= s. =C2=A0 Please do read the wiki and make/suggest changes for clarificatio= n if necessary.

Regards,
Alia
=C2=A0
/Loa

Sent from my iPhon= e

On 20 aug 2014, at 18:32, Alia Atlas <akatlas@gmail.com&= gt; wrote:

Hi = Loa,

On Wed, Aug 20, 2014 at 12:03 PM, Loa Anders= son <lo= a@pi.nu> wrote:
Alia

A few quick questions on this. In the message that the RTG ADs sent
to the wg chairs and directorate when the discussion on re-org started
you said

"First, we intend to use our Routing Directorate more proactively by =C2=A0introducing a Working Group Draft Quality Assurance (WG Draft QA)
=C2=A0process where the same selected routing directorate member will revie= w
=C2=A0a draft during WG draft adoption and during WG last call.=C2=A0 The p= rocess
=C2=A0will be documented on the Routing Area wiki.=C2=A0 This should allow<= br> =C2=A0directorate reviews to report technical issues that can actually get<= br> =C2=A0fixed early in the process (equiv of bug reports) as opposed to just<= br> =C2=A0noting the concerns in the drafts (equiv of release notes)."

It seems that there are a changes from what was said at that time
and what is said now.

"... where the same selected routing directorate member will review =C2=A0a draft during WG draft adoption and during WG last call"

while we now say

"...for all drafts that are being considered for WG adoption."
What motivated this change?

This isn= 9;t intended to be a change. =C2=A0A draft that is going to have a WG call<= /div>
for adoption issued should get a QA reviewer so that the review c= an happen=C2=A0
ideally before the WG call for adoption ends.

Basically, I see =C2=A0the process as:

1. Individ= ual draft submitted and discussed.
2. WG Chairs decide to issue a= call for adoption.
2.1 WG Chairs get a QA reviewer with review
2.2 WG Chairs is= sue a call for adoption (can be before QA reviewer is assigned if
that is taking too much time)
2.3 Ideally, QA reviewer contribut= es the review to the WG mailing list
2.4 WG Chairs decide if there is active consensus to adopt the draft.<= /div>
3. Draft is improved based upon reviews and comments.
= =C2=A0
Where MPLS has additional process between considering a dr= aft and doing a WG=C2=A0
call for adoption that is treating those early reviews as gating, I ca= n understand
that you may see a difference between the two states= .

Second, some wg's have review teams that does something similar to
the WG Draft QA process just prior to that the the call for working
group adoption is started.

Right - that= is intended really for review inside the WG and before the call for
<= div>WG adoption is started.

The WG Draft QA is int= ended more for cross-WG review and expected to
take place in parallel with the call for adoption.
=C2=A0
Do we do the=C2=A0 WG Draft QA in additio= n to, instead of these reviews,
or can we continue doing the review team reviews instead of WG Draft QA?

I believe that they are addressing slight= ly different problems. =C2=A0For MPLS, I think
that some of the d= rafts could benefit from early review that considers cross-WG=C2=A0
concerns as well as usefulness of the draft.

= That said, the process does allow for WG chairs to decide not to request a = QA=C2=A0
reviewer or to request one who isn't part of the rou= ting directorate. =C2=A0We just ask=C2=A0
that it's documented so that we can tell the difference between a = decision not to=C2=A0
request and a failure to remember to do so.=

I'd prefer to see the QA reviews done so we c= an determine how much value is
being added rather than simply say it's not needed for a particula= r WG.=C2=A0

Regards,
Alia

=

/Loa




On 2014-08-20 16:45, Alia Atlas wrote:
Hi to all the Routing=C2=A0 Area WG Chairs and Secretaries,

As Adrian and I discussed prior to IETF 90 and in the Routing Area
meeting at IETF 90,
we would like to start using the new Draft Quality Assurance process (
http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDoc= Qa ) for all
drafts that are being
considered for WG adoption.=C2=A0 =C2=A0Drafts that are already WG drafts d= o not
need to go through this process - but chairs can ask if it seems desirable.=

As with many processes in the IETF, this process is intended to be used
for the spirit of the goal, subject to common-sense and technical
perspective. In particular, none of this process is intended to gate or
otherwise impede the normal progression of documents through IETF
working groups: rather, it is intended to provide additional input,
review, and comments that the working groups can use to help improve the quality of their documents, and to help chairs determine quality and
consensus for documents. We do not expect IETF process to wait for
reviews to happen.

As described on the wiki page, the detailed process is:

=C2=A01. The WG Chair or Secretary emails the Routing Directorate

=C2=A0 =C2=A0 Coordinators ( Deborah Brungard <db3546 at att.com
=C2=A0 =C2=A0 <http://att.= com/>>) and Jonathan Hardwick <jonathan.hardwick at
=C2=A0 =C2=A0 metaswitc= h.com <http://m= etaswitch.com/>>). The subject should be WG
=C2=A0 =C2=A0 Draft QA Requested: <draft-name
=C2=A0 =C2=A0 <http://tools.ietf.org/html/draft-name>>.

=C2=A02. The WG Chair or Secretary marks a draft in the datatracker as
=
=C2=A0 =C2=A0 "Candidate for Adoption" and specifies the date on = which WG Draft QA
=C2=A0 =C2=A0 was requested.

=C2=A03. The Routing Directorate Coordinators and WG Chairs agree and find = a

=C2=A0 =C2=A0 QA Reviewer. The review can be done during the WG Call for Ad= option.
=C2=A0 =C2=A0 The WG Chair or Secretary adds a comment in the draft's d= atatracker
=C2=A0 =C2=A0 history page indicating whom is the QA Reviewer.

Please start doing this now.

After IETF-91, we can discuss how this is going and its usefulness.

Thanks,
Alia

--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64


--20cf3010e6ad71f1a4050113e45b-- From nobody Wed Aug 20 13:10: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 4394E1A0676; Wed, 20 Aug 2014 13:10:07 -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 gxHxEICF0qKk; Wed, 20 Aug 2014 13:10:04 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663C81A0657; Wed, 20 Aug 2014 13:10:03 -0700 (PDT) Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB635.namprd05.prod.outlook.com (10.141.199.22) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Wed, 20 Aug 2014 20:10:00 +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.1010.016; Wed, 20 Aug 2014 20:10:00 +0000 From: Ross Callon To: Alia Atlas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Please start using the Document QA process now Thread-Index: AQHPvIVsruFu56If70+Y3cRd7wR55pvZ6vgA Date: Wed, 20 Aug 2014 20:09:59 +0000 Message-ID: <521b84ffaa85498c9755c42076582780@CO2PR05MB636.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03094A4065 x-forefront-antispam-report: SFV:NSPM; SFS:(199003)(164054003)(189002)(377454003)(19300405004)(76576001)(81342001)(15975445006)(105586002)(108616004)(2656002)(31966008)(99286002)(46102001)(95666004)(81542001)(106356001)(87936001)(85306004)(107046002)(86362001)(83322001)(74316001)(16236675004)(50986999)(74502001)(107886001)(15202345003)(80022001)(76176999)(54356999)(64706001)(18717965001)(79102001)(21056001)(92566001)(19625215002)(85852003)(101416001)(15395725005)(4396001)(33646002)(76482001)(19580405001)(106116001)(74662001)(99396002)(2201001)(20776003)(83072002)(19617315012)(66066001)(19580395003)(19609705001)(77982001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB635; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_521b84ffaa85498c9755c42076582780CO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/H0p-9ibtWqaxXy75ExYupubzTes Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 20 Aug 2014 20:10:07 -0000 --_000_521b84ffaa85498c9755c42076582780CO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB3b25kZXJpbmcgaG93IHRoaXMgZml0cyB3aXRoIFdHIHJldmlldyB0ZWFtcywgd2hlcmUg dGhlcmUgYXJlIHN1Y2guDQoNCkFzIGFuIGV4YW1wbGUsIHRoZSBNUExTIFdHIGhhcyBpdHMgb3du IHJldmlldyB0ZWFtLiBXZSBqdXN0IGZpbmlzaGVkIHRoZSByZXZpZXcgdGVhbSByZXZpZXcgb2Yg ZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZSAod2l0aCByZXZpZXdz IGZyb20gYWxsIDMgcmV2aWV3ZXJzIHdobyB3ZXJlIGFza2VkKS4gVGhlIGRvY3VtZW50IHdhcyB1 cGRhdGVkIGFjY29yZGluZ2x5Lg0KDQpEbyB3ZSB3YW50IGEgZG9jdW1lbnQgdG8gZ28gdGhyb3Vn aCBXRyBzcGVjaWZpYyByZXZpZXcsIHRoZW4gcm91dGluZyBhcmVhIFFBIHRlYW0gcmV2aWV3LCB0 aGVuIGNhbGwgZm9yIGFkb3B0aW9uLCBhbmQgbGF0ZXIgZ28gdGhyb3VnaCBsYXN0IGNhbGwsIFdH IGNoYWlyIHJldmlldywgUUEgdGVhbSByZXZpZXcgKGFnYWluKSwgQUQgcmV2aWV3LCBJRVRGIGxh c3QgY2FsbCwgYW5kIElFU0cgcmV2aWV3Pw0KDQpBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byBy ZXBsYWNlIG9uZSBvZiB0aGUgV0cgcmV2aWV3IHRlYW0gcmV2aWV3ZXJzIHdpdGggb25lIG9yIHR3 byByb3V0aW5nIGFyZWEgUUEgcmV2aWV3ZXJzLCBhbmQgZG8gdGhlc2UgdHdvIHJldmlld3MgYXQg dGhlIHNhbWUgdGltZS4gQXQgbGVhc3QgaW4gdGhlIE1QTFMgV0cgd2UgdHlwaWNhbGx5IGRvIHRo ZSBNUExTIHJldmlldyB0ZWFtIHJldmlld3MgYmVmb3JlIHRoZSBjYWxsIGZvciBXRyBhZG9wdGlv bi4NCg0KVGhhbmtzLCBSb3NzDQoNCkZyb206IHJ0Zy1kaXIgW21haWx0bzpydGctZGlyLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGlhIEF0bGFzDQpTZW50OiBXZWRuZXNkYXksIEF1 Z3VzdCAyMCwgMjAxNCAxMDo0NiBBTQ0KVG86IHJ0Zy1jaGFpcnNAaWV0Zi5vcmc7IHJ0Zy1kaXJA aWV0Zi5vcmcNClN1YmplY3Q6IFtSVEctRElSXSBQbGVhc2Ugc3RhcnQgdXNpbmcgdGhlIERvY3Vt ZW50IFFBIHByb2Nlc3Mgbm93DQoNCkhpIHRvIGFsbCB0aGUgUm91dGluZyAgQXJlYSBXRyBDaGFp cnMgYW5kIFNlY3JldGFyaWVzLA0KDQpBcyBBZHJpYW4gYW5kIEkgZGlzY3Vzc2VkIHByaW9yIHRv IElFVEYgOTAgYW5kIGluIHRoZSBSb3V0aW5nIEFyZWEgbWVldGluZyBhdCBJRVRGIDkwLA0Kd2Ug d291bGQgbGlrZSB0byBzdGFydCB1c2luZyB0aGUgbmV3IERyYWZ0IFF1YWxpdHkgQXNzdXJhbmNl IHByb2Nlc3MgKCBodHRwOi8vd2lraS50b29scy5pZXRmLm9yZy9hcmVhL3J0Zy90cmFjL3dpa2kv UnRnRGlyRG9jUWEgKSBmb3IgYWxsIGRyYWZ0cyB0aGF0IGFyZSBiZWluZw0KY29uc2lkZXJlZCBm b3IgV0cgYWRvcHRpb24uICAgRHJhZnRzIHRoYXQgYXJlIGFscmVhZHkgV0cgZHJhZnRzIGRvIG5v dCBuZWVkIHRvIGdvIHRocm91Z2ggdGhpcyBwcm9jZXNzIC0gYnV0IGNoYWlycyBjYW4gYXNrIGlm IGl0IHNlZW1zIGRlc2lyYWJsZS4NCg0KQXMgd2l0aCBtYW55IHByb2Nlc3NlcyBpbiB0aGUgSUVU RiwgdGhpcyBwcm9jZXNzIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIHRoZSBzcGlyaXQgb2Yg dGhlIGdvYWwsIHN1YmplY3QgdG8gY29tbW9uLXNlbnNlIGFuZCB0ZWNobmljYWwgcGVyc3BlY3Rp dmUuIEluIHBhcnRpY3VsYXIsIG5vbmUgb2YgdGhpcyBwcm9jZXNzIGlzIGludGVuZGVkIHRvIGdh dGUgb3Igb3RoZXJ3aXNlIGltcGVkZSB0aGUgbm9ybWFsIHByb2dyZXNzaW9uIG9mIGRvY3VtZW50 cyB0aHJvdWdoIElFVEYgd29ya2luZyBncm91cHM6IHJhdGhlciwgaXQgaXMgaW50ZW5kZWQgdG8g cHJvdmlkZSBhZGRpdGlvbmFsIGlucHV0LCByZXZpZXcsIGFuZCBjb21tZW50cyB0aGF0IHRoZSB3 b3JraW5nIGdyb3VwcyBjYW4gdXNlIHRvIGhlbHAgaW1wcm92ZSB0aGUgcXVhbGl0eSBvZiB0aGVp ciBkb2N1bWVudHMsIGFuZCB0byBoZWxwIGNoYWlycyBkZXRlcm1pbmUgcXVhbGl0eSBhbmQgY29u c2Vuc3VzIGZvciBkb2N1bWVudHMuIFdlIGRvIG5vdCBleHBlY3QgSUVURiBwcm9jZXNzIHRvIHdh aXQgZm9yIHJldmlld3MgdG8gaGFwcGVuLg0KDQpBcyBkZXNjcmliZWQgb24gdGhlIHdpa2kgcGFn ZSwgdGhlIGRldGFpbGVkIHByb2Nlc3MgaXM6DQoxLiAgICAgIFRoZSBXRyBDaGFpciBvciBTZWNy ZXRhcnkgZW1haWxzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIENvb3JkaW5hdG9ycyAoIERlYm9y YWggQnJ1bmdhcmQgPGRiMzU0NiBhdCBhdHQuY29tPGh0dHA6Ly9hdHQuY29tLz4+KSBhbmQgSm9u YXRoYW4gSGFyZHdpY2sgPGpvbmF0aGFuLmhhcmR3aWNrIGF0IG1ldGFzd2l0Y2guY29tPGh0dHA6 Ly9tZXRhc3dpdGNoLmNvbS8+PikuIFRoZSBzdWJqZWN0IHNob3VsZCBiZSBXRyBEcmFmdCBRQSBS ZXF1ZXN0ZWQ6IDxkcmFmdC1uYW1lPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5h bWU+Pi4NCjIuICAgICAgVGhlIFdHIENoYWlyIG9yIFNlY3JldGFyeSBtYXJrcyBhIGRyYWZ0IGlu IHRoZSBkYXRhdHJhY2tlciBhcyAiQ2FuZGlkYXRlIGZvciBBZG9wdGlvbiIgYW5kIHNwZWNpZmll cyB0aGUgZGF0ZSBvbiB3aGljaCBXRyBEcmFmdCBRQSB3YXMgcmVxdWVzdGVkLg0KMy4gICAgICBU aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBDb29yZGluYXRvcnMgYW5kIFdHIENoYWlycyBhZ3JlZSBh bmQgZmluZCBhIFFBIFJldmlld2VyLiBUaGUgcmV2aWV3IGNhbiBiZSBkb25lIGR1cmluZyB0aGUg V0cgQ2FsbCBmb3IgQWRvcHRpb24uIFRoZSBXRyBDaGFpciBvciBTZWNyZXRhcnkgYWRkcyBhIGNv bW1lbnQgaW4gdGhlIGRyYWZ0J3MgZGF0YXRyYWNrZXIgaGlzdG9yeSBwYWdlIGluZGljYXRpbmcg d2hvbSBpcyB0aGUgUUEgUmV2aWV3ZXIuDQpQbGVhc2Ugc3RhcnQgZG9pbmcgdGhpcyBub3cuDQoN CkFmdGVyIElFVEYtOTEsIHdlIGNhbiBkaXNjdXNzIGhvdyB0aGlzIGlzIGdvaW5nIGFuZCBpdHMg dXNlZnVsbmVzcy4NCg0KVGhhbmtzLA0KQWxpYQ0K --_000_521b84ffaa85498c9755c42076582780CO2PR05MB636namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0 aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTk0NTU1MTQ3Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMjEyODA1Nzc3NDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2NzA1OTY1Nzg7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE0NzgwMzI3NjY7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDINCgl7bXNv LWxpc3QtaWQ6NzE4MTY1NjA4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMjI1OTUyNjIyO30N CkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSB3b25k ZXJpbmcgaG93IHRoaXMgZml0cyB3aXRoIFdHIHJldmlldyB0ZWFtcywgd2hlcmUgdGhlcmUgYXJl IHN1Y2guDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGFuIGV4YW1wbGUsIHRoZSBNUExTIFdHIGhhcyBpdHMgb3du IHJldmlldyB0ZWFtLiBXZSBqdXN0IGZpbmlzaGVkIHRoZSByZXZpZXcgdGVhbSByZXZpZXcgb2Yg ZHJhZnQtYWtpeWEtbXBscy1sc3AtcGluZy1yZXBseS1tb2RlLXNpbXBsZSAod2l0aCByZXZpZXdz IGZyb20NCiBhbGwgMyByZXZpZXdlcnMgd2hvIHdlcmUgYXNrZWQpLiBUaGUgZG9jdW1lbnQgd2Fz IHVwZGF0ZWQgYWNjb3JkaW5nbHkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RG8gd2Ugd2FudCBhIGRvY3VtZW50IHRv IGdvIHRocm91Z2ggV0cgc3BlY2lmaWMgcmV2aWV3LCB0aGVuIHJvdXRpbmcgYXJlYSBRQSB0ZWFt IHJldmlldywgdGhlbiBjYWxsIGZvciBhZG9wdGlvbiwgYW5kIGxhdGVyIGdvIHRocm91Z2ggbGFz dCBjYWxsLCBXRyBjaGFpciByZXZpZXcsDQogUUEgdGVhbSByZXZpZXcgKGFnYWluKSwgQUQgcmV2 aWV3LCBJRVRGIGxhc3QgY2FsbCwgYW5kIElFU0cgcmV2aWV3PyA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuIGFsdGVy bmF0aXZlIHdvdWxkIGJlIHRvIHJlcGxhY2Ugb25lIG9mIHRoZSBXRyByZXZpZXcgdGVhbSByZXZp ZXdlcnMgd2l0aCBvbmUgb3IgdHdvIHJvdXRpbmcgYXJlYSBRQSByZXZpZXdlcnMsIGFuZCBkbyB0 aGVzZSB0d28gcmV2aWV3cyBhdCB0aGUgc2FtZSB0aW1lLg0KIEF0IGxlYXN0IGluIHRoZSBNUExT IFdHIHdlIHR5cGljYWxseSBkbyB0aGUgTVBMUyByZXZpZXcgdGVhbSByZXZpZXdzIGJlZm9yZSB0 aGUgY2FsbCBmb3IgV0cgYWRvcHRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgUm9zczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gcnRnLWRpciBbbWFpbHRvOnJ0Zy1kaXItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJl aGFsZiBPZiA8L2I+QWxpYSBBdGxhczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3Vz dCAyMCwgMjAxNCAxMDo0NiBBTTxicj4NCjxiPlRvOjwvYj4gcnRnLWNoYWlyc0BpZXRmLm9yZzsg cnRnLWRpckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbUlRHLURJUl0gUGxlYXNlIHN0 YXJ0IHVzaW5nIHRoZSBEb2N1bWVudCBRQSBwcm9jZXNzIG5vdzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkhpIHRvIGFsbCB0aGUgUm91dGluZyAmbmJzcDtBcmVhIFdHIENoYWlycyBhbmQgU2VjcmV0 YXJpZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+QXMgQWRyaWFuIGFuZCBJIGRpc2N1c3NlZCBwcmlvciB0byBJRVRGIDkw IGFuZCBpbiB0aGUgUm91dGluZyBBcmVhIG1lZXRpbmcgYXQgSUVURiA5MCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij53ZSB3b3VsZCBsaWtlIHRvIHN0YXJ0IHVzaW5nIHRoZSBuZXcgRHJh ZnQgUXVhbGl0eSBBc3N1cmFuY2UgcHJvY2VzcyAoJm5ic3A7PGEgaHJlZj0iaHR0cDovL3dpa2ku dG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpckRvY1FhIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3dpa2kudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rp ckRvY1FhPC9hPiZuYnNwOykNCiBmb3IgYWxsIGRyYWZ0cyB0aGF0IGFyZSBiZWluZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uLiAmbmJzcDsg RHJhZnRzIHRoYXQgYXJlIGFscmVhZHkgV0cgZHJhZnRzIGRvIG5vdCBuZWVkIHRvIGdvIHRocm91 Z2ggdGhpcyBwcm9jZXNzIC0gYnV0IGNoYWlycyBjYW4gYXNrIGlmIGl0IHNlZW1zIGRlc2lyYWJs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjVwdDtjb2xvcjpibGFjayI+QXMgd2l0aCBtYW55IHByb2Nlc3NlcyBpbiB0aGUg SUVURiwgdGhpcyBwcm9jZXNzIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIHRoZSBzcGlyaXQg b2YgdGhlIGdvYWwsIHN1YmplY3QgdG8gY29tbW9uLXNlbnNlIGFuZCB0ZWNobmljYWwgcGVyc3Bl Y3RpdmUuIEluIHBhcnRpY3VsYXIsIG5vbmUgb2YgdGhpcyBwcm9jZXNzIGlzIGludGVuZGVkDQog dG8gZ2F0ZSBvciBvdGhlcndpc2UgaW1wZWRlIHRoZSBub3JtYWwgcHJvZ3Jlc3Npb24gb2YgZG9j dW1lbnRzIHRocm91Z2ggSUVURiB3b3JraW5nIGdyb3VwczogcmF0aGVyLCBpdCBpcyBpbnRlbmRl ZCB0byBwcm92aWRlIGFkZGl0aW9uYWwgaW5wdXQsIHJldmlldywgYW5kIGNvbW1lbnRzIHRoYXQg dGhlIHdvcmtpbmcgZ3JvdXBzIGNhbiB1c2UgdG8gaGVscCBpbXByb3ZlIHRoZSBxdWFsaXR5IG9m IHRoZWlyIGRvY3VtZW50cywgYW5kIHRvIGhlbHANCiBjaGFpcnMgZGV0ZXJtaW5lIHF1YWxpdHkg YW5kIGNvbnNlbnN1cyBmb3IgZG9jdW1lbnRzLiBXZSBkbyBub3QgZXhwZWN0IElFVEYgcHJvY2Vz cyB0byB3YWl0IGZvciByZXZpZXdzIHRvIGhhcHBlbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+QXMgZGVzY3JpYmVkIG9uIHRoZSB3aWtpIHBhZ2UsIHRoZSBkZXRh aWxlZCBwcm9jZXNzIGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo0Ny4yNXB0O3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOmJsYWNrIj5U aGUgV0cgQ2hhaXIgb3IgU2VjcmV0YXJ5IGVtYWlscyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSBD b29yZGluYXRvcnMgKCBEZWJvcmFoIEJydW5nYXJkICZsdDtkYjM1NDYgYXQmbmJzcDs8YSBocmVm PSJodHRwOi8vYXR0LmNvbS8iIHRhcmdldD0iX2JsYW5rIj5hdHQuY29tPC9hPiZndDspIGFuZCBK b25hdGhhbiBIYXJkd2ljayAmbHQ7am9uYXRoYW4uaGFyZHdpY2sNCiBhdCZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly9tZXRhc3dpdGNoLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5tZXRhc3dpdGNoLmNvbTwv YT4mZ3Q7KS4gVGhlIHN1YmplY3Qgc2hvdWxkIGJlIFdHIERyYWZ0IFFBIFJlcXVlc3RlZDogJmx0 OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW5hbWUiIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzQ0MDA4OCI+ZHJhZnQtbmFtZTwvc3Bhbj48L2E+ Jmd0Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NDcuMjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjayI+VGhlIFdHIENoYWlyIG9yIFNlY3JldGFyeSBt YXJrcyBhIGRyYWZ0IGluIHRoZSBkYXRhdHJhY2tlciBhcyAmcXVvdDtDYW5kaWRhdGUgZm9yIEFk b3B0aW9uJnF1b3Q7IGFuZCBzcGVjaWZpZXMgdGhlIGRhdGUgb24gd2hpY2ggV0cgRHJhZnQgUUEg d2FzIHJlcXVlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6NDcuMjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjpibGFjayI+VGhlIFJvdXRpbmcgRGlyZWN0 b3JhdGUgQ29vcmRpbmF0b3JzIGFuZCBXRyBDaGFpcnMgYWdyZWUgYW5kIGZpbmQgYSBRQSBSZXZp ZXdlci4gVGhlIHJldmlldyBjYW4gYmUgZG9uZSBkdXJpbmcgdGhlIFdHIENhbGwgZm9yIEFkb3B0 aW9uLiBUaGUgV0cgQ2hhaXIgb3IgU2VjcmV0YXJ5IGFkZHMgYSBjb21tZW50IGluIHRoZQ0KIGRy YWZ0J3MgZGF0YXRyYWNrZXIgaGlzdG9yeSBwYWdlIGluZGljYXRpbmcgd2hvbSBpcyB0aGUgUUEg UmV2aWV3ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UGxlYXNlIHN0YXJ0IGRvaW5n IHRoaXMgbm93LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BZnRlciBJRVRGLTkxLCB3ZSBjYW4gZGlzY3VzcyBo b3cgdGhpcyBpcyBnb2luZyBhbmQgaXRzIHVzZWZ1bG5lc3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFsaWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_521b84ffaa85498c9755c42076582780CO2PR05MB636namprd05pro_-- From nobody Wed Aug 20 22:13: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 BF3E51A6F96; Wed, 20 Aug 2014 22:13:44 -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 0NaqkFAXDz-L; Wed, 20 Aug 2014 22:13:41 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0015.outbound.protection.outlook.com [213.199.154.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0261A702B; Wed, 20 Aug 2014 22:13:37 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB609.eurprd03.prod.outlook.com (10.242.109.149) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Thu, 21 Aug 2014 05:13:26 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1010.016; Thu, 21 Aug 2014 05:13:26 +0000 From: Alexander Vainshtein To: Ross Callon , Alia Atlas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Please start using the Document QA process now Thread-Index: AQHPvIVzIcIW9iqMuEO18Y4aSTFod5vZ7GSAgACSLVs= Date: Thu, 21 Aug 2014 05:13:25 +0000 Message-ID: <1408597998512.46078@ecitele.com> References: , <521b84ffaa85498c9755c42076582780@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <521b84ffaa85498c9755c42076582780@CO2PR05MB636.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(164054003)(189002)(199003)(64706001)(105586002)(54356999)(85852003)(15975445006)(106356001)(83322001)(31966008)(20776003)(74662001)(1941001)(2656002)(4396001)(92726001)(19580405001)(101416001)(19580395003)(19625215002)(92566001)(106116001)(2201001)(99396002)(86362001)(16236675004)(85306004)(46102001)(71446004)(76176999)(107886001)(83072002)(80022001)(81342001)(66066001)(107046002)(15202345003)(95666004)(15395725005)(77982001)(19617315012)(87936001)(50986999)(19627405001)(81542001)(76482001)(21056001)(74502001)(117636001)(36756003)(19607625011); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB609; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_140859799851246078ecitelecom_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Rh-wnXPg2tnOofFTt47KhjMCzzU Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 05:13:44 -0000 --_000_140859799851246078ecitelecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ross, Alia and all, Apologies for probably speaking out of turn, but just for my education: Cou= ld somebody please tell me which Routing Area WGs beside MPLS, have their o= wn review teams? The context for my question: * As of today, there are 20 WGs in the Routing Area (the number seems t= o remain the same after restructuring). I try to follow 9 of them, and MPLS= is one of these I follow * MPLS-RT is frequently mentioned on the mailing list. To me, this is a= sign of its being very much alive and kicking * I do not remember review teams being mentioned on the mailing lists o= f the other 8 WGs. Could be my omission/senility, of course, but could also= mean that they either do not exist or are not very active. * It could be nice for me to know which case it is (could be a mix, of = course:-)... Regards, and lots of thanks in advance, Sasha ________________________________ From: rtg-dir on behalf of Ross Callon Sent: Wednesday, August 20, 2014 11:09 PM To: Alia Atlas; rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: Re: [RTG-DIR] Please start using the Document QA process now I am wondering how this fits with WG review teams, where there are such. As an example, the MPLS WG has its own review team. We just finished the re= view team review of draft-akiya-mpls-lsp-ping-reply-mode-simple (with revie= ws from all 3 reviewers who were asked). The document was updated according= ly. Do we want a document to go through WG specific review, then routing area Q= A team review, then call for adoption, and later go through last call, WG c= hair review, QA team review (again), AD review, IETF last call, and IESG re= view? An alternative would be to replace one of the WG review team reviewers with= one or two routing area QA reviewers, and do these two reviews at the same= time. At least in the MPLS WG we typically do the MPLS review team reviews= before the call for WG adoption. Thanks, Ross From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia Atlas Sent: Wednesday, August 20, 2014 10:46 AM To: rtg-chairs@ietf.org; rtg-dir@ietf.org Subject: [RTG-DIR] Please start using the Document QA process now Hi to all the Routing Area WG Chairs and Secretaries, As Adrian and I discussed prior to IETF 90 and in the Routing Area meeting = at IETF 90, we would like to start using the new Draft Quality Assurance process ( http= ://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all drafts that= are being considered for WG adoption. Drafts that are already WG drafts do not need= to go through this process - but chairs can ask if it seems desirable. As with many processes in the IETF, this process is intended to be used for= the spirit of the goal, subject to common-sense and technical perspective.= In particular, none of this process is intended to gate or otherwise imped= e the normal progression of documents through IETF working groups: rather, = it is intended to provide additional input, review, and comments that the w= orking groups can use to help improve the quality of their documents, and t= o help chairs determine quality and consensus for documents. We do not expe= ct IETF process to wait for reviews to happen. As described on the wiki page, the detailed process is: 1. The WG Chair or Secretary emails the Routing Directorate Coordinato= rs ( Deborah Brungard >) and Jonathan Ha= rdwick >). The = subject should be WG Draft QA Requested: >. 2. The WG Chair or Secretary marks a draft in the datatracker as "Cand= idate for Adoption" and specifies the date on which WG Draft QA was request= ed. 3. The Routing Directorate Coordinators and WG Chairs agree and find a= QA Reviewer. The review can be done during the WG Call for Adoption. The W= G Chair or Secretary adds a comment in the draft's datatracker history page= indicating whom is the QA Reviewer. Please start doing this now. After IETF-91, we can discuss how this is going and its usefulness. Thanks, Alia --_000_140859799851246078ecitelecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ross, Alia and all,

Apologies for probably speaking out of turn, but just for my education: = Could somebody please tell me which Routing Area WGs beside MPLS, have thei= r own review teams?

The context for my question:

  • As of today, there are 20 WGs in the Routing Area (the number seems to = remain the same after restructuring). I try to follow 9 of them, and MPLS i= s one of these I follow
  • MPLS-RT is frequently mentioned on the mail= ing list. To me, this is a sign of its being very much alive and kicking
  • I do not remember review teams being mentioned on the mailing lists o= f the other 8 WGs. Could be my omission/senility, of course, but could also= mean that they either do not exist or are not very active.
  • It could be nice for me to know which case it is (could be a mix, = of course:-)...

 

Regards, and lots of thanks in advance,

Sasha

I am wonderi= ng how this fits with WG review teams, where there are such.

 

As an exampl= e, the MPLS WG has its own review team. We just finished the review team re= view of draft-akiya-mpls-lsp-ping-reply-mode-simple (with reviews from all 3 reviewers who were asked). The document was updated acc= ordingly.

 

Do we want a= document to go through WG specific review, then routing area QA team revie= w, then call for adoption, and later go through last call, WG chair review, QA team review (again), AD review, IETF last call, and IE= SG review?

 

An alternati= ve would be to replace one of the WG review team reviewers with one or two = routing area QA reviewers, and do these two reviews at the same time. At least in the MPLS WG we typically do the MPLS review team re= views before the call for WG adoption.

 

Thanks, Ross=

 

From: rtg-= dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alia Atlas
Sent: Wednesday, August 20, 2014 10:46 AM
To: rtg-chairs@ietf.org; rtg-dir@ietf.org
Subject: [RTG-DIR] Please start using the Document QA process now

 

Hi to all the Routing  Area WG Cha= irs and Secretaries,

 

As Adrian and I discussed prior to IETF= 90 and in the Routing Area meeting at IETF 90,

we would like to start using the new Dr= aft Quality Assurance process ( http://wiki.tools.ietf.or= g/area/rtg/trac/wiki/RtgDirDocQa ) for all drafts that are being

considered for WG adoption.   Draf= ts that are already WG drafts do not need to go through this process - but = chairs can ask if it seems desirable.

 

As = with many processes in the IETF, this process is intended to be used for th= e spirit of the goal, subject to common-sense and technical perspective. In= particular, none of this process is intended to gate or otherwise impede the normal progression of documents t= hrough IETF working groups: rather, it is intended to provide additional in= put, review, and comments that the working groups can use to help improve t= he quality of their documents, and to help chairs determine quality and consensus for documents. We do not ex= pect IETF process to wait for reviews to happen.=

 

As described on the wiki page, the deta= iled process is:

1.      The W= G Chair or Secretary emails the Routing Directorate Coordinators ( Deborah = Brungard <db3546 at a= tt.com>) and Jonathan Hardwick <jonathan.hardwick at metaswitch.co= m>). The subject should be WG Draft QA Requested: <draft-name>.

2.      The W= G Chair or Secretary marks a draft in the datatracker as "Candidate fo= r Adoption" and specifies the date on which WG Draft QA was requested.=

3.      The R= outing Directorate Coordinators and WG Chairs agree and find a QA Reviewer.= The review can be done during the WG Call for Adoption. The WG Chair or Se= cretary adds a comment in the draft's datatracker history page indicating whom is the QA Reviewer.

Please start doing this now.  

 

After IETF-91, we can discuss how this = is going and its usefulness.

 

Thanks,

Alia

--_000_140859799851246078ecitelecom_-- From nobody Thu Aug 21 00:43:45 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 CC9BB1A067E; Thu, 21 Aug 2014 00:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 hVIDIwMrwXPp; Thu, 21 Aug 2014 00:43:41 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF851A0652; Thu, 21 Aug 2014 00:43:41 -0700 (PDT) Received: from [192.168.0.101] (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 B1C011801586; Thu, 21 Aug 2014 09:43:39 +0200 (CEST) Message-ID: <53F5A32B.4020103@pi.nu> Date: Thu, 21 Aug 2014 09:43:39 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ross Callon , Alia Atlas , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" References: <521b84ffaa85498c9755c42076582780@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <521b84ffaa85498c9755c42076582780@CO2PR05MB636.namprd05.prod.outlook.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/MhmxJual0jLpx5uoUyNSqd4Tw4Y Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 07:43:44 -0000 Ross, I believe that the Document QA process looks like this, though it could be clearer. MPLS-RT review WG Adoption Poll/RTG Dir review Note: The RTG Dir reviewer is supposed to follow the document through the period from Adoption Poll to WGLC. WGLC/RTG Dir review I.e. the RTG Dir review is "part of" the adoption poll and wglc. The MPLS-RT is (so far) MPLS wg specific. /Loa On 2014-08-20 22:09, Ross Callon wrote: > I am wondering how this fits with WG review teams, where there are such. > > As an example, the MPLS WG has its own review team. We just finished the > review team review of draft-akiya-mpls-lsp-ping-reply-mode-simple (with > reviews from all 3 reviewers who were asked). The document was updated > accordingly. > > Do we want a document to go through WG specific review, then routing > area QA team review, then call for adoption, and later go through last > call, WG chair review, QA team review (again), AD review, IETF last > call, and IESG review? > > An alternative would be to replace one of the WG review team reviewers > with one or two routing area QA reviewers, and do these two reviews at > the same time. At least in the MPLS WG we typically do the MPLS review > team reviews before the call for WG adoption. > > Thanks, Ross > > *From:*rtg-dir [mailto:rtg-dir-bounces@ietf.org] *On Behalf Of *Alia Atlas > *Sent:* Wednesday, August 20, 2014 10:46 AM > *To:* rtg-chairs@ietf.org; rtg-dir@ietf.org > *Subject:* [RTG-DIR] Please start using the Document QA process now > > Hi to all the Routing Area WG Chairs and Secretaries, > > As Adrian and I discussed prior to IETF 90 and in the Routing Area > meeting at IETF 90, > > we would like to start using the new Draft Quality Assurance process ( > http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all > drafts that are being > > considered for WG adoption. Drafts that are already WG drafts do not > need to go through this process - but chairs can ask if it seems desirable. > > As with many processes in the IETF, this process is intended to be used > for the spirit of the goal, subject to common-sense and technical > perspective. In particular, none of this process is intended to gate or > otherwise impede the normal progression of documents through IETF > working groups: rather, it is intended to provide additional input, > review, and comments that the working groups can use to help improve the > quality of their documents, and to help chairs determine quality and > consensus for documents. We do not expect IETF process to wait for > reviews to happen. > > As described on the wiki page, the detailed process is: > > 1.The WG Chair or Secretary emails the Routing Directorate Coordinators > ( Deborah Brungard >) and Jonathan > Hardwick >). The subject should be WG Draft QA Requested: > >. > > 2.The WG Chair or Secretary marks a draft in the datatracker as > "Candidate for Adoption" and specifies the date on which WG Draft QA was > requested. > > 3.The Routing Directorate Coordinators and WG Chairs agree and find a QA > Reviewer. The review can be done during the WG Call for Adoption. The WG > Chair or Secretary adds a comment in the draft's datatracker history > page indicating whom is the QA Reviewer. > > Please start doing this now. > > After IETF-91, we can discuss how this is going and its usefulness. > > Thanks, > > Alia > -- 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 Aug 21 00:54: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 4FE401A067E; Thu, 21 Aug 2014 00:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] 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 e19_1Yxn306a; Thu, 21 Aug 2014 00:54:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4091A0476; Thu, 21 Aug 2014 00:54:29 -0700 (PDT) Received: from [192.168.0.101] (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 A42881801586; Thu, 21 Aug 2014 09:54:27 +0200 (CEST) Message-ID: <53F5A5B3.8000102@pi.nu> Date: Thu, 21 Aug 2014 09:54:27 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <53F4C6D4.2000505@pi.nu> <9727E961-8EAD-429C-B3E6-243414F03543@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/0qCwK57PJhA00eylxPUk3QchZFI Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 07:54:31 -0000 Alia, To put it simply! As for the documents that we start wg adoption poll for we also request RTG Dir review, and that reviewer will stay with the document through the wg process and do a new RTG Dir review at wglc. Right? As for documents that we already have a wg documents, we won't request RTG Dir reviews, unless we want them for some other reason than Document QA. Right? /Loa On 2014-08-20 20:37, Alia Atlas wrote: > Loa, > > On Wed, Aug 20, 2014 at 1:42 PM, Loa Andersson > wrote: > > Alia, > > I think you missed the point. Initially we had two QA reviews > intended. One at wg adoption poll and a second at wglc. The > directive going out now only talks about a RTG dir review at > adoption poll intended or not it is a change. Why did we change. > > > Oh - there isn't a change in terms of the QA reviews intended. At the > WG adoption poll is when the QA reviewer is assigned - and this is > talking about that process. Once the QA reviewer is assigned, he or she > is expected to do both of the reviews. Please do read the wiki and > make/suggest changes for clarification if necessary. > > Regards, > Alia > > /Loa > > Sent from my iPhone > > On 20 aug 2014, at 18:32, Alia Atlas > wrote: > >> Hi Loa, >> >> On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson > > wrote: >> >> Alia >> >> A few quick questions on this. In the message that the RTG ADs >> sent >> to the wg chairs and directorate when the discussion on re-org >> started >> you said >> >> "First, we intend to use our Routing Directorate more >> proactively by >> introducing a Working Group Draft Quality Assurance (WG Draft QA) >> process where the same selected routing directorate member >> will review >> a draft during WG draft adoption and during WG last call. >> The process >> will be documented on the Routing Area wiki. This should allow >> directorate reviews to report technical issues that can >> actually get >> fixed early in the process (equiv of bug reports) as opposed >> to just >> noting the concerns in the drafts (equiv of release notes)." >> >> It seems that there are a changes from what was said at that time >> and what is said now. >> >> "... where the same selected routing directorate member will >> review >> a draft during WG draft adoption and during WG last call" >> >> while we now say >> >> "...for all drafts that are being considered for WG adoption." >> >> What motivated this change? >> >> >> This isn't intended to be a change. A draft that is going to have >> a WG call >> for adoption issued should get a QA reviewer so that the review >> can happen >> ideally before the WG call for adoption ends. >> >> Basically, I see the process as: >> >> 1. Individual draft submitted and discussed. >> 2. WG Chairs decide to issue a call for adoption. >> 2.1 WG Chairs get a QA reviewer with review >> 2.2 WG Chairs issue a call for adoption (can be before QA reviewer >> is assigned if >> that is taking too much time) >> 2.3 Ideally, QA reviewer contributes the review to the WG mailing list >> 2.4 WG Chairs decide if there is active consensus to adopt the draft. >> 3. Draft is improved based upon reviews and comments. >> Where MPLS has additional process between considering a draft and >> doing a WG >> call for adoption that is treating those early reviews as gating, >> I can understand >> that you may see a difference between the two states. >> >> Second, some wg's have review teams that does something similar to >> the WG Draft QA process just prior to that the the call for >> working >> group adoption is started. >> >> >> Right - that is intended really for review inside the WG and >> before the call for >> WG adoption is started. >> >> The WG Draft QA is intended more for cross-WG review and expected to >> take place in parallel with the call for adoption. >> >> Do we do the WG Draft QA in addition to, instead of these >> reviews, >> or can we continue doing the review team reviews instead of WG >> Draft QA? >> >> >> I believe that they are addressing slightly different problems. >> For MPLS, I think >> that some of the drafts could benefit from early review that >> considers cross-WG >> concerns as well as usefulness of the draft. >> >> That said, the process does allow for WG chairs to decide not to >> request a QA >> reviewer or to request one who isn't part of the routing >> directorate. We just ask >> that it's documented so that we can tell the difference between a >> decision not to >> request and a failure to remember to do so. >> >> I'd prefer to see the QA reviews done so we can determine how much >> value is >> being added rather than simply say it's not needed for a >> particular WG. >> >> Regards, >> Alia >> >> >> /Loa >> >> >> >> >> On 2014-08-20 16:45, Alia Atlas wrote: >> >> Hi to all the Routing Area WG Chairs and Secretaries, >> >> As Adrian and I discussed prior to IETF 90 and in the >> Routing Area >> meeting at IETF 90, >> we would like to start using the new Draft Quality >> Assurance process ( >> http://wiki.tools.ietf.org/__area/rtg/trac/wiki/RtgDirDocQa >> ) for all >> drafts that are being >> considered for WG adoption. Drafts that are already WG >> drafts do not >> need to go through this process - but chairs can ask if it >> seems desirable. >> >> As with many processes in the IETF, this process is >> intended to be used >> for the spirit of the goal, subject to common-sense and >> technical >> perspective. In particular, none of this process is >> intended to gate or >> otherwise impede the normal progression of documents >> through IETF >> working groups: rather, it is intended to provide >> additional input, >> review, and comments that the working groups can use to >> help improve the >> quality of their documents, and to help chairs determine >> quality and >> consensus for documents. We do not expect IETF process to >> wait for >> reviews to happen. >> >> As described on the wiki page, the detailed process is: >> >> 1. The WG Chair or Secretary emails the Routing Directorate >> >> Coordinators ( Deborah Brungard > >> >) and Jonathan Hardwick >> > metaswitch.com >> >). The subject should be WG >> Draft QA Requested: > > >>. >> >> 2. The WG Chair or Secretary marks a draft in the >> datatracker as >> >> "Candidate for Adoption" and specifies the date on >> which WG Draft QA >> was requested. >> >> 3. The Routing Directorate Coordinators and WG Chairs >> agree and find a >> >> QA Reviewer. The review can be done during the WG Call >> for Adoption. >> The WG Chair or Secretary adds a comment in the >> draft's datatracker >> history page indicating whom is the QA Reviewer. >> >> Please start doing this now. >> >> After IETF-91, we can discuss how this is going and its >> usefulness. >> >> Thanks, >> Alia >> >> >> -- >> >> >> Loa Andersson email: >> loa@mail01.huawei.com >> Senior MPLS Expert loa@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 Thu Aug 21 07:06: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 19B661A0314; Thu, 21 Aug 2014 07:06: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 4gqJwKm3zfM2; Thu, 21 Aug 2014 07:06:50 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D21101A02F5; Thu, 21 Aug 2014 07:06:49 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id t59so8162908yho.11 for ; Thu, 21 Aug 2014 07:06:49 -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=6nRP5Yy7xn+admmogwBvJ63/YvW+g3rva/qjDQZgtr8=; b=gMh8s8SgDWgQxt2WYIlpqItwK90hNZsg3NByeuMD4xjCP/RtS1WekKTIzQjJj9vt2l 0h6AFeayba2RQHS6OOCxKUy5XYAUZBg+v4G1Ils4x6vxDDKeoTKStJv67BaCO7pfEmCg Btfo9Ep/T4LSzEaNjT9mZcdaMd3ybe6Ywl+Qn0RMaLnj41bBpMiHLxJ8HLo3UGPezlRc TXVFApPLIjOpWoYVDJm94xxyYbgjmNGKabZ7nYKQAGo5pW5r8Go2gVGtBZDaR8aEQEy1 zECpwyd2Fiw+CD3rNeLG5MUUhMO+NnpTEHWUiHFNhP3+Vs0DTxLmeId4H3gzF6M4oAHh hG3Q== MIME-Version: 1.0 X-Received: by 10.236.150.46 with SMTP id y34mr82064855yhj.77.1408630009053; Thu, 21 Aug 2014 07:06:49 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Thu, 21 Aug 2014 07:06:48 -0700 (PDT) In-Reply-To: <53F5A5B3.8000102@pi.nu> References: <53F4C6D4.2000505@pi.nu> <9727E961-8EAD-429C-B3E6-243414F03543@pi.nu> <53F5A5B3.8000102@pi.nu> Date: Thu, 21 Aug 2014 10:06:48 -0400 Message-ID: From: Alia Atlas To: Loa Andersson Content-Type: multipart/alternative; boundary=14dae9d7c8844f489f0501243b8d Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ICA6drAHqn7WtE52WiOs3UR2_KU Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 14:06:54 -0000 --14dae9d7c8844f489f0501243b8d Content-Type: text/plain; charset=UTF-8 Loa, Yes, exactly. Alia On Thu, Aug 21, 2014 at 3:54 AM, Loa Andersson wrote: > Alia, > > To put it simply! > > As for the documents that we start wg adoption poll for we also request > RTG Dir review, and that reviewer will stay with the document through > the wg process and do a new RTG Dir review at wglc. Right? > > As for documents that we already have a wg documents, we won't request > RTG Dir reviews, unless we want them for some other reason than > Document QA. Right? > > /Loa > > > On 2014-08-20 20:37, Alia Atlas wrote: > >> Loa, >> >> On Wed, Aug 20, 2014 at 1:42 PM, Loa Andersson > > wrote: >> >> Alia, >> >> I think you missed the point. Initially we had two QA reviews >> intended. One at wg adoption poll and a second at wglc. The >> directive going out now only talks about a RTG dir review at >> adoption poll intended or not it is a change. Why did we change. >> >> >> Oh - there isn't a change in terms of the QA reviews intended. At the >> WG adoption poll is when the QA reviewer is assigned - and this is >> talking about that process. Once the QA reviewer is assigned, he or she >> is expected to do both of the reviews. Please do read the wiki and >> make/suggest changes for clarification if necessary. >> >> Regards, >> Alia >> >> /Loa >> >> Sent from my iPhone >> >> On 20 aug 2014, at 18:32, Alia Atlas > > wrote: >> >> Hi Loa, >>> >>> On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson >> > wrote: >>> >>> Alia >>> >>> A few quick questions on this. In the message that the RTG ADs >>> sent >>> to the wg chairs and directorate when the discussion on re-org >>> started >>> you said >>> >>> "First, we intend to use our Routing Directorate more >>> proactively by >>> introducing a Working Group Draft Quality Assurance (WG Draft >>> QA) >>> process where the same selected routing directorate member >>> will review >>> a draft during WG draft adoption and during WG last call. >>> The process >>> will be documented on the Routing Area wiki. This should allow >>> directorate reviews to report technical issues that can >>> actually get >>> fixed early in the process (equiv of bug reports) as opposed >>> to just >>> noting the concerns in the drafts (equiv of release notes)." >>> >>> It seems that there are a changes from what was said at that time >>> and what is said now. >>> >>> "... where the same selected routing directorate member will >>> review >>> a draft during WG draft adoption and during WG last call" >>> >>> while we now say >>> >>> "...for all drafts that are being considered for WG adoption." >>> >>> What motivated this change? >>> >>> >>> This isn't intended to be a change. A draft that is going to have >>> a WG call >>> for adoption issued should get a QA reviewer so that the review >>> can happen >>> ideally before the WG call for adoption ends. >>> >>> Basically, I see the process as: >>> >>> 1. Individual draft submitted and discussed. >>> 2. WG Chairs decide to issue a call for adoption. >>> 2.1 WG Chairs get a QA reviewer with review >>> 2.2 WG Chairs issue a call for adoption (can be before QA reviewer >>> is assigned if >>> that is taking too much time) >>> 2.3 Ideally, QA reviewer contributes the review to the WG mailing >>> list >>> 2.4 WG Chairs decide if there is active consensus to adopt the draft. >>> 3. Draft is improved based upon reviews and comments. >>> Where MPLS has additional process between considering a draft and >>> doing a WG >>> call for adoption that is treating those early reviews as gating, >>> I can understand >>> that you may see a difference between the two states. >>> >>> Second, some wg's have review teams that does something similar >>> to >>> the WG Draft QA process just prior to that the the call for >>> working >>> group adoption is started. >>> >>> >>> Right - that is intended really for review inside the WG and >>> before the call for >>> WG adoption is started. >>> >>> The WG Draft QA is intended more for cross-WG review and expected to >>> take place in parallel with the call for adoption. >>> >>> Do we do the WG Draft QA in addition to, instead of these >>> reviews, >>> or can we continue doing the review team reviews instead of WG >>> Draft QA? >>> >>> >>> I believe that they are addressing slightly different problems. >>> For MPLS, I think >>> that some of the drafts could benefit from early review that >>> considers cross-WG >>> concerns as well as usefulness of the draft. >>> >>> That said, the process does allow for WG chairs to decide not to >>> request a QA >>> reviewer or to request one who isn't part of the routing >>> directorate. We just ask >>> that it's documented so that we can tell the difference between a >>> decision not to >>> request and a failure to remember to do so. >>> >>> I'd prefer to see the QA reviews done so we can determine how much >>> value is >>> being added rather than simply say it's not needed for a >>> particular WG. >>> >>> Regards, >>> Alia >>> >>> >>> /Loa >>> >>> >>> >>> >>> On 2014-08-20 16:45, Alia Atlas wrote: >>> >>> Hi to all the Routing Area WG Chairs and Secretaries, >>> >>> As Adrian and I discussed prior to IETF 90 and in the >>> Routing Area >>> meeting at IETF 90, >>> we would like to start using the new Draft Quality >>> Assurance process ( >>> http://wiki.tools.ietf.org/__area/rtg/trac/wiki/RtgDirDocQa >>> >>> >>> ) for all >>> drafts that are being >>> considered for WG adoption. Drafts that are already WG >>> drafts do not >>> need to go through this process - but chairs can ask if it >>> seems desirable. >>> >>> As with many processes in the IETF, this process is >>> intended to be used >>> for the spirit of the goal, subject to common-sense and >>> technical >>> perspective. In particular, none of this process is >>> intended to gate or >>> otherwise impede the normal progression of documents >>> through IETF >>> working groups: rather, it is intended to provide >>> additional input, >>> review, and comments that the working groups can use to >>> help improve the >>> quality of their documents, and to help chairs determine >>> quality and >>> consensus for documents. We do not expect IETF process to >>> wait for >>> reviews to happen. >>> >>> As described on the wiki page, the detailed process is: >>> >>> 1. The WG Chair or Secretary emails the Routing Directorate >>> >>> Coordinators ( Deborah Brungard >> >>> >) and Jonathan Hardwick >>> >> metaswitch.com >>> >). The subject should be WG >>> Draft QA Requested: >> >> >>> >>. >>> >>> 2. The WG Chair or Secretary marks a draft in the >>> datatracker as >>> >>> "Candidate for Adoption" and specifies the date on >>> which WG Draft QA >>> was requested. >>> >>> 3. The Routing Directorate Coordinators and WG Chairs >>> agree and find a >>> >>> QA Reviewer. The review can be done during the WG Call >>> for Adoption. >>> The WG Chair or Secretary adds a comment in the >>> draft's datatracker >>> history page indicating whom is the QA Reviewer. >>> >>> Please start doing this now. >>> >>> After IETF-91, we can discuss how this is going and its >>> usefulness. >>> >>> Thanks, >>> Alia >>> >>> >>> -- >>> >>> >>> Loa Andersson email: >>> loa@mail01.huawei.com >>> Senior MPLS Expert loa@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 > --14dae9d7c8844f489f0501243b8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Loa,

Yes, exactly.

=
Alia


On Thu, Aug 21, 2014 at 3:54 AM, Loa Andersson &l= t;loa@pi.nu> w= rote:
Alia,

To put it simply!

As for the documents that we start wg adoption poll for we also request
RTG Dir review, and that reviewer will stay with the document through
the wg process and do a new RTG Dir review at wglc. Right?

As for documents that we already have a wg documents, we won't request<= br> RTG Dir reviews, unless we want them for some other reason than
Document QA. Right?

/Loa


On 2014-08-20 20:37, Alia Atlas wrote:
Loa,

On Wed, Aug 20, 2014 at 1:42 PM, Loa Andersson <loa@pi.nu
<mailto:loa@pi.nu>= > wrote:

=C2=A0 =C2=A0 Alia,

=C2=A0 =C2=A0 I think you missed the point. Initially we had two QA reviews=
=C2=A0 =C2=A0 intended. One at wg adoption poll and a second at wglc. The =C2=A0 =C2=A0 directive going out now only talks about a RTG dir review at<= br> =C2=A0 =C2=A0 adoption poll intended or not it is a change. Why did we chan= ge.


Oh - there isn't a change in terms of the QA reviews intended.=C2=A0 At= the
WG adoption poll is when the QA reviewer is assigned - and this is
talking about that process.=C2=A0 Once the QA reviewer is assigned, he or s= he
is expected to do both of the reviews.=C2=A0 =C2=A0Please do read the wiki = and
make/suggest changes for clarification if necessary.

Regards,
Alia

=C2=A0 =C2=A0 /Loa

=C2=A0 =C2=A0 Sent from my iPhone

=C2=A0 =C2=A0 On 20 aug 2014, at 18:32, Alia Atlas <akatlas@gmail.com
=C2=A0 =C2=A0 <mailto:akatlas@gmail.com>> wrote:

=C2=A0 =C2=A0 Hi Loa,

=C2=A0 =C2=A0 On Wed, Aug 20, 2014 at 12:03 PM, Loa Andersson <loa@pi.nu
=C2=A0 =C2=A0 <mailto:loa= @pi.nu>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alia

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A few quick questions on this. In the message t= hat the RTG ADs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the wg chairs and directorate when the discu= ssion on re-org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 started
=C2=A0 =C2=A0 =C2=A0 =C2=A0 you said

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "First, we intend to use our Routing Direc= torate more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proactively by
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0introducing a Working Group Draft Quality= Assurance (WG Draft QA)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0process where the same selected routing d= irectorate member
=C2=A0 =C2=A0 =C2=A0 =C2=A0 will review
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a draft during WG draft adoption and duri= ng WG last call.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The process
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will be documented on the Routing Area wi= ki.=C2=A0 This should allow
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0directorate reviews to report technical i= ssues that can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 actually get
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fixed early in the process (equiv of bug = reports) as opposed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to just
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0noting the concerns in the drafts (equiv = of release notes)."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It seems that there are a changes from what was= said at that time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and what is said now.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "... where the same selected routing direc= torate member will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 review
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a draft during WG draft adoption and duri= ng WG last call"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 while we now say

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "...for all drafts that are being consider= ed for WG adoption."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 What motivated this change?


=C2=A0 =C2=A0 This isn't intended to be a change.=C2=A0 A draft that is= going to have
=C2=A0 =C2=A0 a WG call
=C2=A0 =C2=A0 for adoption issued should get a QA reviewer so that the revi= ew
=C2=A0 =C2=A0 can happen
=C2=A0 =C2=A0 ideally before the WG call for adoption ends.

=C2=A0 =C2=A0 Basically, I see=C2=A0 the process as:

=C2=A0 =C2=A0 1. Individual draft submitted and discussed.
=C2=A0 =C2=A0 2. WG Chairs decide to issue a call for adoption.
=C2=A0 =C2=A0 2.1 WG Chairs get a QA reviewer with review
=C2=A0 =C2=A0 2.2 WG Chairs issue a call for adoption (can be before QA rev= iewer
=C2=A0 =C2=A0 is assigned if
=C2=A0 =C2=A0 that is taking too much time)
=C2=A0 =C2=A0 2.3 Ideally, QA reviewer contributes the review to the WG mai= ling list
=C2=A0 =C2=A0 2.4 WG Chairs decide if there is active consensus to adopt th= e draft.
=C2=A0 =C2=A0 3. Draft is improved based upon reviews and comments.
=C2=A0 =C2=A0 Where MPLS has additional process between considering a draft= and
=C2=A0 =C2=A0 doing a WG
=C2=A0 =C2=A0 call for adoption that is treating those early reviews as gat= ing,
=C2=A0 =C2=A0 I can understand
=C2=A0 =C2=A0 that you may see a difference between the two states.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second, some wg's have review teams that do= es something similar to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the WG Draft QA process just prior to that the = the call for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 working
=C2=A0 =C2=A0 =C2=A0 =C2=A0 group adoption is started.


=C2=A0 =C2=A0 Right - that is intended really for review inside the WG and<= br> =C2=A0 =C2=A0 before the call for
=C2=A0 =C2=A0 WG adoption is started.

=C2=A0 =C2=A0 The WG Draft QA is intended more for cross-WG review and expe= cted to
=C2=A0 =C2=A0 take place in parallel with the call for adoption.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Do we do the=C2=A0 WG Draft QA in addition to, = instead of these
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reviews,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or can we continue doing the review team review= s instead of WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft QA?


=C2=A0 =C2=A0 I believe that they are addressing slightly different problem= s.
=C2=A0 =C2=A0 =C2=A0For MPLS, I think
=C2=A0 =C2=A0 that some of the drafts could benefit from early review that<= br> =C2=A0 =C2=A0 considers cross-WG
=C2=A0 =C2=A0 concerns as well as usefulness of the draft.

=C2=A0 =C2=A0 That said, the process does allow for WG chairs to decide not= to
=C2=A0 =C2=A0 request a QA
=C2=A0 =C2=A0 reviewer or to request one who isn't part of the routing<= br> =C2=A0 =C2=A0 directorate.=C2=A0 We just ask
=C2=A0 =C2=A0 that it's documented so that we can tell the difference b= etween a
=C2=A0 =C2=A0 decision not to
=C2=A0 =C2=A0 request and a failure to remember to do so.

=C2=A0 =C2=A0 I'd prefer to see the QA reviews done so we can determine= how much
=C2=A0 =C2=A0 value is
=C2=A0 =C2=A0 being added rather than simply say it's not needed for a<= br> =C2=A0 =C2=A0 particular WG.

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Alia


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




=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 2014-08-20 16:45, Alia Atlas wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi to all the Routing=C2=A0 Area = WG Chairs and Secretaries,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As Adrian and I discussed prior t= o IETF 90 and in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing Area
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meeting at IETF 90,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we would like to start using the = new Draft Quality
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Assurance process (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://wiki.tools.= ietf.org/__area/rtg/trac/wiki/RtgDirDocQa <http:= //wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa><= div>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ) for all
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drafts that are being
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 considered for WG adoption.=C2=A0= =C2=A0Drafts that are already WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drafts do not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 need to go through this process -= but chairs can ask if it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 seems desirable.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As with many processes in the IET= F, this process is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended to be used
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for the spirit of the goal, subje= ct to common-sense and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 technical
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 perspective. In particular, none = of this process is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended to gate or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 otherwise impede the normal progr= ession of documents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 working groups: rather, it is int= ended to provide
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 additional input,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 review, and comments that the wor= king groups can use to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 help improve the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 quality of their documents, and t= o help chairs determine
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 quality and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 consensus for documents. We do no= t expect IETF process to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wait for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reviews to happen.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 As described on the wiki page, th= e detailed process is:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. The WG Chair or Secretar= y emails the Routing Directorate

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Coordinators ( Debo= rah Brungard <db3546 at att= .com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://att.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://att.com/>>) and Jonathan Ha= rdwick
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <jonathan.hardwick at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 metaswitch.com <http://metaswitch.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://metaswitch.com/>>). The subject sh= ould be WG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Draft QA Requested:= <draft-name
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://tools.ietf.or= g/html/__draft-name

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://tools.ietf.org/html/dr= aft-name>>>.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. The WG Chair or Secretar= y marks a draft in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datatracker as

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Candidate for= Adoption" and specifies the date on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which WG Draft QA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 was requested.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03. The Routing Directorate = Coordinators and WG Chairs
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 agree and find a

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 QA Reviewer. The re= view can be done during the WG Call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for Adoption.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The WG Chair or Sec= retary adds a comment in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft's datatracker
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 history page indica= ting whom is the QA Reviewer.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Please start doing this now.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 After IETF-91, we can discuss how= this is going and its
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 usefulness.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Alia


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


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 email:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@mail01.huawei.com <mailto:loa@mail01.huawei.com>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Senior MPLS Expert loa@pi.nu <mailto:loa@pi.nu>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Huawei Technologies (consultant)=C2=A0 =C2=A0 = =C2=A0phone: +46 739 81 21 64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <tel:%2B46%20739%2081%2021%2064>



--


Loa Andersson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 email: loa@mail01.huawei.com
Senior MPLS Expert=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 loa@pi.nu
Huawei Technologies (consultant)=C2=A0 =C2=A0 =C2=A0phone: +46 739= 81 21 64

--14dae9d7c8844f489f0501243b8d-- From nobody Thu Aug 21 07:10: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 5C4231A034A for ; Thu, 21 Aug 2014 07:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwYl_AJ7tqRb for ; Thu, 21 Aug 2014 07:10:29 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 6447D1A032E for ; Thu, 21 Aug 2014 07:10:14 -0700 (PDT) Received: (qmail 31499 invoked by uid 0); 21 Aug 2014 14:10:08 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy8.mail.unifiedlayer.com with SMTP; 21 Aug 2014 14:10:08 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id hYA31o00J2SSUrH01YA66D; Thu, 21 Aug 2014 14:10:06 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=GdzRxsf7yJoA:10 a=zZcDDSsFPPcA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=bwR9eBR2AAAA:8 a=dU1aCudMhM6yx-oUGPcA:9 a=QEXdDO2ut3YA:10 a=eRsKL0hzPpUA:10 a=jGFIkMWxz3cA: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=vZh37ioqpUtQ8Napbp/InbyXPgZrH3Qg5bQd/++S/CE=; b=LR+cZ9lOjBEcmZaPsH3y2BE5xVm9Uuafo0EK+b6EkgkrHWmbWLewZErioqCzbLAcmBQXMSdYhsBIYL+EOB1aBc4RjIK06rbXo5BAbhZEUGi+TjCDRclhRAqb0jG2WcXQ; Received: from box313.bluehost.com ([69.89.31.113]:46275 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKT40-0006pZ-FH; Thu, 21 Aug 2014 08:10:04 -0600 Message-ID: <53F5FE0A.4080205@labn.net> Date: Thu, 21 Aug 2014 10:11:22 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/CrKSZRyBYn3GaqKC6pMP-WmvgNA Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 14:10:30 -0000 Alia, I'm unclear on one point: Is it your intent for the quality review to gate WG acceptance? Lou On 8/20/2014 10:45 AM, Alia Atlas wrote: > Hi to all the Routing Area WG Chairs and Secretaries, > > As Adrian and I discussed prior to IETF 90 and in the Routing Area > meeting at IETF 90, > we would like to start using the new Draft Quality Assurance process > ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all > drafts that are being > considered for WG adoption. Drafts that are already WG drafts do not > need to go through this process - but chairs can ask if it seems > desirable. > > As with many processes in the IETF, this process is intended to be > used for the spirit of the goal, subject to common-sense and technical > perspective. In particular, none of this process is intended to gate > or otherwise impede the normal progression of documents through IETF > working groups: rather, it is intended to provide additional input, > review, and comments that the working groups can use to help improve > the quality of their documents, and to help chairs determine quality > and consensus for documents. We do not expect IETF process to wait for > reviews to happen. > > As described on the wiki page, the detailed process is: > > 1. The WG Chair or Secretary emails the Routing Directorate > Coordinators ( Deborah Brungard >) and Jonathan Hardwick at metaswitch.com >). The subject should > be WG Draft QA Requested: >. > > 2. The WG Chair or Secretary marks a draft in the datatracker as > "Candidate for Adoption" and specifies the date on which WG Draft > QA was requested. > > 3. The Routing Directorate Coordinators and WG Chairs agree and find > a QA Reviewer. The review can be done during the WG Call for > Adoption. The WG Chair or Secretary adds a comment in the draft's > datatracker history page indicating whom is the QA Reviewer. > > Please start doing this now. =20 > > After IETF-91, we can discuss how this is going and its usefulness. > > Thanks, > Alia From nobody Thu Aug 21 07:52: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 19E1A1A0339; Thu, 21 Aug 2014 07:52: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 Hxwr_RCWvK_E; Thu, 21 Aug 2014 07:52:17 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399851A038F; Thu, 21 Aug 2014 07:52:17 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id t59so8117772yho.39 for ; Thu, 21 Aug 2014 07:52:16 -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=KPXLGxhFk2mtG3vPUu/mIQvBvdzeUJW23OtaPloaMaI=; b=vj74TWzzb8qyJCcfdleiIirFaKCaDiE80jb4vij2Fgxk/mJemRXBR2AI0T4t4C721Z /06izxdDmnMwHfoiWw16q12v5xuUlTa5/in9uDV81xKPq43VJnQ4BuqA52Y0vwng0M+G 4S8PC1WXn+LCcQ29F+xSoU2qhNuvwIy7aoBWWZo1PU7l2iBsZ4vqh0jpJWx9oOPtX/TD DoZ0WlaoCdM+fuKVLzA8CaoLKtAlZ5rgZ/hgWXuu6gNgsnZPP/hHYcqPg3FoFwNWO/lx Gbj+V1B5WUToIAX+c/vGNB/886jvcEh/a7qgikz5ZlN8f/uvacKdxj58tc7CnT+uOeoY 9E1Q== MIME-Version: 1.0 X-Received: by 10.236.123.114 with SMTP id u78mr2816577yhh.107.1408632736594; Thu, 21 Aug 2014 07:52:16 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Thu, 21 Aug 2014 07:52:16 -0700 (PDT) In-Reply-To: <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> Date: Thu, 21 Aug 2014 10:52:16 -0400 Message-ID: From: Alia Atlas To: Sandra Murphy Content-Type: multipart/alternative; boundary=20cf301b659fe2426d050124dd84 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/7IOdxz8yCU_k9P68f-ddC2h84Rg Cc: "rtg-dir@ietf.org" , Lou Berger , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 14:52:20 -0000 --20cf301b659fe2426d050124dd84 Content-Type: text/plain; charset=UTF-8 Sandy, Exactly so. :-) Alia On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy wrote: > I read through the process again and to me it seems clear that it does not. > > "Any issues the QA Reviewer finds are written down, sent to the mailing > list and discussed for future versions, but need not gate the progress of > the draft in the WG" > > I'd be interested to see how others interpret the process. > > --Sandy > > On Aug 21, 2014, at 10:11 AM, Lou Berger wrote: > > > Alia, > > I'm unclear on one point: Is it your intent for the quality review > > to gate WG acceptance? > > > > Lou > > > > On 8/20/2014 10:45 AM, Alia Atlas wrote: > >> Hi to all the Routing Area WG Chairs and Secretaries, > >> > >> As Adrian and I discussed prior to IETF 90 and in the Routing Area > >> meeting at IETF 90, > >> we would like to start using the new Draft Quality Assurance process > >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all > >> drafts that are being > >> considered for WG adoption. Drafts that are already WG drafts do not > >> need to go through this process - but chairs can ask if it seems > >> desirable. > >> > >> As with many processes in the IETF, this process is intended to be > >> used for the spirit of the goal, subject to common-sense and technical > >> perspective. In particular, none of this process is intended to gate > >> or otherwise impede the normal progression of documents through IETF > >> working groups: rather, it is intended to provide additional input, > >> review, and comments that the working groups can use to help improve > >> the quality of their documents, and to help chairs determine quality > >> and consensus for documents. We do not expect IETF process to wait for > >> reviews to happen. > >> > >> As described on the wiki page, the detailed process is: > >> > >> 1. The WG Chair or Secretary emails the Routing Directorate > >> Coordinators ( Deborah Brungard >> >) and Jonathan Hardwick >> at metaswitch.com >). The subject should > >> be WG Draft QA Requested: >> >. > >> > >> 2. The WG Chair or Secretary marks a draft in the datatracker as > >> "Candidate for Adoption" and specifies the date on which WG Draft > >> QA was requested. > >> > >> 3. The Routing Directorate Coordinators and WG Chairs agree and find > >> a QA Reviewer. The review can be done during the WG Call for > >> Adoption. The WG Chair or Secretary adds a comment in the draft's > >> datatracker history page indicating whom is the QA Reviewer. > >> > >> Please start doing this now. > >> > >> After IETF-91, we can discuss how this is going and its usefulness. > >> > >> Thanks, > >> Alia > > > > --20cf301b659fe2426d050124dd84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sandy,

Exactly so. =C2=A0 =C2=A0:-)

Alia


On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy <= sandy@tislabs.com> wrote:
I read through the process again and to me i= t seems clear that it does not.

"Any issues the QA Reviewer finds are written down, sent to the mailin= g list and discussed for future versions, but need not gate the progress of= the draft in the WG"

I'd be interested to see how others interpret the process.

--Sandy

On Aug 21, 2014, at 10:11 AM, Lou Berger <lberger@labn.net> wrote:

> Alia,
>=C2=A0 =C2=A0 I'm unclear on one point: Is it your intent for the q= uality review
> to gate WG acceptance?
>
> Lou
>
> On 8/20/2014 10:45 AM, Alia Atlas wrote:
>> Hi to all the Routing=C2=A0 Area WG Chairs and Secretaries,
>>
>> As Adrian and I discussed prior to IETF 90 and in the Routing Area=
>> meeting at IETF 90,
>> we would like to start using the new Draft Quality Assurance proce= ss
>> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDi= rDocQa ) for all
>> drafts that are being
>> considered for WG adoption.=C2=A0 =C2=A0Drafts that are already WG= drafts do not
>> need to go through this process - but chairs can ask if it seems >> desirable.
>>
>> As with many processes in the IETF, this process is intended to be=
>> used for the spirit of the goal, subject to common-sense and techn= ical
>> perspective. In particular, none of this process is intended to ga= te
>> or otherwise impede the normal progression of documents through IE= TF
>> working groups: rather, it is intended to provide additional input= ,
>> review, and comments that the working groups can use to help impro= ve
>> the quality of their documents, and to help chairs determine quali= ty
>> and consensus for documents. We do not expect IETF process to wait= for
>> reviews to happen.
>>
>> As described on the wiki page, the detailed process is:
>>
>> 1. The WG Chair or Secretary emails the Routing Directorate
>>=C2=A0 =C2=A0 Coordinators ( Deborah Brungard <db3546 at att.com
>>=C2=A0 =C2=A0 <htt= p://att.com/>>) and Jonathan Hardwick <jonathan.hardwick
>>=C2=A0 =C2=A0 at metaswitch.com <http://metaswitch.com/>>). The subject should
>>=C2=A0 =C2=A0 be WG Draft QA Requested: <draft-name
>>=C2=A0 =C2=A0 <http://tools.ietf.org/html/draft-name>>.
>>
>> 2. The WG Chair or Secretary marks a draft in the datatracker as >>=C2=A0 =C2=A0 "Candidate for Adoption" and specifies the = date on which WG Draft
>>=C2=A0 =C2=A0 QA was requested.
>>
>> 3. The Routing Directorate Coordinators and WG Chairs agree and fi= nd
>>=C2=A0 =C2=A0 a QA Reviewer. The review can be done during the WG C= all for
>>=C2=A0 =C2=A0 Adoption. The WG Chair or Secretary adds a comment in= the draft's
>>=C2=A0 =C2=A0 datatracker history page indicating whom is the QA Re= viewer.
>>
>> Please start doing this now.
>>
>> After IETF-91, we can discuss how this is going and its usefulness= .
>>
>> Thanks,
>> Alia
>


--20cf301b659fe2426d050124dd84-- From nobody Thu Aug 21 08:11: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 04FB61A04A4 for ; Thu, 21 Aug 2014 08:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqqnfBYRgcJ4 for ; Thu, 21 Aug 2014 08:11:01 -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 C94901A03CA for ; Thu, 21 Aug 2014 08:11:01 -0700 (PDT) Received: (qmail 28823 invoked by uid 0); 21 Aug 2014 15:11:01 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy3.mail.unifiedlayer.com with SMTP; 21 Aug 2014 15:11:01 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id hZAu1o00j2SSUrH01ZAxyz; Thu, 21 Aug 2014 15:10:59 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=GdzRxsf7yJoA:10 a=zZcDDSsFPPcA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ImH2GW_KAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=bwR9eBR2AAAA:8 a=-RbjBnzbt5pbV-ekFSYA:9 a=QEXdDO2ut3YA:10 a=eRsKL0hzPpUA:10 a=jGFIkMWxz3cA:10 a=Da6P7i8uiOsA: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=J4kwFBy/sodSGo4iW2g6q5BNm3d36jFa+X2bqiRaEgU=; b=u+JNyVP4zbS8G2jwNVOsrCZv4w+S2a0IlU0tRpk0olSCUKKPS0zHyQftW703gLcXE38z+FDAOysKXgDpIWUMwDDhr60FaraHZEPuSMVXXjhdriCMzrilDB6TEUExTC7V; Received: from box313.bluehost.com ([69.89.31.113]:52519 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKU0t-0002s5-Pq; Thu, 21 Aug 2014 09:10:55 -0600 Message-ID: <53F60C4E.60607@labn.net> Date: Thu, 21 Aug 2014 11:12:14 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas , Sandra Murphy References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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/qV-mzexf72kKmFrNkPI-IoaqPqA Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:11:09 -0000 Okay, then why not wait for assignment until there is a WG -00 draft? This way we avoid wasting reviewer resources on rejected documents. Also, wither way the next step should be added as a 4. to the "detailed process". Thanks, Lou On 8/21/2014 10:52 AM, Alia Atlas wrote: > Sandy, > > Exactly so. :-) > > Alia > > > On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy > wrote: > > I read through the process again and to me it seems clear that it > does not. > > "Any issues the QA Reviewer finds are written down, sent to the > mailing list and discussed for future versions, but need not gate > the progress of the draft in the WG" > > I'd be interested to see how others interpret the process. > > --Sandy > > On Aug 21, 2014, at 10:11 AM, Lou Berger > wrote: > > > Alia, > > I'm unclear on one point: Is it your intent for the quality > review > > to gate WG acceptance? > > > > Lou > > > > On 8/20/2014 10:45 AM, Alia Atlas wrote: > >> Hi to all the Routing Area WG Chairs and Secretaries, > >> > >> As Adrian and I discussed prior to IETF 90 and in the Routing Area > >> meeting at IETF 90, > >> we would like to start using the new Draft Quality Assurance > process > >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) > for all > >> drafts that are being > >> considered for WG adoption. Drafts that are already WG drafts > do not > >> need to go through this process - but chairs can ask if it seems > >> desirable. > >> > >> As with many processes in the IETF, this process is intended to be > >> used for the spirit of the goal, subject to common-sense and > technical > >> perspective. In particular, none of this process is intended to > gate > >> or otherwise impede the normal progression of documents through > IETF > >> working groups: rather, it is intended to provide additional input, > >> review, and comments that the working groups can use to help > improve > >> the quality of their documents, and to help chairs determine > quality > >> and consensus for documents. We do not expect IETF process to > wait for > >> reviews to happen. > >> > >> As described on the wiki page, the detailed process is: > >> > >> 1. The WG Chair or Secretary emails the Routing Directorate > >> Coordinators ( Deborah Brungard > >> >) and Jonathan Hardwick >> at metaswitch.com > >). The subject should > >> be WG Draft QA Requested: >> >. > >> > >> 2. The WG Chair or Secretary marks a draft in the datatracker as > >> "Candidate for Adoption" and specifies the date on which WG > Draft > >> QA was requested. > >> > >> 3. The Routing Directorate Coordinators and WG Chairs agree and > find > >> a QA Reviewer. The review can be done during the WG Call for > >> Adoption. The WG Chair or Secretary adds a comment in the > draft's > >> datatracker history page indicating whom is the QA Reviewer. > >> > >> Please start doing this now. > >> > >> After IETF-91, we can discuss how this is going and its usefulness. > >> > >> Thanks, > >> Alia > > > > From nobody Thu Aug 21 08: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 9C0B01A03B5; Thu, 21 Aug 2014 08:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 kqvacEFRdKqF; Thu, 21 Aug 2014 08:17:15 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709381A02ED; Thu, 21 Aug 2014 08:17:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3676; q=dns/txt; s=iport; t=1408634235; x=1409843835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=afsgHgpjSa9YZgVX3Ww6oq2BSER1k36i8ZIrOPBFn9E=; b=eifk9xSPvY+xYQi9N5ySEB9evl/GIJJcaBJRKiBSWqH7vYQJ2Sx8SQzv q91UtXNDVB8MqU6UAD34BIQ2P92e3CKqJvyJakjQ4UyEVP4ZSUk9Z3kGZ /5q72FhgnXD2thiSjwkpZZVvXzrSGr3jCNiEQaGxvWZ0lQ2aROUoi+vZo 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAGYM9lOtJV2a/2dsb2JhbABagw1TVwTMTIdZAYEOFneEAwEBAQMBHR00CwULAgEIDgoeCQcyFBECBA4FiDoIDcMAF49MB4MvgR0FkSWEKYZ5gVeTM4NebAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.01,909,1400025600"; d="scan'208";a="71213035" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 21 Aug 2014 15:17:14 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7LFHEpP006975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 15:17:14 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 10:17:13 -0500 From: "Acee Lindem (acee)" To: Lou Berger Thread-Topic: [RTG-DIR] Please start using the Document QA process now Thread-Index: AQHPvUmyeryJcU2XPEe55SJW3hap3pvbd7oAgAAAgwCAAAWUAIAAAWYA Date: Thu, 21 Aug 2014 15:17:13 +0000 Message-ID: <1CB303B2-45A6-463A-82D3-A8A1A4CA64E6@cisco.com> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> In-Reply-To: <53F60C4E.60607@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <3F07FF718614344C8EFF2ABEB72E50B9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/04O_OkGQILXLiJH0gTl3WeYd58w Cc: "rtg-dir@ietf.org" , Sandra Murphy , "rtg-chairs@ietf.org" , Alia Atlas Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:17:17 -0000 I agree.=20 Acee=20 On Aug 21, 2014, at 11:12 AM, Lou Berger wrote: > Okay, then why not wait for assignment until there is a WG -00 draft?=20 > This way we avoid wasting reviewer resources on rejected documents. >=20 > Also, wither way the next step should be added as a 4. to the "detailed > process". >=20 > Thanks, > Lou > On 8/21/2014 10:52 AM, Alia Atlas wrote: >> Sandy, >>=20 >> Exactly so. :-) >>=20 >> Alia >>=20 >>=20 >> On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy > > wrote: >>=20 >> I read through the process again and to me it seems clear that it >> does not. >>=20 >> "Any issues the QA Reviewer finds are written down, sent to the >> mailing list and discussed for future versions, but need not gate >> the progress of the draft in the WG" >>=20 >> I'd be interested to see how others interpret the process. >>=20 >> --Sandy >>=20 >> On Aug 21, 2014, at 10:11 AM, Lou Berger > > wrote: >>=20 >>> Alia, >>> I'm unclear on one point: Is it your intent for the quality >> review >>> to gate WG acceptance? >>>=20 >>> Lou >>>=20 >>> On 8/20/2014 10:45 AM, Alia Atlas wrote: >>>> Hi to all the Routing Area WG Chairs and Secretaries, >>>>=20 >>>> As Adrian and I discussed prior to IETF 90 and in the Routing Area >>>> meeting at IETF 90, >>>> we would like to start using the new Draft Quality Assurance >> process >>>> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) >> for all >>>> drafts that are being >>>> considered for WG adoption. Drafts that are already WG drafts >> do not >>>> need to go through this process - but chairs can ask if it seems >>>> desirable. >>>>=20 >>>> As with many processes in the IETF, this process is intended to be >>>> used for the spirit of the goal, subject to common-sense and >> technical >>>> perspective. In particular, none of this process is intended to >> gate >>>> or otherwise impede the normal progression of documents through >> IETF >>>> working groups: rather, it is intended to provide additional input, >>>> review, and comments that the working groups can use to help >> improve >>>> the quality of their documents, and to help chairs determine >> quality >>>> and consensus for documents. We do not expect IETF process to >> wait for >>>> reviews to happen. >>>>=20 >>>> As described on the wiki page, the detailed process is: >>>>=20 >>>> 1. The WG Chair or Secretary emails the Routing Directorate >>>> Coordinators ( Deborah Brungard > >>>> >) and Jonathan Hardwick >>> at metaswitch.com >> >). The subject should >>>> be WG Draft QA Requested: >>> >. >>>>=20 >>>> 2. The WG Chair or Secretary marks a draft in the datatracker as >>>> "Candidate for Adoption" and specifies the date on which WG >> Draft >>>> QA was requested. >>>>=20 >>>> 3. The Routing Directorate Coordinators and WG Chairs agree and >> find >>>> a QA Reviewer. The review can be done during the WG Call for >>>> Adoption. The WG Chair or Secretary adds a comment in the >> draft's >>>> datatracker history page indicating whom is the QA Reviewer. >>>>=20 >>>> Please start doing this now. >>>>=20 >>>> After IETF-91, we can discuss how this is going and its usefulness. >>>>=20 >>>> Thanks, >>>> Alia >>>=20 >>=20 >>=20 >=20 From nobody Thu Aug 21 08:22: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 574C91A6FC8; Thu, 21 Aug 2014 08:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij4bJ-3TgOs2; Thu, 21 Aug 2014 08:22:01 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51DE1A6F3E; Thu, 21 Aug 2014 08:22:00 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id v1so8285594yhn.13 for ; Thu, 21 Aug 2014 08:22: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=vmGDoMi+89frgiTItaLYLtXlXYQPWam3OxXw/J7ctWM=; b=iJIfZPBa3CfAnaCMOO5MuJrSY4i6fdrqY56JumV5yQzR79IpF+Hrs2NG5Iycd5v22i CaecB4FrN1nAFhj09bSmseC5TjvacGpKF192yGcA8iv0fl9iMtiPUiQXVMhsaSfcFPm2 DOdwfpYHQB+u0HADcmhvWO58dHLVL9ZkeBIcJCmddiuXPy+A2JrEDpgybOFiTrifoWhh B8LMokEbPjLSMlOdGaWLv5N1KaZt4A8rKWSexB2HYAL6QQAnHMU39uR6AaEeXPh5NNEt NN80F1KzC5EMmNmKm/Ti/n2bwj++rHmmtup9pHBAFGggwmbr5qgu1+m0qNYvNYDSXjtM YJbA== MIME-Version: 1.0 X-Received: by 10.236.164.70 with SMTP id b46mr82564183yhl.16.1408634520246; Thu, 21 Aug 2014 08:22:00 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Thu, 21 Aug 2014 08:22:00 -0700 (PDT) In-Reply-To: <53F60C4E.60607@labn.net> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> Date: Thu, 21 Aug 2014 11:22:00 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=20cf30434c58329ffe0501254854 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/f1h67udnq-GiApEZOp-BypL4bEw Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Sandra Murphy Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:22:03 -0000 --20cf30434c58329ffe0501254854 Content-Type: text/plain; charset=UTF-8 Lou, On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger wrote: > Okay, then why not wait for assignment until there is a WG -00 draft? > This way we avoid wasting reviewer resources on rejected documents. > The QA reviewer's review isn't given special consideration to block WG adoption BUT it is intended to be useful input to the WG decision about whether to adopt the WG-00 draft. To be blunt, it can be another tool to demonstrate lack of consensus or that a draft is a bad idea before the draft is actually adopted by the WG. As for avoiding wasting reviewer resources, the gate there is that the WG chairs believe the draft should be up for WG adoption. I would hope that is a sufficient gate. > Also, wither way the next step should be added as a 4. to the "detailed > process". > Can you clarify? I.e. suggest words - and it is a wiki - feel free to add a bit of text with context such as [NOTE: 4. blah blah (suggested by Lou Berger)] Thanks, Alia > > Thanks, > Lou > On 8/21/2014 10:52 AM, Alia Atlas wrote: > > Sandy, > > > > Exactly so. :-) > > > > Alia > > > > > > On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy > > wrote: > > > > I read through the process again and to me it seems clear that it > > does not. > > > > "Any issues the QA Reviewer finds are written down, sent to the > > mailing list and discussed for future versions, but need not gate > > the progress of the draft in the WG" > > > > I'd be interested to see how others interpret the process. > > > > --Sandy > > > > On Aug 21, 2014, at 10:11 AM, Lou Berger > > wrote: > > > > > Alia, > > > I'm unclear on one point: Is it your intent for the quality > > review > > > to gate WG acceptance? > > > > > > Lou > > > > > > On 8/20/2014 10:45 AM, Alia Atlas wrote: > > >> Hi to all the Routing Area WG Chairs and Secretaries, > > >> > > >> As Adrian and I discussed prior to IETF 90 and in the Routing Area > > >> meeting at IETF 90, > > >> we would like to start using the new Draft Quality Assurance > > process > > >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) > > for all > > >> drafts that are being > > >> considered for WG adoption. Drafts that are already WG drafts > > do not > > >> need to go through this process - but chairs can ask if it seems > > >> desirable. > > >> > > >> As with many processes in the IETF, this process is intended to be > > >> used for the spirit of the goal, subject to common-sense and > > technical > > >> perspective. In particular, none of this process is intended to > > gate > > >> or otherwise impede the normal progression of documents through > > IETF > > >> working groups: rather, it is intended to provide additional > input, > > >> review, and comments that the working groups can use to help > > improve > > >> the quality of their documents, and to help chairs determine > > quality > > >> and consensus for documents. We do not expect IETF process to > > wait for > > >> reviews to happen. > > >> > > >> As described on the wiki page, the detailed process is: > > >> > > >> 1. The WG Chair or Secretary emails the Routing Directorate > > >> Coordinators ( Deborah Brungard > > > >> >) and Jonathan Hardwick > >> at metaswitch.com > > >). The subject should > > >> be WG Draft QA Requested: > >> >. > > >> > > >> 2. The WG Chair or Secretary marks a draft in the datatracker as > > >> "Candidate for Adoption" and specifies the date on which WG > > Draft > > >> QA was requested. > > >> > > >> 3. The Routing Directorate Coordinators and WG Chairs agree and > > find > > >> a QA Reviewer. The review can be done during the WG Call for > > >> Adoption. The WG Chair or Secretary adds a comment in the > > draft's > > >> datatracker history page indicating whom is the QA Reviewer. > > >> > > >> Please start doing this now. > > >> > > >> After IETF-91, we can discuss how this is going and its > usefulness. > > >> > > >> Thanks, > > >> Alia > > > > > > > > > --20cf30434c58329ffe0501254854 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,

On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger <lberger@labn= .net> wrote:
Okay, then why not wait for assignment until= there is a WG -00 draft?
This way we avoid wasting reviewer resources on rejected documents.

The QA reviewer's review isn't given s= pecial consideration to block WG adoption
BUT it is intended to b= e useful input to the WG decision about whether to adopt
the WG-00 draft.

To be blunt, it can be anoth= er tool to demonstrate lack of consensus or that a draft
is a bad= idea before the draft is actually adopted by the WG.

As for avoiding wasting reviewer resources, the gate there is that the= WG chairs
believe the draft should be up for WG adoption. =C2=A0= I would hope that is a sufficient gate.
=C2=A0
Also, wither way the next step should be added as a 4. to the "detaile= d
process".

Can you clarify? =C2=A0I= .e. suggest words =C2=A0- and it is a wiki - feel free to add a bit of text=
with context =C2=A0such as [NOTE: 4. blah blah (suggested by Lou= Berger)]

Thanks,
Alia
=C2=A0

Thanks,
Lou
On 8/21/2014 10:52 AM, Alia Atlas wrote:
> Sandy,
>
> Exactly so.=C2=A0 =C2=A0 :-)
>
> Alia
>
>
> On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy <sandy@tislabs.com
> <mailto:sandy@tislabs.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I read through the process again and to me it seems= clear that it
>=C2=A0 =C2=A0 =C2=A0does not.
>
>=C2=A0 =C2=A0 =C2=A0"Any issues the QA Reviewer finds are written = down, sent to the
>=C2=A0 =C2=A0 =C2=A0mailing list and discussed for future versions, but= need not gate
>=C2=A0 =C2=A0 =C2=A0the progress of the draft in the WG"
>
>=C2=A0 =C2=A0 =C2=A0I'd be interested to see how others interpret t= he process.
>
>=C2=A0 =C2=A0 =C2=A0--Sandy
>
>=C2=A0 =C2=A0 =C2=A0On Aug 21, 2014, at 10:11 AM, Lou Berger <lberger@labn.net
>=C2=A0 =C2=A0 =C2=A0<m= ailto:lberger@labn.net>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0> Alia,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 I'm unclear on one point: Is = it your intent for the quality
>=C2=A0 =C2=A0 =C2=A0review
>=C2=A0 =C2=A0 =C2=A0> to gate WG acceptance?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Lou
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On 8/20/2014 10:45 AM, Alia Atlas wrote:
>=C2=A0 =C2=A0 =C2=A0>> Hi to all the Routing=C2=A0 Area WG Chairs= and Secretaries,
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> As Adrian and I discussed prior to IETF 90= and in the Routing Area
>=C2=A0 =C2=A0 =C2=A0>> meeting at IETF 90,
>=C2=A0 =C2=A0 =C2=A0>> we would like to start using the new Draft= Quality Assurance
>=C2=A0 =C2=A0 =C2=A0process
>=C2=A0 =C2=A0 =C2=A0>> ( http://wiki.tools.ietf.org/= area/rtg/trac/wiki/RtgDirDocQa )
>=C2=A0 =C2=A0 =C2=A0for all
>=C2=A0 =C2=A0 =C2=A0>> drafts that are being
>=C2=A0 =C2=A0 =C2=A0>> considered for WG adoption.=C2=A0 =C2=A0Dr= afts that are already WG drafts
>=C2=A0 =C2=A0 =C2=A0do not
>=C2=A0 =C2=A0 =C2=A0>> need to go through this process - but chai= rs can ask if it seems
>=C2=A0 =C2=A0 =C2=A0>> desirable.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> As with many processes in the IETF, this p= rocess is intended to be
>=C2=A0 =C2=A0 =C2=A0>> used for the spirit of the goal, subject t= o common-sense and
>=C2=A0 =C2=A0 =C2=A0technical
>=C2=A0 =C2=A0 =C2=A0>> perspective. In particular, none of this p= rocess is intended to
>=C2=A0 =C2=A0 =C2=A0gate
>=C2=A0 =C2=A0 =C2=A0>> or otherwise impede the normal progression= of documents through
>=C2=A0 =C2=A0 =C2=A0IETF
>=C2=A0 =C2=A0 =C2=A0>> working groups: rather, it is intended to = provide additional input,
>=C2=A0 =C2=A0 =C2=A0>> review, and comments that the working grou= ps can use to help
>=C2=A0 =C2=A0 =C2=A0improve
>=C2=A0 =C2=A0 =C2=A0>> the quality of their documents, and to hel= p chairs determine
>=C2=A0 =C2=A0 =C2=A0quality
>=C2=A0 =C2=A0 =C2=A0>> and consensus for documents. We do not exp= ect IETF process to
>=C2=A0 =C2=A0 =C2=A0wait for
>=C2=A0 =C2=A0 =C2=A0>> reviews to happen.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> As described on the wiki page, the detaile= d process is:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 1. The WG Chair or Secretary emails the Ro= uting Directorate
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Coordinators ( Deborah Brunga= rd <db3546 at att.com >=C2=A0 =C2=A0 =C2=A0<ht= tp://att.com>
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 <http://att.com/>>) and Jonathan Hardwick <= ;jonathan.hardwick
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 at metaswitch.com <http://metaswitch.com>
>=C2=A0 =C2=A0 =C2=A0<http://metaswitch.com/>>). The subject should
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 be WG Draft QA Requested: <= ;draft-name
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 <http://tools.ietf.org/html/draft= -name>>.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 2. The WG Chair or Secretary marks a draft= in the datatracker as
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 "Candidate for Adoption&= quot; and specifies the date on which WG
>=C2=A0 =C2=A0 =C2=A0Draft
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 QA was requested.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> 3. The Routing Directorate Coordinators an= d WG Chairs agree and
>=C2=A0 =C2=A0 =C2=A0find
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 a QA Reviewer. The review can= be done during the WG Call for
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Adoption. The WG Chair or Sec= retary adds a comment in the
>=C2=A0 =C2=A0 =C2=A0draft's
>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 datatracker history page indi= cating whom is the QA Reviewer.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Please start doing this now.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> After IETF-91, we can discuss how this is = going and its usefulness.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Thanks,
>=C2=A0 =C2=A0 =C2=A0>> Alia
>=C2=A0 =C2=A0 =C2=A0>
>
>


--20cf30434c58329ffe0501254854-- From nobody Thu Aug 21 08:33: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 68E0F1A03D9; Thu, 21 Aug 2014 08:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, 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 X79xxd8Rk8-n; Thu, 21 Aug 2014 08:33:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2011A03B5; Thu, 21 Aug 2014 08:33:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 47DB8C27E; Thu, 21 Aug 2014 11:33:56 -0400 (EDT) Date: Thu, 21 Aug 2014 11:33:56 -0400 From: Jeffrey Haas To: Christian Hopps Message-ID: <20140821153356.GL30106@pfrc> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/EVNJ0LLg6PNymBGuBd_AyysUpQU Cc: Sandra Murphy , "rtg-dir@ietf.org" , Lou Berger , "rtg-chairs@ietf.org" , Alia Atlas Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:33:58 -0000 On Thu, Aug 21, 2014 at 11:29:08AM -0400, Christian Hopps wrote: > On Aug 21, 2014, at 11:12 AM, Lou Berger wrote: > > > Okay, then why not wait for assignment until there is a WG -00 draft? > > This way we avoid wasting reviewer resources on rejected documents. > > Yeah, I thought it was an odd ordering as well. There are competing goals here and I think that's part of the problem. 1. We want a document that "is a WG document" to clear quality issues as soon as possible. See the justifications in the wiki. 2. Documents that are of interesting technical content but have other issues are difficult to read and review and those issues serve as a impediment to discussion of the draft pre-adoption-call. I believe we are talking about solving the first issue. -- Jeff From nobody Thu Aug 21 08:39: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 D5B551A0203; Thu, 21 Aug 2014 08:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jsphX715vQLA; Thu, 21 Aug 2014 08:39:17 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0019.outbound.protection.outlook.com [213.199.154.19]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12751A0144; Thu, 21 Aug 2014 08:39:16 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Thu, 21 Aug 2014 15:39:14 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1010.016; Thu, 21 Aug 2014 15:39:14 +0000 From: Alexander Vainshtein To: Jeffrey Haas Thread-Topic: [RTG-DIR] Please start using the Document QA process now Thread-Index: AQHPvIVzIcIW9iqMuEO18Y4aSTFod5vbGocAgAALwGWAAAVBAIAABhxYgAAASXA= Date: Thu, 21 Aug 2014 15:39:14 +0000 Message-ID: <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> In-Reply-To: <20140821153356.GL30106@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.56.21] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(252514010)(51704005)(24454002)(189002)(31014004)(377454003)(13464003)(108616004)(110136001)(19580395003)(33646002)(83072002)(19580405001)(83322001)(85852003)(4396001)(105586002)(87936001)(92566001)(106356001)(106116001)(86362001)(74662001)(31966008)(107046002)(74502001)(81342001)(95666004)(85306004)(21056001)(93886004)(76482001)(77982001)(81542001)(79102001)(101416001)(66066001)(80022001)(64706001)(2656002)(20776003)(74316001)(99396002)(54356999)(50986999)(76176999)(76576001)(46102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ZflHw-KdEu4nIHYrXAPhKhu2woc Cc: "rtg-dir@ietf.org" , Christian Hopps , Sandra Murphy , Alia Atlas , "rtg-chairs@ietf.org" , Lou Berger Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:39:20 -0000 Jeffrey, A na=EFve question:=20 If a document is "difficult to read and review" (no matter at what stage), = how can the WG understand/reach consensus that it is "of interesting tech= nical content "?=20 Or did I misread something in your mail? Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Thursday, August 21, 2014 6:34 PM > To: Christian Hopps > Cc: Sandra Murphy; rtg-dir@ietf.org; Lou Berger; rtg-chairs@ietf.org; Ali= a > Atlas > Subject: Re: [RTG-DIR] Please start using the Document QA process now >=20 > On Thu, Aug 21, 2014 at 11:29:08AM -0400, Christian Hopps wrote: > > On Aug 21, 2014, at 11:12 AM, Lou Berger wrote: > > > > > Okay, then why not wait for assignment until there is a WG -00 draft? > > > This way we avoid wasting reviewer resources on rejected documents. > > > > Yeah, I thought it was an odd ordering as well. >=20 > There are competing goals here and I think that's part of the problem. >=20 > 1. We want a document that "is a WG document" to clear quality issues as > soon as possible. See the justifications in the wiki. >=20 > 2. Documents that are of interesting technical content but have other iss= ues > are difficult to read and review and those issues serve as a impediment t= o > discussion of the draft pre-adoption-call. >=20 > I believe we are talking about solving the first issue. >=20 > -- Jeff From nobody Thu Aug 21 08:54: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 65CB71A019B; Thu, 21 Aug 2014 08:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbLPoS8WYMfp; Thu, 21 Aug 2014 08:54:02 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD481A037E; Thu, 21 Aug 2014 08:54:01 -0700 (PDT) Received: from CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) by CO2PR05MB651.namprd05.prod.outlook.com (10.141.199.155) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 21 Aug 2014 15:53:59 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB634.namprd05.prod.outlook.com (10.141.199.17) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Thu, 21 Aug 2014 15:53:57 +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.1010.016; Thu, 21 Aug 2014 15:53:57 +0000 From: Ross Callon To: Alexander Vainshtein , Jeffrey Haas Thread-Topic: [RTG-DIR] Please start using the Document QA process now Thread-Index: AQHPvVI4oq1ALJ8aOUOJhWREtZiSzpvbLqcAgAABWACAAAF7AIAAAHyA Date: Thu, 21 Aug 2014 15:53:57 +0000 Message-ID: <3efca289e0964654bc999900a42cb22b@CO2PR05MB636.namprd05.prod.outlook.com> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> In-Reply-To: <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.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.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(51704005)(31014004)(377454003)(199003)(24454002)(13464003)(189002)(252514010)(92566001)(99286002)(83072002)(85852003)(19580395003)(76482001)(74662001)(106116001)(2656002)(74502001)(105586002)(95666004)(87936001)(86362001)(4396001)(19580405001)(83322001)(106356001)(33646002)(54356999)(31966008)(50986999)(81342001)(80022001)(76176999)(93886004)(101416001)(76576001)(79102001)(66066001)(74316001)(20776003)(107046002)(46102001)(81542001)(99396002)(77982001)(108616004)(21056001)(64706001)(85306004)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO2PR05MB634; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Lx6Do-ue6lE2sBVOFrlSAi1zCNE Cc: "rtg-dir@ietf.org" , Christian Hopps , Sandra Murphy , Alia Atlas , "rtg-chairs@ietf.org" , Lou Berger Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:54:06 -0000 Two points: Yes, if a document is difficult to read and review, then we should expect t= hat the WG will either have trouble coming to consensus that it is of inter= esting and valuable technical content, or should decide that it is not read= y to be adopted. This is part of the reason that the MPLS WG has its review= team look at documents prior to the call for adoption.=20 I have come up with a different way to look at the routing area QA review: = Looking at the IETF process as it has existed for many years, when a docume= nt is called for WG adoption, we as co-chairs might *hope* that multiple ex= perienced WG participants who have a clue about the technology will read th= e document, evaluate whether it makes sense, and send their opinions, comme= nts, and observations to the WG email list. This might in some cases be sho= rt and sweet ("IMHO the document is ready to be adopted as a WG item" or "I= MHO this document is a really bad idea"). This might in some cases include = detailed comments that should be used to update the document, either before= or after adoption. Perhaps the routing area QA review might end up being l= ittle more than a way to get at least one experienced knowledgeable person = to promise that they will indeed do precisely this review during the call f= or adoption. If we think of the review this way, then it does not actually = add delay or more process to the existing IETF process, but it just makes i= t more likely that for each document at least some portion of our experts w= ill actually do what we already want them to do.=20 Ross -----Original Message----- From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Alexander Vain= shtein Sent: Thursday, August 21, 2014 11:39 AM To: Jeffrey Haas Cc: rtg-dir@ietf.org; Christian Hopps; Sandra Murphy; Alia Atlas; rtg-chair= s@ietf.org; Lou Berger Subject: Re: [RTG-DIR] Please start using the Document QA process now Jeffrey, A na=EFve question:=20 If a document is "difficult to read and review" (no matter at what stage), = how can the WG understand/reach consensus that it is "of interesting tech= nical content "?=20 Or did I misread something in your mail? Regards, Sasha=20 Email: Alexander.Vainshtein@ecitele.com Mobile: 054-9266302 > -----Original Message----- > From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Thursday, August 21, 2014 6:34 PM > To: Christian Hopps > Cc: Sandra Murphy; rtg-dir@ietf.org; Lou Berger; rtg-chairs@ietf.org; Ali= a > Atlas > Subject: Re: [RTG-DIR] Please start using the Document QA process now >=20 > On Thu, Aug 21, 2014 at 11:29:08AM -0400, Christian Hopps wrote: > > On Aug 21, 2014, at 11:12 AM, Lou Berger wrote: > > > > > Okay, then why not wait for assignment until there is a WG -00 draft? > > > This way we avoid wasting reviewer resources on rejected documents. > > > > Yeah, I thought it was an odd ordering as well. >=20 > There are competing goals here and I think that's part of the problem. >=20 > 1. We want a document that "is a WG document" to clear quality issues as > soon as possible. See the justifications in the wiki. >=20 > 2. Documents that are of interesting technical content but have other iss= ues > are difficult to read and review and those issues serve as a impediment t= o > discussion of the draft pre-adoption-call. >=20 > I believe we are talking about solving the first issue. >=20 > -- Jeff From nobody Thu Aug 21 09:07:11 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 1CF7E1A8749; Thu, 21 Aug 2014 07:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 0z5L5836m60F; Thu, 21 Aug 2014 07:50:28 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2A51A03AE; Thu, 21 Aug 2014 07:50:28 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3EDF828B0017; Thu, 21 Aug 2014 10:50:27 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id D633A1F8032; Thu, 21 Aug 2014 10:50:26 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_60D9F696-46CF-4EAE-B8BF-B4D019B4CEBC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <53F5FE0A.4080205@labn.net> Date: Thu, 21 Aug 2014 10:50:26 -0400 Message-Id: <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> References: <53F5FE0A.4080205@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/dGtvykuXY7NjFVzwCxv0nm9Mfkw X-Mailman-Approved-At: Thu, 21 Aug 2014 09:07:09 -0700 Cc: "rtg-dir@ietf.org" , Alia Atlas , "rtg-chairs@ietf.org" , Sandra Murphy Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 14:50:37 -0000 --Apple-Mail=_60D9F696-46CF-4EAE-B8BF-B4D019B4CEBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I read through the process again and to me it seems clear that it does = not. "Any issues the QA Reviewer finds are written down, sent to the mailing = list and discussed for future versions, but need not gate the progress = of the draft in the WG" I'd be interested to see how others interpret the process. --Sandy On Aug 21, 2014, at 10:11 AM, Lou Berger wrote: > Alia, > I'm unclear on one point: Is it your intent for the quality review > to gate WG acceptance? >=20 > Lou >=20 > On 8/20/2014 10:45 AM, Alia Atlas wrote: >> Hi to all the Routing Area WG Chairs and Secretaries, >>=20 >> As Adrian and I discussed prior to IETF 90 and in the Routing Area >> meeting at IETF 90, >> we would like to start using the new Draft Quality Assurance process >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) for all >> drafts that are being >> considered for WG adoption. Drafts that are already WG drafts do = not >> need to go through this process - but chairs can ask if it seems >> desirable. >>=20 >> As with many processes in the IETF, this process is intended to be >> used for the spirit of the goal, subject to common-sense and = technical >> perspective. In particular, none of this process is intended to gate >> or otherwise impede the normal progression of documents through IETF >> working groups: rather, it is intended to provide additional input, >> review, and comments that the working groups can use to help improve >> the quality of their documents, and to help chairs determine quality >> and consensus for documents. We do not expect IETF process to wait = for >> reviews to happen. >>=20 >> As described on the wiki page, the detailed process is: >>=20 >> 1. The WG Chair or Secretary emails the Routing Directorate >> Coordinators ( Deborah Brungard > >) and Jonathan Hardwick > at metaswitch.com >). The subject should >> be WG Draft QA Requested: > >. >>=20 >> 2. The WG Chair or Secretary marks a draft in the datatracker as >> "Candidate for Adoption" and specifies the date on which WG Draft >> QA was requested. >>=20 >> 3. The Routing Directorate Coordinators and WG Chairs agree and find >> a QA Reviewer. The review can be done during the WG Call for >> Adoption. The WG Chair or Secretary adds a comment in the draft's >> datatracker history page indicating whom is the QA Reviewer. >>=20 >> Please start doing this now. =20 >>=20 >> After IETF-91, we can discuss how this is going and its usefulness. >>=20 >> Thanks, >> Alia >=20 --Apple-Mail=_60D9F696-46CF-4EAE-B8BF-B4D019B4CEBC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJT9gcyAAoJEHplpQeet0IZH1kP/3xB0bZW3IBb5aNyGUGPOL6w OcTjvPA3RpLJU+EV/SUD7JOjI6n82jL4P50Vnp1GsbcDunQSVkgeyafLmx75DZsd bu8yLsVE/Y638in5jjxNs5/diRNK0Cj+kaoIzVAQTCPqeHaNwoOxHAIuFVr7oMC6 cwkZb0F9TcM/N3Ka29E1CvsKmS0E/mfcCS1oDWG91yt34FGo6/g5Lu0uXTnnpha3 gcaIr9PqehD8SGvvrcP5d7HmHH/di35TwMHLc3M31vxj/90BvyuRb1Tk1NFWXe17 lvstnLjuxDomON+N+7wFLPDKdiXHnHPBq/SdNREpR0Kjdst0G7KuuEgriV/5robP qlAjEcrZEeOttzFJ3SlLWpFJ+B/pJj5ML7OqCPlAYtmwIMukTUkj8stJWbXIHQmG +oUBzltiWY3KojKdh9IIINNmPFDCiMJjz+R5Ot91IuCfUjsJM+XHm8bZ40kdPqpm fPdBs+yGPF52ZRAAufQ6rpFNqtSKpG7LOJ818n+bta/gEa5ZjUFeRUO+SZG8Fduo ymMzch+QEymR1evSYIF3sHbmetABQgUCk4kRQhiqUsLxJ2RKb6Gp5tg363Kzf/9X 2Y/tBCAGsCAWAd+6wp1GJwxJR0gE3pI1yFxOj0l5A1X1OUto22XXeLBRVgY/8MXp iIVGN3bhhfA+Ev4eiHtA =pSyA -----END PGP SIGNATURE----- --Apple-Mail=_60D9F696-46CF-4EAE-B8BF-B4D019B4CEBC-- From nobody Thu Aug 21 09:07: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 996461A03F0 for ; Thu, 21 Aug 2014 08:29:13 -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, 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 7PoiR5O3VCEJ for ; Thu, 21 Aug 2014 08:29:12 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183B21A03D9 for ; Thu, 21 Aug 2014 08:29:12 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id fp1so14051742pdb.5 for ; Thu, 21 Aug 2014 08:29:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=dtORO+UyyXPb6McsL1s9L3OrIsQ70mDZ47ZhedDlx0I=; b=LHEbDblhws3uyrSxa4GMvnKY2LBvq3qk5l2nYyQdOfMSr/VBGFu/Wy2WirBNBM3Tor hnmwhmbhNG2IOTvk3j+a7x86A1VA3xKy0r2/Hz5a/CG+wI7s7QiPPuFiJx1654Jhq3tg 0t4lNOo4q2xLzxdU/twj5HFjjZ2pjKl7D5/kvc4zYYXonKDf3WmpuqkF5SqYUNmAqXSg DhudYLFppJ+5cVKMstftCYfemVXrvVUpLNtjmDroo/1trMfgEXI9+ugoaDtWTOVWrrCc hDjw0uZq4Lj9B0Xq9NoqjDCCMImoHphB1e9ZvmzXe3VeaS1tsy7lD7aGItLjB+lOKHk/ fntw== X-Gm-Message-State: ALoCoQmXKoSMOBgkJOpVEger1QZwKrDf+BZS2Y4wDqpjs5fLkA5Wvbk3cqEjqC/WS2NW+jpceB6Y X-Received: by 10.70.42.10 with SMTP id j10mr4468517pdl.1.1408634951681; Thu, 21 Aug 2014 08:29:11 -0700 (PDT) Received: from [192.168.1.3] (c-71-227-97-41.hsd1.mi.comcast.net. [71.227.97.41]) by mx.google.com with ESMTPSA id kb12sm25832002pbd.80.2014.08.21.08.29.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 08:29:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Christian Hopps In-Reply-To: <53F60C4E.60607@labn.net> Date: Thu, 21 Aug 2014 11:29:08 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Ge_7-W9f-WXhgArozkhhhwVedew X-Mailman-Approved-At: Thu, 21 Aug 2014 09:07:09 -0700 Cc: "rtg-dir@ietf.org" , Sandra Murphy , Christian Hopps , "rtg-chairs@ietf.org" , Alia Atlas Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:29:13 -0000 On Aug 21, 2014, at 11:12 AM, Lou Berger wrote: > Okay, then why not wait for assignment until there is a WG -00 draft? > This way we avoid wasting reviewer resources on rejected documents. Yeah, I thought it was an odd ordering as well. Thanks, Chris. > > Also, wither way the next step should be added as a 4. to the "detailed > process". > > Thanks, > Lou From nobody Thu Aug 21 09:07: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 5478A1A03FE for ; Thu, 21 Aug 2014 08:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gFc5ky5xbU7D for ; Thu, 21 Aug 2014 08:37:35 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057D31A03F0 for ; Thu, 21 Aug 2014 08:37:34 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id y10so14033676pdj.7 for ; Thu, 21 Aug 2014 08:37:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=y5y1wjy0oYY05LY2yThjSKr5rCYjotrY5wzRkl3A3JU=; b=fVy3BHpN0YtMMG9fGdK0OnApZ6VM+LrBAZn7G1mQP1zUZ+Tf5Eh0WH8idODUG6nBxI AB1AbYluTMu/vwglIV2oxfarHrgGOspZ5NloFSk6s+njPsJOUcbb5PklPR+omvTD9im4 XfmOsPQyOcLvzJR3c/HSIT70sf2wJYQuYlBYc/Pr7suTnMxkNTPRhY7X/MED7eZK8OaU sHXR1rtzWrXFkYIO+WM2SxFeURMe44MIcyrAw1qANO1W5tCjZGG9MjVXJ2AE1FFJgSmj qs+/iMawv3W1ASqWSjNRa7ObF4Sf9/PNuxrPrCBI39df9CNcvwPRpQ8DetiBl4V7lXjm 8Biw== X-Gm-Message-State: ALoCoQm6eJXlr4ablRLYom4Apv2hJRV30RmmS4Ikltazbb5B4K4JoahSvRMIpx0Skz8d+VVLsbED X-Received: by 10.70.133.136 with SMTP id pc8mr30830145pdb.0.1408635454636; Thu, 21 Aug 2014 08:37:34 -0700 (PDT) Received: from [192.168.1.3] (c-71-227-97-41.hsd1.mi.comcast.net. [71.227.97.41]) by mx.google.com with ESMTPSA id oe10sm25869327pbc.3.2014.08.21.08.37.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 08:37:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7B0CD68C-FB6A-4631-830D-C34A0AB032B0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Christian Hopps In-Reply-To: Date: Thu, 21 Aug 2014 11:37:31 -0400 Message-Id: <897BFA2C-0BEA-4A00-B0C6-0FFFEB8B5008@rawdofmt.org> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> To: Alia Atlas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/lGH5SSFQ7gtkh0sEBbZXvTzlqFg X-Mailman-Approved-At: Thu, 21 Aug 2014 09:07:09 -0700 Cc: "rtg-dir@ietf.org" , Lou Berger , Christian Hopps , "rtg-chairs@ietf.org" , Sandra Murphy Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 15:37:37 -0000 --Apple-Mail=_7B0CD68C-FB6A-4631-830D-C34A0AB032B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 21, 2014, at 11:22 AM, Alia Atlas wrote: > Lou, >=20 > On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger wrote: > Okay, then why not wait for assignment until there is a WG -00 draft? > This way we avoid wasting reviewer resources on rejected documents. >=20 > The QA reviewer's review isn't given special consideration to block WG = adoption > BUT it is intended to be useful input to the WG decision about whether = to adopt > the WG-00 draft. Ok, I could see having an extra external voice being useful as a way of = including extra support or non-support for a document if there was some = contention. Thanks, Chris. > To be blunt, it can be another tool to demonstrate lack of consensus = or that a draft > is a bad idea before the draft is actually adopted by the WG. >=20 > As for avoiding wasting reviewer resources, the gate there is that the = WG chairs > believe the draft should be up for WG adoption. I would hope that is = a sufficient gate. > =20 > Also, wither way the next step should be added as a 4. to the = "detailed > process". >=20 > Can you clarify? I.e. suggest words - and it is a wiki - feel free = to add a bit of text > with context such as [NOTE: 4. blah blah (suggested by Lou Berger)] >=20 > Thanks, > Alia > =20 >=20 > Thanks, > Lou > On 8/21/2014 10:52 AM, Alia Atlas wrote: > > Sandy, > > > > Exactly so. :-) > > > > Alia > > > > > > On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy > > wrote: > > > > I read through the process again and to me it seems clear that = it > > does not. > > > > "Any issues the QA Reviewer finds are written down, sent to the > > mailing list and discussed for future versions, but need not = gate > > the progress of the draft in the WG" > > > > I'd be interested to see how others interpret the process. > > > > --Sandy > > > > On Aug 21, 2014, at 10:11 AM, Lou Berger > > wrote: > > > > > Alia, > > > I'm unclear on one point: Is it your intent for the quality > > review > > > to gate WG acceptance? > > > > > > Lou > > > > > > On 8/20/2014 10:45 AM, Alia Atlas wrote: > > >> Hi to all the Routing Area WG Chairs and Secretaries, > > >> > > >> As Adrian and I discussed prior to IETF 90 and in the Routing = Area > > >> meeting at IETF 90, > > >> we would like to start using the new Draft Quality Assurance > > process > > >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa ) > > for all > > >> drafts that are being > > >> considered for WG adoption. Drafts that are already WG = drafts > > do not > > >> need to go through this process - but chairs can ask if it = seems > > >> desirable. > > >> > > >> As with many processes in the IETF, this process is intended = to be > > >> used for the spirit of the goal, subject to common-sense and > > technical > > >> perspective. In particular, none of this process is intended = to > > gate > > >> or otherwise impede the normal progression of documents = through > > IETF > > >> working groups: rather, it is intended to provide additional = input, > > >> review, and comments that the working groups can use to help > > improve > > >> the quality of their documents, and to help chairs determine > > quality > > >> and consensus for documents. We do not expect IETF process to > > wait for > > >> reviews to happen. > > >> > > >> As described on the wiki page, the detailed process is: > > >> > > >> 1. The WG Chair or Secretary emails the Routing Directorate > > >> Coordinators ( Deborah Brungard > > > >> >) and Jonathan Hardwick = > >> at metaswitch.com > > >). The subject should > > >> be WG Draft QA Requested: > >> >. > > >> > > >> 2. The WG Chair or Secretary marks a draft in the datatracker = as > > >> "Candidate for Adoption" and specifies the date on which = WG > > Draft > > >> QA was requested. > > >> > > >> 3. The Routing Directorate Coordinators and WG Chairs agree = and > > find > > >> a QA Reviewer. The review can be done during the WG Call = for > > >> Adoption. The WG Chair or Secretary adds a comment in the > > draft's > > >> datatracker history page indicating whom is the QA = Reviewer. > > >> > > >> Please start doing this now. > > >> > > >> After IETF-91, we can discuss how this is going and its = usefulness. > > >> > > >> Thanks, > > >> Alia > > > > > > > >=20 >=20 --Apple-Mail=_7B0CD68C-FB6A-4631-830D-C34A0AB032B0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Aug 21, 2014, at 11:22 AM, Alia Atlas <akatlas@gmail.com> wrote:

Lou,

On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger <lberger@labn.net> wrote:
Okay, then why not wait for assignment until there is a WG -00 draft?
This way we avoid wasting reviewer resources on rejected documents.

The QA reviewer's review isn't given special consideration to block WG adoption
BUT it is intended to be useful input to the WG decision about whether to adopt
the WG-00 draft.

Ok, I could see having an extra external voice being useful as a way of including extra support or non-support for a document if there was some contention.

Thanks,
Chris.

To be blunt, it can be another tool to demonstrate lack of consensus or that a draft
is a bad idea before the draft is actually adopted by the WG.

As for avoiding wasting reviewer resources, the gate there is that the WG chairs
believe the draft should be up for WG adoption.   I would hope that is a sufficient gate.
 
Also, wither way the next step should be added as a 4. to the "detailed
process".

Can you clarify?  I.e. suggest words  - and it is a wiki - feel free to add a bit of text
with context  such as [NOTE: 4. blah blah (suggested by Lou Berger)]

Thanks,
Alia
 

Thanks,
Lou
On 8/21/2014 10:52 AM, Alia Atlas wrote:
> Sandy,
>
> Exactly so.    :-)
>
> Alia
>
>
> On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy <sandy@tislabs.com
> <mailto:sandy@tislabs.com>> wrote:
>
>     I read through the process again and to me it seems clear that it
>     does not.
>
>     "Any issues the QA Reviewer finds are written down, sent to the
>     mailing list and discussed for future versions, but need not gate
>     the progress of the draft in the WG"
>
>     I'd be interested to see how others interpret the process.
>
>     --Sandy
>
>     On Aug 21, 2014, at 10:11 AM, Lou Berger <lberger@labn.net
>     <mailto:lberger@labn.net>> wrote:
>
>     > Alia,
>     >    I'm unclear on one point: Is it your intent for the quality
>     review
>     > to gate WG acceptance?
>     >
>     > Lou
>     >
>     > On 8/20/2014 10:45 AM, Alia Atlas wrote:
>     >> Hi to all the Routing  Area WG Chairs and Secretaries,
>     >>
>     >> As Adrian and I discussed prior to IETF 90 and in the Routing Area
>     >> meeting at IETF 90,
>     >> we would like to start using the new Draft Quality Assurance
>     process
>     >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa )
>     for all
>     >> drafts that are being
>     >> considered for WG adoption.   Drafts that are already WG drafts
>     do not
>     >> need to go through this process - but chairs can ask if it seems
>     >> desirable.
>     >>
>     >> As with many processes in the IETF, this process is intended to be
>     >> used for the spirit of the goal, subject to common-sense and
>     technical
>     >> perspective. In particular, none of this process is intended to
>     gate
>     >> or otherwise impede the normal progression of documents through
>     IETF
>     >> working groups: rather, it is intended to provide additional input,
>     >> review, and comments that the working groups can use to help
>     improve
>     >> the quality of their documents, and to help chairs determine
>     quality
>     >> and consensus for documents. We do not expect IETF process to
>     wait for
>     >> reviews to happen.
>     >>
>     >> As described on the wiki page, the detailed process is:
>     >>
>     >> 1. The WG Chair or Secretary emails the Routing Directorate
>     >>    Coordinators ( Deborah Brungard <db3546 at att.com
>     <http://att.com>
>     >>    <http://att.com/>>) and Jonathan Hardwick <jonathan.hardwick
>     >>    at metaswitch.com <http://metaswitch.com>
>     <http://metaswitch.com/>>). The subject should
>     >>    be WG Draft QA Requested: <draft-name
>     >>    <http://tools.ietf.org/html/draft-name>>.
>     >>
>     >> 2. The WG Chair or Secretary marks a draft in the datatracker as
>     >>    "Candidate for Adoption" and specifies the date on which WG
>     Draft
>     >>    QA was requested.
>     >>
>     >> 3. The Routing Directorate Coordinators and WG Chairs agree and
>     find
>     >>    a QA Reviewer. The review can be done during the WG Call for
>     >>    Adoption. The WG Chair or Secretary adds a comment in the
>     draft's
>     >>    datatracker history page indicating whom is the QA Reviewer.
>     >>
>     >> Please start doing this now.
>     >>
>     >> After IETF-91, we can discuss how this is going and its usefulness.
>     >>
>     >> Thanks,
>     >> Alia
>     >
>
>



--Apple-Mail=_7B0CD68C-FB6A-4631-830D-C34A0AB032B0-- From nobody Thu Aug 21 09:16: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 D1F6F1A0663 for ; Thu, 21 Aug 2014 09:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgjE88vKrqC3 for ; Thu, 21 Aug 2014 09:16:08 -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 2CB511A6FE3 for ; Thu, 21 Aug 2014 09:15:39 -0700 (PDT) Received: (qmail 28146 invoked by uid 0); 21 Aug 2014 16:15:37 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 21 Aug 2014 16:15:37 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id haFW1o00N2SSUrH01aFZ69; Thu, 21 Aug 2014 16:15:35 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=J_gUWGTokVsA:10 a=uAKC8EM7BPsA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=ImH2GW_KAAAA:8 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=bwR9eBR2AAAA:8 a=NOn1NsQ_-EBjAE_78YgA:9 a=QEXdDO2ut3YA:10 a=eRsKL0hzPpUA:10 a=jGFIkMWxz3cA:10 a=33rK67OTR_gA:10 a=Da6P7i8uiOsA: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=Pq7FFBUOQOwGVaEgGjWW7+utuJniWqTxfFpPjvRjQ7A=; b=vnvxQ04EayJ9NNXUyxnxNwKFuA141b45AZyaIX9Zh0/Kj5oO3BwL8qs5pqW7j2HJQsox1hf4t1RhZD5uNgq5pggFOZWWuuR5Tdj937504aVwDbdcuGIELgLnMzHDJr8J; Received: from box313.bluehost.com ([69.89.31.113]:59202 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKV1P-0000kF-LA; Thu, 21 Aug 2014 10:15:31 -0600 Message-ID: <53F61B72.6090200@labn.net> Date: Thu, 21 Aug 2014 12:16:50 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/qcKryYX0XF0Agqx6q33yjf_-1Ks Cc: "rtg-dir@ietf.org" , Sandra Murphy , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 16:16:12 -0000 Alia, On 8/21/2014 11:22 AM, Alia Atlas wrote: > Lou, > > On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger > wrote: > > Okay, then why not wait for assignment until there is a WG -00 draf= t? > This way we avoid wasting reviewer resources on rejected documents.= > > > The QA reviewer's review isn't given special consideration to block WG > adoption > BUT it is intended to be useful input to the WG decision about whether > to adopt > the WG-00 draft. > The following really confuses me: > To be blunt, it can be another tool to demonstrate lack of consensus Is this the point of the existing WG adoption poll? How does an outside review aid in a show of consensus by the WG? > or that a draft > is a bad idea before the draft is actually adopted by the WG. > Isn't the the job of the chair to cover this case? BTW Note I'm not saying that they block the poll. In the past I have used polls on documents in order to *stop* discussion on the topic. > As for avoiding wasting reviewer resources, the gate there is that the > WG chairs > believe the draft should be up for WG adoption. I would hope that is > a sufficient gate. > =20 This seems to completely counter your previous comment. If the chair can do the job of gating the document here, they can do it for the previous case to. > Also, wither way the next step should be added as a 4. to the > "detailed > process". > > > Can you clarify? I.e. suggest words - and it is a wiki - feel free > to add a bit of text So anyone can change your process??? How about something like: 4. The QA review does not block or gate a call for adoption, and the QA Reviewer may send their comments to the WG and authors during the call, or after it is closed. If the document is adopted, the QA Reviewer will work with the document editors to resolve comments. Comments may be tracked via the WG's trac tools page. > with context such as > [NOTE: 4. blah blah (suggested by Lou Berger)] > Please no. -- (or perhaps you're just trying to get me *not* to write anything;-) Lou > Thanks, > Alia > =20 > > > Thanks, > Lou > On 8/21/2014 10:52 AM, Alia Atlas wrote: > > Sandy, > > > > Exactly so. :-) > > > > Alia > > > > > > On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy > > > >> wrote: > > > > I read through the process again and to me it seems clear > that it > > does not. > > > > "Any issues the QA Reviewer finds are written down, sent to t= he > > mailing list and discussed for future versions, but need not > gate > > the progress of the draft in the WG" > > > > I'd be interested to see how others interpret the process. > > > > --Sandy > > > > On Aug 21, 2014, at 10:11 AM, Lou Berger > > >> wrote: > > > > > Alia, > > > I'm unclear on one point: Is it your intent for the qual= ity > > review > > > to gate WG acceptance? > > > > > > Lou > > > > > > On 8/20/2014 10:45 AM, Alia Atlas wrote: > > >> Hi to all the Routing Area WG Chairs and Secretaries, > > >> > > >> As Adrian and I discussed prior to IETF 90 and in the > Routing Area > > >> meeting at IETF 90, > > >> we would like to start using the new Draft Quality Assuran= ce > > process > > >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQ= a ) > > for all > > >> drafts that are being > > >> considered for WG adoption. Drafts that are already WG > drafts > > do not > > >> need to go through this process - but chairs can ask if > it seems > > >> desirable. > > >> > > >> As with many processes in the IETF, this process is > intended to be > > >> used for the spirit of the goal, subject to common-sense a= nd > > technical > > >> perspective. In particular, none of this process is > intended to > > gate > > >> or otherwise impede the normal progression of documents > through > > IETF > > >> working groups: rather, it is intended to provide > additional input, > > >> review, and comments that the working groups can use to he= lp > > improve > > >> the quality of their documents, and to help chairs determi= ne > > quality > > >> and consensus for documents. We do not expect IETF process= to > > wait for > > >> reviews to happen. > > >> > > >> As described on the wiki page, the detailed process is: > > >> > > >> 1. The WG Chair or Secretary emails the Routing Directorat= e > > >> Coordinators ( Deborah Brungard > > > > >> >) and Jonathan Hardwick > > >> at metaswitch.com > > > >). The subject should > > >> be WG Draft QA Requested: > >> >. > > >> > > >> 2. The WG Chair or Secretary marks a draft in the > datatracker as > > >> "Candidate for Adoption" and specifies the date on > which WG > > Draft > > >> QA was requested. > > >> > > >> 3. The Routing Directorate Coordinators and WG Chairs > agree and > > find > > >> a QA Reviewer. The review can be done during the WG > Call for > > >> Adoption. The WG Chair or Secretary adds a comment in t= he > > draft's > > >> datatracker history page indicating whom is the QA > Reviewer. > > >> > > >> Please start doing this now. > > >> > > >> After IETF-91, we can discuss how this is going and its > usefulness. > > >> > > >> Thanks, > > >> Alia > > > > > > > > > From nobody Thu Aug 21 09:19: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 A58891A06AE for ; Thu, 21 Aug 2014 09:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.267 X-Spam-Level: X-Spam-Status: No, score=-0.267 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 MqmK9f2VUdpq for ; Thu, 21 Aug 2014 09:19:27 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id E80501A06C7 for ; Thu, 21 Aug 2014 09:19:22 -0700 (PDT) Received: (qmail 7804 invoked by uid 0); 21 Aug 2014 16:19:16 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 21 Aug 2014 16:19:16 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id haK91o0142SSUrH01aKCf7; Thu, 21 Aug 2014 16:19:14 -0600 X-Authority-Analysis: v=2.1 cv=KvHehwmN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=J_gUWGTokVsA:10 a=uAKC8EM7BPsA:10 a=HFCU6gKsb0MA:10 a=8nJEP1OIZ-IA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=_v7u3vsEUDXjJFuGoLsA:9 a=wPNLvfGTeEIA:10 a=P1jpjLd8GksA:10 a=GNMbabmF3CIA:10 a=2GLdp0_pZ50A: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=lB36s78hpklDIUOyfYZ/VxgnlBvooXAJnmxxQUNZ5Sc=; b=RkCHtv9k5tTmWMrHNsWr/oii/ThIYcJ+5ZlMKDUTtDpcxHTs1DW7T+PigUrM5N1ZctdIS6aSv6/CRBs8wwsF7MF3y12sEjlzX7gQF5w3M+sYAXz0ZW9p39nuxYuJoNnq; Received: from box313.bluehost.com ([69.89.31.113]:59570 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKV4x-0001tN-0G; Thu, 21 Aug 2014 10:19:11 -0600 Message-ID: <53F61C4E.5020306@labn.net> Date: Thu, 21 Aug 2014 12:20:30 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ross Callon References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> <3efca289e0964654bc999900a42cb22b@CO2PR05MB636.namprd05.prod.outlook.com> In-Reply-To: <3efca289e0964654bc999900a42cb22b@CO2PR05MB636.namprd05.prod.outlook.com> 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/TH5PSm_FDSMp37i87plJ6PXEDac Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Christian Hopps , Alia Atlas Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 16:19:31 -0000 On 8/21/2014 11:53 AM, Ross Callon wrote: > If we think of the review this way, then it does not actually add delay or more process to the existing IETF process, but it just makes it more likely that for each document at least some portion of our experts will actually do what we already want them to do. Sounds like the reviewer really needs to be active in the WG then and not just reviewing for document quality... From nobody Thu Aug 21 09:20:40 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 45FDA1A06AE; Thu, 21 Aug 2014 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.668, 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 1GS946LA24v5; Thu, 21 Aug 2014 09:20:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5C07C1A06D1; Thu, 21 Aug 2014 09:20:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id E7AB2C27E; Thu, 21 Aug 2014 12:20:35 -0400 (EDT) Date: Thu, 21 Aug 2014 12:20:35 -0400 From: Jeffrey Haas To: Alexander Vainshtein Message-ID: <20140821162035.GM30106@pfrc> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/851yE6m5M1NwprQTreReNWqA9Ws Cc: "rtg-dir@ietf.org" , Christian Hopps , Sandra Murphy , Alia Atlas , "rtg-chairs@ietf.org" , Jeffrey Haas , Lou Berger Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 16:20:38 -0000 Sasha, On Thu, Aug 21, 2014 at 03:39:14PM +0000, Alexander Vainshtein wrote: > Jeffrey, > A na?ve question: > If a document is "difficult to read and review" (no matter at what stage), how can the WG understand/reach consensus that it is "of interesting technical content "? It seems to happen. Some people seem willing to push through difficult language or confusing syntax anyway. Improving the quality of the document *before* the call to adopt means the document can get better discussion and easier review during adoption. Once a document has been adopted, the audience is wider. -- Jeff From nobody Thu Aug 21 09:28: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 6DBF01A044F; Thu, 21 Aug 2014 09:27:59 -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 RHqK5IurT8QL; Thu, 21 Aug 2014 09:27:56 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A92A1A03EF; Thu, 21 Aug 2014 09:27:56 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id 29so8305511yhl.32 for ; Thu, 21 Aug 2014 09:27: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=RQWuAuPcZCw136mTjYTeBSA1XXFStQJK94DuEHjJbrs=; b=KPKyjCs9dV4aMdrTNq2VBcXGBD/9K44L9FD7lDXilEb54GOxCkhg61FWaMEysFL5ja IX3fGbpBKvsNh3pVTZn1mTorShR2c2lro1XhSdL5Vo3sM/kWbxJujEbhnm3/LFWks+eG Ew7KUvB2XbQvX+YOtdbOnSDkldAI+Hy4LghXZBpp/dMWbiLGZJxI52TMARlQ7wjsZDvN DFIkdvPa0l8SyCiaUR+AuwCTw6viHoQcQ1Mkm6DdZSXM5Aeu/xzcKLiWeAoN267H3WWJ hW+AP+dPm73xH7rD8HLVqIHXddeszYSHECWM/gDUfLzwNQ6E8CN0uOtgSeJZE9mxacRA xBKQ== MIME-Version: 1.0 X-Received: by 10.236.85.208 with SMTP id u56mr84917819yhe.48.1408638475499; Thu, 21 Aug 2014 09:27:55 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Thu, 21 Aug 2014 09:27:55 -0700 (PDT) In-Reply-To: <53F61B72.6090200@labn.net> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <53F61B72.6090200@labn.net> Date: Thu, 21 Aug 2014 12:27:55 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=20cf301af725f3023d05012633a1 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/e7oJBW_4I2rIwjD_-px_nFV7hMc Cc: "rtg-dir@ietf.org" , Sandra Murphy , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 16:27:59 -0000 --20cf301af725f3023d05012633a1 Content-Type: text/plain; charset=UTF-8 Lou, On Thu, Aug 21, 2014 at 12:16 PM, Lou Berger wrote: > Alia, > > On 8/21/2014 11:22 AM, Alia Atlas wrote: > > Lou, > > > > On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger > > wrote: > > > > Okay, then why not wait for assignment until there is a WG -00 draft? > > This way we avoid wasting reviewer resources on rejected documents. > > > > > > The QA reviewer's review isn't given special consideration to block WG > > adoption > > BUT it is intended to be useful input to the WG decision about whether > > to adopt > > the WG-00 draft. > > > The following really confuses me: > > > To be blunt, it can be another tool to demonstrate lack of consensus > > Is this the point of the existing WG adoption poll? How does an outside > review aid in a show of consensus by the WG? > Good point - by triggering discussion? > or that a draft > > is a bad idea before the draft is actually adopted by the WG. > > > Isn't the the job of the chair to cover this case? BTW Note I'm not > saying that they block the poll. In the past I have used polls on > documents in order to *stop* discussion on the topic. > The primary purpose of the QA Review process is to get early cross-WG review and routing directorate reviews done while the drafts are still malleable. > > As for avoiding wasting reviewer resources, the gate there is that the > > WG chairs > > believe the draft should be up for WG adoption. I would hope that is > > a sufficient gate. > > > > This seems to completely counter your previous comment. If the chair can > do the job of gating the document here, they can do it for the previous > case to. > If the WG Chair doesn't want a QA Reviewer for a particular draft, that is up to the WG chair's discretion. > > Also, wither way the next step should be added as a 4. to the > > "detailed > > process". > > > > > > Can you clarify? I.e. suggest words - and it is a wiki - feel free > > to add a bit of text > So anyone can change your process??? > > How about something like: > > 4. The QA review does not block or gate a call for adoption, and the QA > Reviewer may send their comments to the WG and authors during the call, > or after it is closed. If the document is adopted, the QA Reviewer will > work with the document editors to resolve comments. Comments may be > tracked via the WG's trac tools page. Sounds good. I think it is implied. > > with context such as > > > [NOTE: 4. blah blah (suggested by Lou Berger)] > > > Please no. -- (or perhaps you're just trying to get me *not* to write > anything;-) > Without context after this discussion is fine too - but I beat you to it. Alia > > Lou > > > Thanks, > > Alia > > > > > > > > Thanks, > > Lou > > On 8/21/2014 10:52 AM, Alia Atlas wrote: > > > Sandy, > > > > > > Exactly so. :-) > > > > > > Alia > > > > > > > > > On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murphy > > > > > >> wrote: > > > > > > I read through the process again and to me it seems clear > > that it > > > does not. > > > > > > "Any issues the QA Reviewer finds are written down, sent to the > > > mailing list and discussed for future versions, but need not > > gate > > > the progress of the draft in the WG" > > > > > > I'd be interested to see how others interpret the process. > > > > > > --Sandy > > > > > > On Aug 21, 2014, at 10:11 AM, Lou Berger > > > > >> wrote: > > > > > > > Alia, > > > > I'm unclear on one point: Is it your intent for the > quality > > > review > > > > to gate WG acceptance? > > > > > > > > Lou > > > > > > > > On 8/20/2014 10:45 AM, Alia Atlas wrote: > > > >> Hi to all the Routing Area WG Chairs and Secretaries, > > > >> > > > >> As Adrian and I discussed prior to IETF 90 and in the > > Routing Area > > > >> meeting at IETF 90, > > > >> we would like to start using the new Draft Quality Assurance > > > process > > > >> ( http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > ) > > > for all > > > >> drafts that are being > > > >> considered for WG adoption. Drafts that are already WG > > drafts > > > do not > > > >> need to go through this process - but chairs can ask if > > it seems > > > >> desirable. > > > >> > > > >> As with many processes in the IETF, this process is > > intended to be > > > >> used for the spirit of the goal, subject to common-sense and > > > technical > > > >> perspective. In particular, none of this process is > > intended to > > > gate > > > >> or otherwise impede the normal progression of documents > > through > > > IETF > > > >> working groups: rather, it is intended to provide > > additional input, > > > >> review, and comments that the working groups can use to help > > > improve > > > >> the quality of their documents, and to help chairs determine > > > quality > > > >> and consensus for documents. We do not expect IETF process > to > > > wait for > > > >> reviews to happen. > > > >> > > > >> As described on the wiki page, the detailed process is: > > > >> > > > >> 1. The WG Chair or Secretary emails the Routing Directorate > > > >> Coordinators ( Deborah Brungard > > > > > > > >> >) and Jonathan Hardwick > > > > >> at metaswitch.com > > > > > >). The subject should > > > >> be WG Draft QA Requested: > > >> >. > > > >> > > > >> 2. The WG Chair or Secretary marks a draft in the > > datatracker as > > > >> "Candidate for Adoption" and specifies the date on > > which WG > > > Draft > > > >> QA was requested. > > > >> > > > >> 3. The Routing Directorate Coordinators and WG Chairs > > agree and > > > find > > > >> a QA Reviewer. The review can be done during the WG > > Call for > > > >> Adoption. The WG Chair or Secretary adds a comment in the > > > draft's > > > >> datatracker history page indicating whom is the QA > > Reviewer. > > > >> > > > >> Please start doing this now. > > > >> > > > >> After IETF-91, we can discuss how this is going and its > > usefulness. > > > >> > > > >> Thanks, > > > >> Alia > > > > > > > > > > > > > > > > > --20cf301af725f3023d05012633a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lou,

On Thu, Aug 21, 2014 at 12:16 PM, Lou = Berger <lberger@labn.net> wrote:
Alia,

On 8/21/2014 11:22 AM, Alia Atlas wrote:
> Lou,
>
> On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger <lberger@labn.net
> <mailto:l= berger@labn.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Okay, then why not wait for assignment until there = is a WG -00 draft?
>=C2=A0 =C2=A0 =C2=A0This way we avoid wasting reviewer resources on rej= ected documents.
>
>
> The QA reviewer's review isn't given special consideration to = block WG
> adoption
> BUT it is intended to be useful input to the WG decision about whether=
> to adopt
> the WG-00 draft.
>
The following really confuses me:

> To be blunt, it can be another tool to demonstrate lack of consensus
Is this the point of the existing WG adoption poll?=C2=A0 How does an= outside
review aid in a show of consensus by the WG?

Good point - by triggering discussion? =C2=A0=C2=A0
> or that a draft
> is a bad idea before the draft is actually adopted by the WG.
>
Isn't the the job of the chair to cover this case?=C2=A0 BTW Note= I'm not
saying that they block the poll.=C2=A0 In the past I=C2=A0 have used polls = on
documents in order to *stop* discussion on the topic.
=
The primary purpose of the QA Review process is to get early= cross-WG
review and routing directorate reviews done while the d= rafts are still malleable.
=C2=A0
> As for avoiding wasting reviewer resources, the gate t= here is that the
> WG chairs
> believe the draft should be up for WG adoption.=C2=A0 =C2=A0I would ho= pe that is
> a sufficient gate.
>

This seems to completely counter your previous comment. If the chair = can
do the job of gating the document here, they can do it for the previous
case to.

If the WG Chair doesn't wa= nt a QA Reviewer for a particular draft, that is up to the
WG cha= ir's discretion.

=C2=A0
>=C2=A0 =C2=A0 =C2=A0Also, wither way the next step shou= ld be added as a 4. to the
>=C2=A0 =C2=A0 =C2=A0"detailed
>=C2=A0 =C2=A0 =C2=A0process".
>
>
> Can you clarify?=C2=A0 I.e. suggest words=C2=A0 - and it is a wiki - f= eel free
> to add a bit of text
So anyone can change your process???

How about something like:

4. The QA review does not block or gate a call for adoption, and the QA
Reviewer may send their comments to the WG and authors during the call,
or after it is closed. If the document is adopted, the QA Reviewer will
work with the document editors to resolve comments. Comments may be
tracked via the WG's trac tools page.

S= ounds good. =C2=A0I think it is implied.

=C2=A0
> with context=C2=A0 such as

> [NOTE: 4. blah blah (suggested by Lou Berger)]
>
Please no.=C2=A0 --=C2=A0 (or perhaps you're just trying to get m= e *not* to write
anything;-)

Without context after this = discussion is fine too - but I beat you to it.

Alia
=C2=A0

Lou

> Thanks,
> Alia
>
>
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0Lou
>=C2=A0 =C2=A0 =C2=A0On 8/21/2014 10:52 AM, Alia Atlas wrote:
>=C2=A0 =C2=A0 =C2=A0> Sandy,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Exactly so.=C2=A0 =C2=A0 :-)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Alia
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Thu, Aug 21, 2014 at 10:50 AM, Sandra Murph= y
>=C2=A0 =C2=A0 =C2=A0<sandy@tisl= abs.com <mailto:sandy@tislabs.c= om>
>=C2=A0 =C2=A0 =C2=A0> <mailto:sandy@tislabs.com <mailto:sandy@tislabs.com>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I read through the process = again and to me it seems clear
>=C2=A0 =C2=A0 =C2=A0that it
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0does not.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0"Any issues the QA Rev= iewer finds are written down, sent to the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0mailing list and discussed = for future versions, but need not
>=C2=A0 =C2=A0 =C2=A0gate
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0the progress of the draft i= n the WG"
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0I'd be interested to se= e how others interpret the process.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0--Sandy
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On Aug 21, 2014, at 10:11 A= M, Lou Berger <lberger@labn.net<= br> >=C2=A0 =C2=A0 =C2=A0<mailto:lber= ger@labn.net>
>=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0<mailto:lberger@= labn.net <mailto:lberger@labn.ne= t>>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Alia,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 I'm u= nclear on one point: Is it your intent for the quality
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0review
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> to gate WG acceptance?=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Lou
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On 8/20/2014 10:45 AM,= Alia Atlas wrote:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Hi to all the Rout= ing=C2=A0 Area WG Chairs and Secretaries,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> As Adrian and I di= scussed prior to IETF 90 and in the
>=C2=A0 =C2=A0 =C2=A0Routing Area
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> meeting at IETF 90= ,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> we would like to s= tart using the new Draft Quality Assurance
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0process
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> ( htt= p://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa )
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0for all
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> drafts that are be= ing
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> considered for WG = adoption.=C2=A0 =C2=A0Drafts that are already WG
>=C2=A0 =C2=A0 =C2=A0drafts
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0do not
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> need to go through= this process - but chairs can ask if
>=C2=A0 =C2=A0 =C2=A0it seems
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> desirable.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> As with many proce= sses in the IETF, this process is
>=C2=A0 =C2=A0 =C2=A0intended to be
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> used for the spiri= t of the goal, subject to common-sense and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0technical
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> perspective. In pa= rticular, none of this process is
>=C2=A0 =C2=A0 =C2=A0intended to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0gate
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> or otherwise imped= e the normal progression of documents
>=C2=A0 =C2=A0 =C2=A0through
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0IETF
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> working groups: ra= ther, it is intended to provide
>=C2=A0 =C2=A0 =C2=A0additional input,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> review, and commen= ts that the working groups can use to help
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0improve
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> the quality of the= ir documents, and to help chairs determine
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0quality
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> and consensus for = documents. We do not expect IETF process to
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0wait for
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> reviews to happen.=
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> As described on th= e wiki page, the detailed process is:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 1. The WG Chair or= Secretary emails the Routing Directorate
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Coord= inators ( Deborah Brungard <db3546 at att.com
>=C2=A0 =C2=A0 =C2=A0<ht= tp://att.com>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://att.com>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 <<= a href=3D"http://att.com/" target=3D"_blank">http://att.com/>>) a= nd Jonathan Hardwick
>=C2=A0 =C2=A0 =C2=A0<jonathan.hardwick
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 at metaswitch.com <http://metaswitch.com= >
>=C2=A0 =C2=A0 =C2=A0<http://metaswitch.com>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<http://metaswitch.com/>>). The subj= ect should
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 be WG= Draft QA Requested: <draft-name
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 <<= a href=3D"http://tools.ietf.org/html/draft-name" target=3D"_blank">http://t= ools.ietf.org/html/draft-name>>.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 2. The WG Chair or= Secretary marks a draft in the
>=C2=A0 =C2=A0 =C2=A0datatracker as
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 "= ;Candidate for Adoption" and specifies the date on
>=C2=A0 =C2=A0 =C2=A0which WG
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Draft
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 QA wa= s requested.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> 3. The Routing Dir= ectorate Coordinators and WG Chairs
>=C2=A0 =C2=A0 =C2=A0agree and
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0find
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 a QA = Reviewer. The review can be done during the WG
>=C2=A0 =C2=A0 =C2=A0Call for
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 Adopt= ion. The WG Chair or Secretary adds a comment in the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0draft's
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>=C2=A0 =C2=A0 datat= racker history page indicating whom is the QA
>=C2=A0 =C2=A0 =C2=A0Reviewer.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Please start doing= this now.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> After IETF-91, we = can discuss how this is going and its
>=C2=A0 =C2=A0 =C2=A0usefulness.
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Thanks,
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>> Alia
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>
>



--20cf301af725f3023d05012633a1-- From nobody Thu Aug 21 09:32: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 041811A06A3; Thu, 21 Aug 2014 09:32:28 -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 fY1Yq5yOqvDq; Thu, 21 Aug 2014 09:32:26 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276DF1A0693; Thu, 21 Aug 2014 09:32:26 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id a41so8259112yho.15 for ; Thu, 21 Aug 2014 09:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uedvHI2fPK8Jw3J5JuIxHEzr8kgTSnXXZQ9E1z8rfig=; b=Vf4hSXvzvw4FfSpTX8+W7Zz/+7imAZ306Xmmt2GN8WEfDlPKEtTxPzPMF+L5ojownT cggzN0873fAK6jcxGvxryJbCSUpVFb6LO8DT1Hq5KvKyWQkMtRFGtGSiDKQEkT46SE3f TrPcK5caBtDcJkfiF1gq9sDwsmazNE8TqKusHpOvzeZ/0zn7rL6cSSVkZHiSc82Kbm3c bBaExkvKbJE4cWWXkIgFxBwZWhAOKjX+Oa76r8ExPXibL55B/7eLBaUfHqrN5DfimJSZ w1QuK76woEnNAiAcQjXNy75ImABdX82aAZQxgxKTa6yX6l53r+6IWf8U8IVY+jIbI/q+ RkwA== MIME-Version: 1.0 X-Received: by 10.236.84.134 with SMTP id s6mr84745971yhe.38.1408638745477; Thu, 21 Aug 2014 09:32:25 -0700 (PDT) Received: by 10.170.110.17 with HTTP; Thu, 21 Aug 2014 09:32:25 -0700 (PDT) In-Reply-To: <53F61C4E.5020306@labn.net> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> <3efca289e0964654bc999900a42cb22b@CO2PR05MB636.namprd05.prod.outlook.com> <53F61C4E.5020306@labn.net> Date: Thu, 21 Aug 2014 12:32:25 -0400 Message-ID: From: Alia Atlas To: Lou Berger Content-Type: multipart/alternative; boundary=20cf301b69cf0a88a20501264420 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/dBFRsiXOvso95UWCG67b6-O8nCU Cc: Ross Callon , "rtg-dir@ietf.org" , Christian Hopps , "rtg-chairs@ietf.org" Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 16:32:28 -0000 --20cf301b69cf0a88a20501264420 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 12:20 PM, Lou Berger wrote: > > On 8/21/2014 11:53 AM, Ross Callon wrote: > > If we think of the review this way, then it does not actually add delay > or more process to the existing IETF process, but it just makes it more > likely that for each document at least some portion of our experts will > actually do what we already want them to do. > Sounds like the reviewer really needs to be active in the WG then and > not just reviewing for document quality... > While it is desirable to have active WG participants review a draft, that "should" happen because the draft is of interest and relevant. The WG Document QA process is NOT trying to fix that problem. The WG Document QA is trying to get the cross-WG perspective via early directorate review when issues can still be easily fixed. Of course, more reviews by experienced participants is desirable - but that's part of having a WG with energy and drafts in the design center. Sometimes that comes by kicking (s/kicking/asking) people individually to do reviews. Alia --20cf301b69cf0a88a20501264420 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 21, 2014 at 12:20 PM, Lou Berger <lberger@labn.net> w= rote:

On 8/21/2014 11:53 AM, Ross Callon wrote:
>=C2=A0 If we think of the review this way, then it does not actually ad= d delay or more process to the existing IETF process, but it just makes it = more likely that for each document at least some portion of our experts wil= l actually do what we already want them to do.
Sounds like the reviewer really needs to be active in the WG then and=
not just reviewing for document quality...

<= div>While it is desirable to have active WG participants review a draft, th= at "should" happen because the draft is of interest =C2=A0and rel= evant. =C2=A0 The WG Document QA process is NOT trying to fix that problem.=

The WG Document QA is trying to get the cross-WG perspe= ctive via early directorate review when issues can still be easily fixed.

Of course, more reviews by experienced participants= is desirable - but that's part of having a WG with energy and drafts i= n the design center. =C2=A0Sometimes that comes by kicking (s/kicking/askin= g) people individually to do reviews.

Alia
--20cf301b69cf0a88a20501264420-- From nobody Thu Aug 21 09:50: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 BBDB31A06AE for ; Thu, 21 Aug 2014 09:50:02 -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 vIE3rdOLB4Ci for ; Thu, 21 Aug 2014 09:50:01 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 6AB951A0453 for ; Thu, 21 Aug 2014 09:50:01 -0700 (PDT) Received: (qmail 26057 invoked by uid 0); 21 Aug 2014 16:49:57 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 21 Aug 2014 16:49:57 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id hapq1o00z2SSUrH01aptVS; Thu, 21 Aug 2014 16:49:55 -0600 X-Authority-Analysis: v=2.1 cv=DIUcvU9b c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=u9EReRu7m0cA:10 a=J_gUWGTokVsA:10 a=uAKC8EM7BPsA:10 a=HFCU6gKsb0MA:10 a=IkcTkHD0fZMA:10 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=j9gCZs7P-CcnT_nUOdUA:9 a=QEXdDO2ut3YA: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=BY3RphRNk5nurOZRzJDO7mvZGpo+6stC+IL6eDMBy50=; b=CxB7xuZlS9qcDTDwlLznplA+BaoYyIUC+07kSmeMfnXGFY39ig1QBL64+X3yr/Ph/76chBlEjpug7qgWE3Z36s1Ehskocv9ADXS+QBXTDCosHd7vyJA1C8g+vL9tS0Mg; Received: from box313.bluehost.com ([69.89.31.113]:34677 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.82) (envelope-from ) id 1XKVYd-0003pm-VL; Thu, 21 Aug 2014 10:49:52 -0600 Message-ID: <53F6237F.2030608@labn.net> Date: Thu, 21 Aug 2014 12:51:11 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alia Atlas References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <53F61B72.6090200@labn.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/rd6lyMWX0HzFx4LfFti1dKX3wcQ Cc: "rtg-dir@ietf.org" , "rtg-chairs@ietf.org" , Sandra Murphy Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 16:50:03 -0000 Alia, The updated page is helpful. The timing part of the thread is covered below. On 8/21/2014 12:27 PM, Alia Atlas wrote: > Lou, > > On Thu, Aug 21, 2014 at 12:16 PM, Lou Berger > wrote: > > Alia, > > On 8/21/2014 11:22 AM, Alia Atlas wrote: > > Lou, > > > > On Thu, Aug 21, 2014 at 11:12 AM, Lou Berger > > >> wrote: > > > > Okay, then why not wait for assignment until there is a WG > -00 draft? > > This way we avoid wasting reviewer resources on rejected > documents. > > > > > > The QA reviewer's review isn't given special consideration to > block WG > > adoption > > BUT it is intended to be useful input to the WG decision about > whether > > to adopt > > the WG-00 draft. > > > The following really confuses me: > > > To be blunt, it can be another tool to demonstrate lack of consen= sus > > Is this the point of the existing WG adoption poll? How does an > outside > review aid in a show of consensus by the WG? > > > Good point - by triggering discussion? =20 > > > or that a draft > > is a bad idea before the draft is actually adopted by the WG. > > > Isn't the the job of the chair to cover this case? BTW Note I'm no= t > saying that they block the poll. In the past I have used polls on= > documents in order to *stop* discussion on the topic. > > > The primary purpose of the QA Review process is to get early cross-WG > review and routing directorate reviews done while the drafts are still > malleable. I think early QA review is a great idea, but I certainly hope you didn't mean that once a document is accepted as a WG document it is no longer "malleable". WG change control of a document starts at adoption, not before. > =20 > > > As for avoiding wasting reviewer resources, the gate there is > that the > > WG chairs > > believe the draft should be up for WG adoption. I would hope > that is > > a sufficient gate. > > > > This seems to completely counter your previous comment. If the > chair can > do the job of gating the document here, they can do it for the > previous > case to. > > > If the WG Chair doesn't want a QA Reviewer for a particular draft, > that is up to the > WG chair's discretion. > Giving the chair the discretion to submit a QA Review request either pre or post adoption addresses my concern. (Looks like the process part of the page will need some tweaking to make it clear that chairs have this choice.) Thanks! =2E.. From nobody Thu Aug 21 10:30:50 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 937D91A047D; Thu, 21 Aug 2014 10:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 Zcz_kwNNYVCQ; Thu, 21 Aug 2014 10:30:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75131A04A7; Thu, 21 Aug 2014 10:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28754; q=dns/txt; s=iport; t=1408642235; x=1409851835; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XpI1V9A86d1D9XCAzF3zKzRS5BkKtH3tVAd6MZ2oUmg=; b=dBX6frY3L/WxG/tsbOIINoSQnUjjOyVEV7l1jLz27T2Dz35nwUBFr8rH u/UTHX2B3ZwFWp7CWDRUZ2mlZoHrcQtiul5cKgQe021Ft1BTTUzOZjN4i C5Mj1ZBk6RHjQmheET1t2hUm0EuRVOBzfAmi0h70FZY7fngyDD3Y3F+kz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAGUs9lOtJV2S/2dsb2JhbABPCoJHRoEqBNQdAYEPFneEAwEBAQQaDUQOEAIBCBEDAQIhBwcyFAkIAQEEAQ0FG4gnwysXiX+EagcFRhEHhEwFh0iHSoIThmOEP5UKg15sAYEGAR4GHIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,909,1406592000"; d="scan'208,217";a="349093681" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 21 Aug 2014 17:30:29 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7LHUT9n006172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Aug 2014 17:30:29 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.181]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 12:30:29 -0500 From: "Alvaro Retana (aretana)" To: "George, Wes" , "rtg-ads@tools.ietf.org" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uA Date: Thu, 21 Aug 2014 17:30:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D01B67B26749Baretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/ipFz7cjqieip10M8ShKGbETAoDs Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Thu, 21 Aug 2014 17:30:41 -0000 --_000_D01B67B26749Baretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 8/20/14 11:38 AM, "George, Wes" > wrote: Wes: Hi! Some comments in line.. Alvaro, thank you for the thorough review. Please find my responses below i= nline on behalf of the author team. We have an update in the edit buffer, a= waiting a few updates to the EVPN section and possibly the L2VPN section (t= o incorporate any necessary discussion of RFC 7117), but I wanted to go ahe= ad and respond now that most of the comments have been addressed in our edi= ts at least. Thanks, Wes George From: "Alvaro Retana (aretana)" > Date: Tuesday, August 5, 2014 at 2:44 PM To: "rtg-ads@tools.ietf.org" > Cc: "rtg-dir@ietf.org" >, "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" >, "mpls@ietf.org" > Subject: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Comments: I do have a couple of high-level items I want to bring up. Because I assum= e that these may have already been discussed in the appropriate WG(s) I'm n= ot listing them as major issues, and will defer to what the consensus has b= een so far. 1. Why do we need to publish this document? As I said above, I believe = the work is valuable, but it captures the state in time (today!) of the gap= s =97 it points to work that already solved a potential gap, or is in the p= rocess of solving them. A significant portion of the gaps are already bein= g addressed. Given the importance of IPv6, if published, soon this documen= t will have to be updated to say "nothing breaks". Again, the work is impo= rtant, but it may be better suited to be a "living document" as a guide for= what still needs to be addressed. If it is to be published, I would sugge= st avoiding links to work in progress, but limiting the content to identify= ing the gaps..and then letting the solution drafts/RFCs point back to this = document.. (ala requirements -> solution) 2. It is interesting to me that this draft came through the mpls WG, and= not one of the operations-focused groups..which presumably would be in a b= etter position to evaluate the needs described. Given that the document is= already in WG Last Call, I'm assuming that the alignment has already been = discussed and that proper cross-WG reviews have occurred. WG] Cross-WG reviews haven't occurred, but we view MPLS's active participan= ts as a superset of the participants of most of the MPLS-dependent WGs, and= also a good source of cross-WG generalists and experts on MPLS. It's uncle= ar to me what needs should be evaluated by the operations-focused WGs, give= n that the issue came from a problem that an actual operator experienced (n= amely, me) and I don't think that the need for MPLS to work on an IPv6-only= or IPv6-primary network is particularly controversial anyway. If people be= lieve that there isn't enough overlap, we can certainly solicit reviews fro= m some of the other WGs involved. Awaiting AD/WG chair guidance. I don't think it's controversial either. You did a better job explaining m= y point: the need for this work "came from a problem that an actual operato= r experienced". But I agree with you about the overlap in participation an= d yield to whatever the AD/WG chair suggest. We've discussed this question about whether to publish a gap analysis at al= l somewhat offline, but I'm including a few points for the record and for W= G comment here. First, my expectation is that the gap analysis shouldn't proceed to RFC unt= il a consensus exists that we have reasonably captured all of the existing = gaps. In other words, this is a documentation of all of the gaps that we as= a collective group of the Smart People Who Know About Such Things could th= ink of, and explicit documentation of areas without gaps to confirm that we= reviewed them to validate this. New gaps SHOULD NOT develop, as once a gap= analysis like this is performed, it raises awareness so that people in the= WG (and ADs) will ask of future work, "does this work on an IPv6-only MPLS= network, does it depend on known gaps documented in RFCnnnn being addresse= d, or are additional changes necessary to make this work properly on IPv6-o= nly?" Second, I think this generally highlights a problem IETF-wide when it comes= to gap analyses. Either the work is already in progress, and it serves as = a method to catalog the issues to make sure we have them all being addresse= d, or it serves to identify places where future work is needed. The problem= is that the IETF has no method defined to follow up on gap analyses to ens= ure that future work identified actually gets completed, short of the WG ad= ding items to its charter to explicitly address these things. If the gap an= alysis spans WGs, or there isn't anyone interested in addressing the identi= fied gap, it can sort of rot inside the analysis and gradually be forgotten= . We're dealing with this question in sunset4 on the original set of IPv6 g= ap analyses that were done on RFCs 3790-96, because no one has a good sense= for whether all of the gaps identified in those documents were addressed, = or are indeed still relevant. This draft catalogs gaps with pointers to whe= re the authors know there is already work being done, which serves to link = the two, and ensures that it's as clear as possible where there are still o= utstanding gaps that need to be addressed, and it'd be reasonable to expect= any follow-on documents that address gaps identified as TBD in this docume= nt to formally update this document so that the link is present between thi= s document and the future documents addressing some of the gaps that it ide= ntified as not having fixes in progress. It's the best we can do with "froz= en in time" documents like this, but I think it's acceptable. Ultimately, I think your question is a larger issue and this gap analysis i= s no different than any other =96 the question of "should we publish" is re= ally "should we publish any gap analysis as an RFC given the limitations of= the series?" and that's not something we're going to solve here, so I thin= k it's a matter of publishing the document if the content is helpful. I agree with pretty much everything [*] you wrote..specially the part about= it being a wider issue that we're not going to solve here =97 and that sho= uldn't stop this work. As I said at the beginning, I defer to the current = consensus. The summary of our offline discussion is very good. I do want to bring up = one point that you mentioned there: " WG] Given that these sorts of documents are ultimately snapshots in time, w= e are including everything that we know about, but we do have to be clear a= bout the limits of what that means. We as the authors made the decision to = limit that to existing RFCs, because if we open it to any drafts in progres= s, we end up not having a decent line to draw about when to declare things = done =96 which drafts do we wait for, do we hold the doc because a new draf= t showed up that we need to evaluate, etc etc. I'm open to suggestions abou= t alternate methods of defining that line, but it's a lot harder to analyze= standards that are still fluid because they're actively being refined by t= he WG =96 is a gap in a draft really a gap, or is it simply a problem that = must be addressed before the thing that draft is standardizing is actually = ready to move to RFC? I think it's the latter, and that a gap is something = that exists in a standard that has already been completed because it can't = be updated to address that gap without a new draft, while an existing draft= can be modified to address the issue with minimal effort. " I fully agree with you: the line for identifying gaps should be based on RF= Cs (not drafts). [*] The part that I don't agree with is related to this line and the last c= ouple of sentences of your second point above: "This draft catalogs gaps wi= th pointers to where the authors know there is already work being done, whi= ch serves to link the two, and ensures that it's as clear as possible where= there are still outstanding gaps that need to be addressed, and it'd be re= asonable to expect any follow-on documents that address gaps identified as = TBD in this document to formally update this document so that the link is p= resent between this document and the future documents addressing some of th= e gaps that it identified as not having fixes in progress. It's the best we= can do with "frozen in time" documents like this, but I think it's accepta= ble." Following your logic ("is a gap in a draft really a gap"), I don't think th= at a draft can categorically be referred to as solving a gap. While we wou= ld hope that the draft progresses as expected and that it does address the = gap..it may end up not covering it, being abandoned, moving in a different = direction, etc. I understand the reasoning behind pointing at the work in progress. This d= iscussion is one of those where there might be no ideal answer and we both = might be right (at least in part). I wanted to bring this point up for the= record..and in case anyone has a brilliant solution. We don't need to dwe= ll on this.. . . . * The introduction to the draft talks about "gaps that must be addresse= d in order to allow MPLS-related protocols and applications to be used with= IPv6-only networks" ("IPv6-only (no IPv4 provisioned on the device)"), whi= ch gives the impression that no IPv4 is present in the network at all. Ho= wever, several gaps are identified that occur in "mixed" networks, where is= lands of IPv4/IPv6 exist. I would suggest clarifying the scope of the docu= ment in the introduction. Some of the places where these scenarios are dis= cussed include: 3.2.2. (Multipoint LDP), 3.3.2. (L3VPN), 3.4.1. (Extended= ICMP) and 3.4.2. (LSP Ping). WG] a few sentences before, the document says "any networks will need to st= art operating some or all of their network nodes either as primarily IPv6 (= most functions use IPv6, a few legacy features use IPv4), or as IPv6-only (= no IPv4 provisioned on the device)" Do we simply need to add similar langua= ge to the next-to-last sentence, does the existing text make it clear now t= hat I've highlighted it, or is more required? I think you should add similar language to the next-to-last sentence; that = is where you're describing what this document is doing. The text before it = is ok, but it seems to provide some context on what's happening as people a= re moving..not defining the scope. Thanks! Alvaro. --_000_D01B67B26749Baretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 8/20/14 11:38 AM, "George, Wes" <wesley.george@twcable.com> wrote:

Wes:

Hi!

Some comments in line..

Alvaro, thank you for the thorough review. Please find my responses be= low inline on behalf of the author team. We have an update in the edit buff= er, awaiting a few updates to the EVPN section and possibly the L2VPN secti= on (to incorporate any necessary discussion of RFC 7117), but I wanted to go ahead and respond now that mos= t of the comments have been addressed in our edits at least. 

Thanks,

 

Wes George

 

From: "Alvaro Retana (aretana)= " <aretana@cisco.com> Date: Tuesday, August 5, 2014 at 2:= 44 PM
To: "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.or= g" <dr= aft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: [mpls] RtgDir review: draf= t-ietf-mpls-ipv6-only-gap-01

Comments:

I do have a couple of high-level items I want to bring up.  Because I = assume that these may have already been discussed in the appropriate WG(s) = I'm not listing them as major issues, and will defer to what the consensus = has been so far.
  1. Why do we need to publish this document?  As I said above, I belie= ve the work is valuable, but it captures the state in time (today!) of the = gaps =97 it points to work that already solved a potential gap, or is in th= e process of solving them.  A significant portion of the gaps are already being addressed.  Given the importanc= e of IPv6, if published, soon this document will have to be updated to say = "nothing breaks".  Again, the work is important, but it may = be better suited to be a "living document" as a guide for what still needs to be addressed.  If it is to be published, I wo= uld suggest avoiding links to work in progress, but limiting the content to= identifying the gaps..and then letting the solution drafts/RFCs point back= to this document..  (ala requirements -> solution)
  2. It is interesting to me that this draft came throu= gh the mpls WG, and not one of the operations-focused groups..which presuma= bly would be in a better position to evaluate the needs described.  Gi= ven that the document is already in WG Last Call, I'm assuming that the alignment has already been discussed and that proper cross-WG rev= iews have occurred.
WG] Cross-WG reviews haven't occurred, but we view MPLS's active parti= cipants as a superset of the participants of most of the MPLS-dependent WGs= , and also a good source of cross-WG generalists and experts on MPLS. It's = unclear to me what needs should be evaluated by the operations-focused WGs, given that the issue came from= a problem that an actual operator experienced (namely, me) and I don't thi= nk that the need for MPLS to work on an IPv6-only or IPv6-primary network i= s particularly controversial anyway. If people believe that there isn't enough overlap, we can certainly solici= t reviews from some of the other WGs involved. Awaiting AD/WG chair guidanc= e.

I don't think it's controversial either.  You did a better job ex= plaining my point: the need for this work "came from a problem that an= actual operator experienced".  But I agree with you about the ov= erlap in participation and yield to whatever the AD/WG chair suggest.


We've discussed this question about whether to publish a gap analysis = at all somewhat offline, but I'm including a few points for the record and = for WG comment here.

First, my expectation is that the gap analysis shouldn't proceed to RF= C until a consensus exists that we have reasonably captured all of the exis= ting gaps. In other words, this is a documentation of all of the gaps that = we as a collective group of the Smart People Who Know About Such Things could think of, and explicit docum= entation of areas without gaps to confirm that we reviewed them to validate= this. New gaps SHOULD NOT develop, as once a gap analysis like this is per= formed, it raises awareness so that people in the WG (and ADs) will ask of future work, "does this work o= n an IPv6-only MPLS network, does it depend on known gaps documented in RFC= nnnn being addressed, or are additional changes necessary to make this work= properly on IPv6-only?" 

Second, I think this generally highlights a problem IETF-wide when it = comes to gap analyses. Either the work is already in progress, and it serve= s as a method to catalog the issues to make sure we have them all being add= ressed, or it serves to identify places where future work is needed. The problem is that the IETF has no me= thod defined to follow up on gap analyses to ensure that future work identi= fied actually gets completed, short of the WG adding items to its charter t= o explicitly address these things. If the gap analysis spans WGs, or there isn't anyone interested in address= ing the identified gap, it can sort of rot inside the analysis and graduall= y be forgotten. We're dealing with this question in sunset4 on the original= set of IPv6 gap analyses that were done on RFCs 3790-96, because no one has a good sense for whether all of t= he gaps identified in those documents were addressed, or are indeed still r= elevant. This draft catalogs gaps with pointers to where the authors know t= here is already work being done, which serves to link the two, and ensures that it's as clear as possible w= here there are still outstanding gaps that need to be addressed, and it'd b= e reasonable to expect any follow-on documents that address gaps identified= as TBD in this document to formally update this document so that the link is present between this document and= the future documents addressing some of the gaps that it identified as not= having fixes in progress. It's the best we can do with "frozen in tim= e" documents like this, but I think it's acceptable. 

Ultimately, I think your question is a larger issue and this gap analy= sis is no different than any other =96 the question of "should we publ= ish" is really "should we publish any gap analysis as an RFC g= iven the limitations of the series?" and that's not something we're go= ing to solve here, so I think it's a matter of publishing the document if t= he content is helpful. 

I agree with pretty much everything [*] you wrote..specially the part = about it being a wider issue that we're not going to solve here =97 and tha= t shouldn't stop this work.  As I said at the beginning, I defer to th= e current consensus.


The summary of our offline discussion is very good.  I do want to= bring up one point that you mentioned there:

"
WG] Given that these sorts of documents are ultimately snapshots in ti= me, we are including everything that we know about, but we do have to be cl= ear about the limits of what that means. We as the authors made the decisio= n to limit that to existing RFCs, because if we open it to any drafts in progress, we end up not having a de= cent line to draw about when to declare things done =96 which drafts do we = wait for, do we hold the doc because a new draft showed up that we need to = evaluate, etc etc. I'm open to suggestions about alternate methods of defining that line, but it's a lot harder to an= alyze standards that are still fluid because they're actively being refined= by the WG =96 is a gap in a draft really a gap, or is it simply a problem = that must be addressed before the thing that draft is standardizing is actually ready to move to RFC? I thin= k it's the latter, and that a gap is something that exists in a standard th= at has already been completed because it can't be updated to address that g= ap without a new draft, while an existing draft can be modified to address the issue with minimal effort.&n= bsp;
"

I fully agree with you: the line for identifying gaps should be based = on RFCs (not drafts).

[*] The part that I don't agree with is related to this line and the l= ast couple of sentences of your second point above: "This draft catalo= gs gaps with pointers to where the authors know there is already work being= done, which serves to link the two, and ensures that it's as clear as possible where there are still outstandi= ng gaps that need to be addressed, and it'd be reasonable to expect any fol= low-on documents that address gaps identified as TBD in this document to fo= rmally update this document so that the link is present between this document and the future documents address= ing some of the gaps that it identified as not having fixes in progress. It= 's the best we can do with "frozen in time" documents like this, = but I think it's acceptable."

Following your logic ("is a gap in a draft really a gap"), I= don't think that a draft can categorically be referred to as solving a gap= .  While we would hope that the draft progresses as expected and that = it does address the gap..it may end up not covering it, being abandoned, moving in a different direction, etc.

I understand the reasoning behind pointing at the work in progress. &n= bsp;This discussion is one of those where there might be no ideal answer an= d we both might be right (at least in part).  I wanted to bring this p= oint up for the record..and in case anyone has a brilliant solution.  We don't need to dwell on this..

. . .


  • The introduction to the dr= aft talks about "gaps that must be addressed in order to allow MPLS-re= lated protocols and applications to be used with IPv6-only networks&qu= ot; ("IPv6-only (no IPv4 provisioned on the device)"), which gives the impression that no IPv4 is present in the network at all. =   However, several gaps are identified that occur in "mixed&= quot; networks, where islands of IPv4/IPv6 exist.  I would suggest cla= rifying the scope of the document in the introduction.  Some of the places where these scenarios are discussed include:  3.2.2. (M= ultipoint LDP), 3.3.2. (L3VPN),  3.4.1. (Extended ICMP) and = 3.4.2. (LSP Ping).

WG] a few sentences before,= the document says "any networks will need to start operating some or = all of their network nodes either as primarily IPv6 (most functions use IPv= 6, a few legacy features use IPv4), or as IPv6-only (no IPv4 provisioned on the device)" Do we simply need t= o add similar language to the next-to-last sentence, does the existing text= make it clear now that I've highlighted it, or is more required?

I think you should add similar language to the next-to-last sentence; = that is where you're describing what this document is doing. The text befor= e it is ok, but it seems to provide some context on what's happening as peo= ple are moving..not defining the scope.

Thanks!

Alvaro.

--_000_D01B67B26749Baretanaciscocom_-- From nobody Thu Aug 21 12:53: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 48D2A1A6FDD; Thu, 21 Aug 2014 12:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, 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 UOjD0H0DN_rF; Thu, 21 Aug 2014 12:52:52 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0011.outbound.protection.outlook.com [213.199.154.11]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E35A1A86F2; Thu, 21 Aug 2014 12:52:42 -0700 (PDT) Received: from AM3PR03MB612.eurprd03.prod.outlook.com (10.242.110.144) by AM3PR03MB610.eurprd03.prod.outlook.com (10.242.109.27) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Thu, 21 Aug 2014 19:52:38 +0000 Received: from AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) by AM3PR03MB612.eurprd03.prod.outlook.com ([10.242.110.144]) with mapi id 15.00.1010.016; Thu, 21 Aug 2014 19:52:38 +0000 From: Alexander Vainshtein To: Jeffrey Haas Thread-Topic: [RTG-DIR] Please start using the Document QA process now Thread-Index: AQHPvIVzIcIW9iqMuEO18Y4aSTFod5vbGocAgAALwGWAAAVBAIAABhxYgAAASXCAAAy0gIAAOYKq Date: Thu, 21 Aug 2014 19:52:38 +0000 Message-ID: <1408650750780.83304@ecitele.com> References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com>, <20140821162035.GM30106@pfrc> In-Reply-To: <20140821162035.GM30106@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [5.153.9.203] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0310C78181 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(377454003)(189002)(199003)(24454002)(66066001)(101416001)(80022001)(46102001)(71446004)(77982001)(76482001)(81542001)(79102001)(50986999)(76176999)(2656002)(64706001)(20776003)(54356999)(99396002)(105586002)(87936001)(4396001)(85852003)(36756003)(117636001)(83322001)(19580405001)(19580395003)(83072002)(110136001)(74502001)(107046002)(95666004)(81342001)(85306004)(31966008)(21056001)(74662001)(93886004)(106356001)(86362001)(92726001)(92566001)(106116001)(90102001); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR03MB610; H:AM3PR03MB612.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/HU45AWwRtkbQvVGc-zkjwih3Okc Cc: "rtg-dir@ietf.org" , Christian Hopps , Sandra Murphy , Alia Atlas , "rtg-chairs@ietf.org" , Lou Berger Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 19:52:58 -0000 Jeff,=0A= Lots of thanks for a prompt response.=0A= =0A= I agree with you that some people are ready to push it through the text tha= t is really difficult to read.=0A= But this does not happen frequently IMO - and not because the majority of t= he drafts are well-written!=0A= =0A= The result in many cases is that people simply do not care.=0A= =0A= Having somebody assigned to read and review the document helps IMO. And som= etimes his/her comments eventually result in a document that is much easier= to read and understand, so that the WG consensus could be based on actual = understanding what the draft is about and not just on default.=0A= =0A= My 2c,=0A= Sasha =0A= =0A= ________________________________________=0A= From: Jeffrey Haas =0A= Sent: Thursday, August 21, 2014 7:20 PM=0A= To: Alexander Vainshtein=0A= Cc: Jeffrey Haas; Sandra Murphy; rtg-dir@ietf.org; Lou Berger; rtg-chairs@i= etf.org; Alia Atlas; Christian Hopps=0A= Subject: Re: [RTG-DIR] Please start using the Document QA process now=0A= =0A= Sasha,=0A= =0A= On Thu, Aug 21, 2014 at 03:39:14PM +0000, Alexander Vainshtein wrote:=0A= > Jeffrey,=0A= > A na?ve question:=0A= > If a document is "difficult to read and review" (no matter at what stage)= , how can the WG understand/reach consensus that it is "of interesting te= chnical content "?=0A= =0A= It seems to happen. Some people seem willing to push through difficult=0A= language or confusing syntax anyway.=0A= =0A= Improving the quality of the document *before* the call to adopt means the= =0A= document can get better discussion and easier review during adoption.=0A= =0A= Once a document has been adopted, the audience is wider.=0A= =0A= -- Jeff=0A= From nobody Thu Aug 21 13:04: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 C747F1A06CD; Thu, 21 Aug 2014 13:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 melHYDzFDWxg; Thu, 21 Aug 2014 13:03:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BCD101A0678; Thu, 21 Aug 2014 13:03:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=64.112.195.202; From: "Susan Hares" To: "'Alia Atlas'" References: <53F5FE0A.4080205@labn.net> <8057BCA2-4A11-4EB6-8728-D6EE0E38A6CB@tislabs.com> <53F60C4E.60607@labn.net> <5F27EC18-88D4-4898-9523-33F2351BF553@rawdofmt.org> <20140821153356.GL30106@pfrc> <4b6b9432c8074f49b271762e4c88dcf0@AM3PR03MB612.eurprd03.prod.outlook.com> <3efca289e0964654bc999900a42cb22b@CO2PR05MB636.namprd05.prod.outlook.com> <53F61C4E.5020306@labn.net> In-Reply-To: Date: Thu, 21 Aug 2014 16:03:52 -0400 Message-ID: <02cd01cfbd7b$084d6270$18e82750$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CE_01CFBD59.813CD3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH8PGqJ4wPvLLPnlBfucEcKiFbZegGxCjieAailISwBuracKgEfcd7xAp+4JdEB6uYttAIvB9LQA3Ys8uQClnF3AAKThmlsmtYNQCA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/_ZyZXfB-pYO6bTtrRTt_7rqFyOY Cc: 'Ross Callon' , rtg-dir@ietf.org, 'Christian Hopps' , rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Please start using the Document QA process now 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, 21 Aug 2014 20:03:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CE_01CFBD59.813CD3E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alia=20 =20 IDR has a draft that is in WG adoption call now, but early comments have = caused the author to re-spin the draft. =20 =20 Three questions:=20 =20 1) Should I wait until the authors re-spin the draft to ask for the = reviewer or give a heads up to Deborah and Jonathan on the draft?=20 =20 2) In my own personal reviewing of the draft, I have found existing = drafts in L2VPN and IDR utilizing BGP solutions with 80-90% overlap. I = have also found an RFC approved by Softwires and not cross-reviewed in = IDR. Should I prepare a background scenario to go with the draft for = the reviewer?=20 =20 3) The authors of this draft have asked for early allocation. Will = the reviewer be ready to reply for the early allocation as well as WG = Adoption and WG LC.=20 =20 =20 Sue Hares =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Thursday, August 21, 2014 12:32 PM To: Lou Berger Cc: Ross Callon; rtg-dir@ietf.org; Christian Hopps; rtg-chairs@ietf.org Subject: Re: [RTG-DIR] Please start using the Document QA process now =20 On Thu, Aug 21, 2014 at 12:20 PM, Lou Berger wrote: On 8/21/2014 11:53 AM, Ross Callon wrote: > If we think of the review this way, then it does not actually add = delay or more process to the existing IETF process, but it just makes it = more likely that for each document at least some portion of our experts = will actually do what we already want them to do. Sounds like the reviewer really needs to be active in the WG then and not just reviewing for document quality... =20 While it is desirable to have active WG participants review a draft, = that "should" happen because the draft is of interest and relevant. = The WG Document QA process is NOT trying to fix that problem. =20 The WG Document QA is trying to get the cross-WG perspective via early = directorate review when issues can still be easily fixed. =20 Of course, more reviews by experienced participants is desirable - but = that's part of having a WG with energy and drafts in the design center. = Sometimes that comes by kicking (s/kicking/asking) people individually = to do reviews. =20 Alia ------=_NextPart_000_02CE_01CFBD59.813CD3E0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Alia

 

IDR has a draft that is in WG adoption call now, but early comments = have caused the author to re-spin the draft.=C2=A0=C2=A0 =

 

Three questions:

 

1)      = Should I wait until the authors re-spin the draft to ask for the = reviewer or give a heads up to Deborah and Jonathan on the draft? =

 

2)      = In my own personal reviewing of the draft, I have found existing = drafts in L2VPN and IDR utilizing BGP solutions with 80-90% = overlap.=C2=A0 I have also found an RFC approved by Softwires and not = cross-reviewed in IDR.=C2=A0=C2=A0 Should I prepare a background = scenario to go with the draft for the reviewer?

 

3)      = The authors of this draft have asked for early allocation. =C2=A0Will = the reviewer be ready to reply for the early allocation as well as WG = Adoption and WG LC.

 

 

Sue Hares

 

From:= = Alia Atlas [mailto:akatlas@gmail.com]
Sent: Thursday, August = 21, 2014 12:32 PM
To: Lou Berger
Cc: Ross Callon; = rtg-dir@ietf.org; Christian Hopps; = rtg-chairs@ietf.org
Subject: Re: [RTG-DIR] Please start using = the Document QA process now

 

On Thu, Aug 21, 2014 at 12:20 PM, Lou Berger <lberger@labn.net> wrote:


On 8/21/2014 11:53 AM, Ross Callon = wrote:
>  If we think of the review this way, then it does = not actually add delay or more process to the existing IETF process, but = it just makes it more likely that for each document at least some = portion of our experts will actually do what we already want them to = do.

Sounds like the reviewer = really needs to be active in the WG then and
not just reviewing for = document quality...

 

While it is desirable to have active WG participants = review a draft, that "should" happen because the draft is of = interest  and relevant.   The WG Document QA process is NOT = trying to fix that problem.

 

The WG Document QA is trying to get the cross-WG = perspective via early directorate review when issues can still be easily = fixed.

 

Of course, more reviews by experienced participants is = desirable - but that's part of having a WG with energy and drafts in the = design center.  Sometimes that comes by kicking (s/kicking/asking) = people individually to do reviews.

 

Alia

------=_NextPart_000_02CE_01CFBD59.813CD3E0-- From nobody Fri Aug 22 08:39: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 4DD2E1A0688; Thu, 21 Aug 2014 17:57:33 -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 BPtdPIDJfbvs; Thu, 21 Aug 2014 17:57:31 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B5C1A0655; Thu, 21 Aug 2014 17:57:31 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so5494560iec.25 for ; Thu, 21 Aug 2014 17:57:31 -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=jh5vDOmubQkWtOAbwZOD9moqrC5roK+9TJsA7V42j5U=; b=vkTMEamQhXUsZxyBymi14Ul68xlQafvVvMs8dGAhNqh3GPRg/+1vCfdMuU25Wjbdre VQcE/QMfMM3Ddk2IN3mN8hb/kypcWVWqASxrOYg67f46xMKcffWcdDGAh7oXXNX7UzVf 7tRV4pZ7sfzZijyt41/W40RC0GeDJgimH6M9GlNnnItZRkiz7SGsc0ocvOkW8Ad4BNca UXeMq1QG176QvqefGrUE/N+AGxL0NJxG/4uXZn+QVVJU/f9O1Q3lS71NC6Yn/LM18u4/ 5QS1arH7ogikOAtEnhITEqEYsDTAKt11iIgsykkmCPJx+/9qdqdlgbu8nTK+hS1fW8+E dMNA== MIME-Version: 1.0 X-Received: by 10.42.35.8 with SMTP id o8mr6631756icd.41.1408669050975; Thu, 21 Aug 2014 17:57:30 -0700 (PDT) Received: by 10.50.189.170 with HTTP; Thu, 21 Aug 2014 17:57:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 06:27:30 +0530 Message-ID: From: Dhruv Dhody To: "Alvaro Retana (aretana)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/DQ6xqgUxVPJOdfs27M3QwsMhD6I X-Mailman-Approved-At: Fri, 22 Aug 2014 08:39:06 -0700 Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "George, Wes" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 00:57:33 -0000 Hi Alvaro, Wes, > I fully agree with you: the line for identifying gaps should be based on > RFCs (not drafts). > > [*] The part that I don't agree with is related to this line and the last > couple of sentences of your second point above: "This draft catalogs gaps > with pointers to where the authors know there is already work being done, > which serves to link the two, and ensures that it's as clear as possible > where there are still outstanding gaps that need to be addressed, and it'd > be reasonable to expect any follow-on documents that address gaps identified > as TBD in this document to formally update this document so that the link is > present between this document and the future documents addressing some of > the gaps that it identified as not having fixes in progress. It's the best > we can do with "frozen in time" documents like this, but I think it's > acceptable." > > Following your logic ("is a gap in a draft really a gap"), I don't think > that a draft can categorically be referred to as solving a gap. While we > would hope that the draft progresses as expected and that it does address > the gap..it may end up not covering it, being abandoned, moving in a > different direction, etc. > > I understand the reasoning behind pointing at the work in progress. This > discussion is one of those where there might be no ideal answer and we both > might be right (at least in part). I wanted to bring this point up for the > record..and in case anyone has a brilliant solution. We don't need to dwell > on this.. How about we move the pointers to any work-in-progress to address the gaps to appendix, would that be a good compromise? Dhruv From nobody Fri Aug 22 09:43: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 97DC91A0502; Fri, 22 Aug 2014 09:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 Zt5YcF84Ait9; Fri, 22 Aug 2014 09:43:44 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B893A1A0494; Fri, 22 Aug 2014 09:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3508; q=dns/txt; s=iport; t=1408725823; x=1409935423; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k4XirlTqgm/7qaDH9V9HfgW1+Ui4VulkyZm8zFqScl4=; b=WiP+pK1+71N5kU/BCFx1pn7gmu9kJdtKyt+TB+IH5okYvfN9PA57BypI Qo6AUhAAbkcttJiSOzlKUVAE4eYgCOAY9mtyOpdgCkhA3H9/OeCN209yA Q9b3S5pueXtU0enrSsOWqSQpL6XtgNIMTsibCFSWB1TviTHGZm+xsu3vl 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAGpy91OtJV2b/2dsb2JhbABZgmojgSoE1CYBgQ8Wd4QDAQEBBHkMBAIBCBEDAQIvIREdCAEBBAENBRuIEwMRAb81DYUZF4l/gyCBejMHBoRGAQSHSIMehC2CE4kTghCOV4Y1g15sAYFHgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71566752" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP; 22 Aug 2014 16:43:42 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7MGhgDl031264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 16:43:42 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 11:43:42 -0500 From: "Carlos Pignataro (cpignata)" To: Dhruv Dhody , "Alvaro Retana (aretana)" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogA== Date: Fri, 22 Aug 2014 16:43:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.102.157.31] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/4t0ye13jLZI2AapSLIe8l3zFGPo Cc: "rtg-dir@ietf.org" , "mpls@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "George, Wes" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 16:43:45 -0000 -----Original Message----- From: Dhruv Dhody Date: Thursday, August 21, 2014 at 8:57 PM To: Alvaro Retana Cc: Wes George , "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Resent-From: Resent-To: Carlos Pignataro , Loa Andersson , Martin Vigoureux , Ross Callon , , Wes George , Alia Atlas , Adrian Farrel Resent-Date: Thursday, August 21, 2014 at 8:57 PM >Hi Alvaro, Wes, > >> I fully agree with you: the line for identifying gaps should be based on >> RFCs (not drafts). >> >> [*] The part that I don't agree with is related to this line and the >>last >> couple of sentences of your second point above: "This draft catalogs >>gaps >> with pointers to where the authors know there is already work being >>done, >> which serves to link the two, and ensures that it's as clear as possible >> where there are still outstanding gaps that need to be addressed, and >>it'd >> be reasonable to expect any follow-on documents that address gaps >>identified >> as TBD in this document to formally update this document so that the >>link is >> present between this document and the future documents addressing some >>of >> the gaps that it identified as not having fixes in progress. It's the >>best >> we can do with "frozen in time" documents like this, but I think it's >> acceptable." >> >> Following your logic ("is a gap in a draft really a gap"), I don't think >> that a draft can categorically be referred to as solving a gap. While >>we >> would hope that the draft progresses as expected and that it does >>address >> the gap..it may end up not covering it, being abandoned, moving in a >> different direction, etc. >> >> I understand the reasoning behind pointing at the work in progress. >>This >> discussion is one of those where there might be no ideal answer and we >>both >> might be right (at least in part). I wanted to bring this point up for >>the >> record..and in case anyone has a brilliant solution. We don't need to >>dwell >> on this.. > >How about we move the pointers to any work-in-progress to address the >gaps to appendix, would that be a good compromise? I agree with Alvaro=B9s point that a draft cannot be checked as the solutio= n of a gap. I also believe there is no perfect answer to this one. There is, however, another way in which draft-ietf-mpls-ipv6-only-gap points to I-Ds: As a very detailed description of a Gap. draft-ietf-mpls-ipv6-only-gap might have one paragraph / couple sentences describing a gap, and then point to an I-D that details the gap (and might or might not propose solutions). In this context, there might not be one-size-fit-all for the I-D references. I would not want to loose the consolidated references, but perhaps we need to be more precise about a why we are pointing to each I-D. Pointing as expanding the gap is OK, and maybe moving the =B3solution I-Ds=B2 to an Appendix is a good idea. Thanks, Carlos. > >Dhruv From nobody Fri Aug 22 10:14: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 065751A0693; Fri, 22 Aug 2014 10:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 bBozvzBS3_Tj; Fri, 22 Aug 2014 10:14:29 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655471A069E; Fri, 22 Aug 2014 10:14:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3770; q=dns/txt; s=iport; t=1408727670; x=1409937270; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yp1MEH28LENClKIlK40N5x8shm7TIw6s3j7SIhjzaOE=; b=a/P1gSR6Fgl5iUA9qaGE9+ZDDI/IXv71h1ktATi24Zp/QFSjPqBfG2vb zlK96EgvVo8kuxJtO5T1a22G1fY3nUR9rMwarb3AjC3Z7jck/6CXYgIgw fzED2PnSbMc9gbyKn4AUCk1DdPXvDsAa4EXrYjIoBZJ8ZCMeU+YvEWxDF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAOh591OtJV2S/2dsb2JhbABZgmojgSoEgnjRLgEZdhZ3hAMBAQEENDgGBwwEAgEIEQMBAgUoAgIfER0IAQEEAQ0FG4gTAxEBkxKcNQaPcA2FGReBJot5gVwBARwIKwcCAgKCbYFZAQSGEYkCghOJE4IQjleGNYNebAGBDjmBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71576577" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP; 22 Aug 2014 17:14:30 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7MHESTv027459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 17:14:28 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 12:14:28 -0500 From: "Carlos Pignataro (cpignata)" To: "George, Wes" , Dhruv Dhody , "Alvaro Retana (aretana)" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PAA= Date: Fri, 22 Aug 2014 17:14:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.102.157.31] Content-Type: text/plain; charset="euc-kr" Content-ID: <22B90EF4592D864EB100537A9ED97E51@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Q9LutkBKfrUkbuPHgaaOziAyQqM Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 17:14:31 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiA8R2VvcmdlPiwgV2VzIEdlb3Jn ZSA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbT4NCkRhdGU6IEZyaWRheSwgQXVndXN0IDIyLCAy MDE0IGF0IDE6MDYgUE0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+ LCBEaHJ1diBEaG9keQ0KPGRocnV2LmlldGZAZ21haWwuY29tPiwgQWx2YXJvIFJldGFuYSA8YXJl dGFuYUBjaXNjby5jb20+DQpDYzogInJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmciIDxydGctYWRzQHRv b2xzLmlldGYub3JnPiwgInJ0Zy1kaXJAaWV0Zi5vcmciDQo8cnRnLWRpckBpZXRmLm9yZz4sICJk cmFmdC1pZXRmLW1wbHMtaXB2Ni1vbmx5LWdhcC5hbGxAdG9vbHMuaWV0Zi5vcmciDQo8ZHJhZnQt aWV0Zi1tcGxzLWlwdjYtb25seS1nYXAuYWxsQHRvb2xzLmlldGYub3JnPiwgIm1wbHNAaWV0Zi5v cmciDQo8bXBsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbXBsc10gUnRnRGlyIHJldmlldzog ZHJhZnQtaWV0Zi1tcGxzLWlwdjYtb25seS1nYXAtMDENCg0KPg0KPj4+SG93IGFib3V0IHdlIG1v dmUgdGhlIHBvaW50ZXJzIHRvIGFueSB3b3JrLWluLXByb2dyZXNzIHRvIGFkZHJlc3MgdGhlDQo+ Pj5nYXBzIHRvIGFwcGVuZGl4LCB3b3VsZCB0aGF0IGJlIGEgZ29vZCBjb21wcm9taXNlPw0KPj4N Cj4+SSB3b3VsZCBub3Qgd2FudCB0byBsb29zZSB0aGUgY29uc29saWRhdGVkIHJlZmVyZW5jZXMs IGJ1dCBwZXJoYXBzIHdlDQo+Pm5lZWQNCj4+dG8gYmUgbW9yZSBwcmVjaXNlIGFib3V0IGEgd2h5 IHdlIGFyZSBwb2ludGluZyB0byBlYWNoIEktRC4gUG9pbnRpbmcgYXMNCj4+ZXhwYW5kaW5nIHRo ZSBnYXAgaXMgT0ssIGFuZCBtYXliZSBtb3ZpbmcgdGhlIKn4c29sdXRpb24gSS1Ec6n3IHRvIGFu DQo+PkFwcGVuZGl4IGlzIGEgZ29vZCBpZGVhLg0KPg0KPkknbSBub3QgY29udmluY2VkIHRoYXQg bXVjaCB3aWxsIGJlIGdhaW5lZCBieSBzdWNoIGEgY2hhbmdlLiBJdCBzZWVtcyBsaWtlDQo+Y2hh bmdlIGZvciB0aGUgc2FrZSBvZiBjaGFuZ2UuIEkgd2lsbCBnbyBhbG9uZyB3aXRoIGl0IGlmIFdH IGNvbnNlbnN1cw0KPnB1c2hlcyB0aGF0IGRpcmVjdGlvbiwgYnV0IG15IHByZWZlcmVuY2Ugd291 bGQgYmUgdG8gbGVhdmUgdGhlIHJlZmVyZW5jZXMNCj5hcy1pcy4gSWYgd2Uga25vdyBzb21ldGhp bmcgaXMgaW4gcHJvZ3Jlc3MgdGhhdCBpcyB0cnlpbmcgdG8gYWRkcmVzcyB0aGUNCj5wcm9ibGVt LCB3aHkgbm90IGRvY3VtZW50IHdoYXQgd2Uga25vdyBpbiB0aGUgc2FtZSBwbGFjZXMgYXMgd2Ug ZGlzY3Vzcw0KPnRoZSBnYXBzPyBXaGF0IHZhbHVlIGlzIHRoZXJlIGluIGhpZGluZyB0aGVzZSB0 aGluZ3MgaW4gYW4gYXBwZW5kaXgganVzdA0KPmJlY2F1c2Ugd2UgYXJlbid0IGNvbXBsZXRlbHkg Y2VydGFpbiB0aGF0IHdoYXQgd2UgYmVsaWV2ZSB3aWxsIGFkZHJlc3MgdGhlDQo+Z2FwIHdpbGwg YWN0dWFsbHkgYWRkcmVzcyB0aGUgZ2FwPw0KDQpQZXJzb25hbGx5IEkgZG8gbm90IGhhdmUgYSBw YXJ0aWN1bGFyIHByZWZlcmVuY2UgYmV0d2VlbiBsZWF2aW5nIGNpdGF0aW9ucw0KdG8gSS1EcyB3 aGVyZSB0aGV5IGFyZSBvciBtb3ZpbmcgdGhlbSAoYXMgY28tZWRpdG9yIEkgcHJlZmVyIGxlYXZp bmcgdGhlbQ0Kd2hlcmUgdGhleSBhcmUgOi0pDQoNCkJ1dCB0aGUgcG9pbnQgSSB0aGluayBpcyBp bXBvcnRhbnQgdG8gY2xhcmlmeSBpbiB0aGUgZG9jdW1lbnQgaXMgd2hldGhlciBhDQpkcmFmdCBp cyByZWZlcmVuY2VkIGJlY2F1c2UgaXQgZGVzY3JpYmVzIGEgZ2FwIG9yIGJlY2F1c2UgaXQgZGVz Y3JpYmVzIGENCnBvdGVudGlhbCBzb2x1dGlvbiB0byBhIGdhcC4NCg0KVGhhbmtzLA0KDQpDYXJs b3MuDQoNCj4NCj5UaGFua3MsDQo+DQo+V2VzDQo+DQo+DQo+QW55dGhpbmcgYmVsb3cgdGhpcyBs aW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnmhr3MgbWFpbCBzZXJ2ZXIsIEkNCj5oYXZl IG5vIGNvbnRyb2wgb3ZlciBpdC4NCj4tLS0tLS0tLS0tLQ0KPg0KPg0KPg0KPlRoaXMgRS1tYWls IGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxl DQo+cHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCwgb3Igc3ViamVjdCB0bw0KPmNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIg Q2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVseQ0KPmZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdQ0K PmFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQNCj50aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNv cHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbg0KPnJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBh bmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkNCj5wcm9oaWJpdGVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluDQo+ ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50 bHkgZGVsZXRlIHRoZQ0KPm9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQg YW55IHByaW50b3V0Lg0KDQo= From nobody Fri Aug 22 11:48: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 BA6F21A040B; Fri, 22 Aug 2014 11:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 pX32SN0UVwNP; Fri, 22 Aug 2014 11:48:37 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 457E21A03C8; Fri, 22 Aug 2014 11:48:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=785; q=dns/txt; s=iport; t=1408733317; x=1409942917; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Q/9c7HwOn5rrvj4XyA/cScvpB6lTu1T2Fj7Fp46d7Aw=; b=cR9UUs9oB+WYWK1QIK7L/ulOlw1cqS08Klf8yX6zosVWEHyYhfFso3X7 Nlsn/RKZFjK6DCdDUlk5vtf9H23U/FMMA/2K6fn5FGxCVHzIQyt2mcg2o VRC6YuDPlt8yQTomrCJ4jIu2sv+vsFvq8ftTRcSyK3YSa1FDVR76/reXt E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFANGP91OtJA2K/2dsb2JhbABZgw2BKgTUJgGBEBZ3hAQBAQQ6PxACAQg2ECERJQIEAQ0FG4gTAxG/WQ2FGReNH4ItB4RMAQSPE4ITiROCEI5XhjWDXmyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71602794" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 22 Aug 2014 18:48:36 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7MImaBJ016067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 18:48:36 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.181]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 13:48:36 -0500 From: "Alvaro Retana (aretana)" To: Dhruv Dhody , "Carlos Pignataro (cpignata)" , "George, Wes" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PACAAEivgP//0YgA Date: Fri, 22 Aug 2014 18:48:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <4C4C96189218D7419FFE86ACD9AE3776@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/h5SfrntrLmcCl-qVHs_Rcfk09no Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 18:48:39 -0000 On 8/22/14 1:34 PM, "Dhruv Dhody" wrote: >we could explicitly state that the aim of the pointers in this >appendix is to let the reader note that there are some proposed >solutions in IETF, but they are work in progress and do not have >consensus at the time of publication. There could be other solutions >proposed at future time and the pointers should not be considered >normative in any way. Maybe we could make everyone happy if we add some "disclaimer" text (similar to what Dhruv wrote above). I'm thinking that it could go in Section 4 (Gap Summary) (no need for an appendix). This way we don't have to change the text anymore..we can leave the references as-is..and we address any potential mishap to the WIP. Thoughts? Alvaro. From nobody Fri Aug 22 11:51: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 3F7B01A0AD7; Fri, 22 Aug 2014 11:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 3Q6U1koDG8Ze; Fri, 22 Aug 2014 11:50:57 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178911A0AD2; Fri, 22 Aug 2014 11:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=531; q=dns/txt; s=iport; t=1408733458; x=1409943058; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+UQ/gVMB1+KAe7s93/sf7QcTrUw4GOD6E73w+vXovFw=; b=Yq4T1E5j6p0J8vqg72/zTq0upbH61WFaBi63ZGe9G2nBD4fTzdjgjZoN m95iuV22+vzWhRbZbbIn/7IvXlEQoDfKbN0nsCywJu/uR53FfSj2xCTE/ NdKaEHNht2nSS+7HWzYg1reLZ7tVggxnwlPZpjKFfNh6m9p3UU6JBynXy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAGmQ91OtJA2G/2dsb2JhbABZgw2BLtQmAYEQFneEBAEBBDo/EAIBCDYQMiUCBA6IR8UBF49MB4RMAQSPE4ITiyOVDINegjSBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,382,1406592000"; d="scan'208";a="71600730" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP; 22 Aug 2014 18:50:58 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7MIouKK020334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 18:50:56 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.181]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 13:50:56 -0500 From: "Alvaro Retana (aretana)" To: "Carlos Pignataro (cpignata)" , "George, Wes" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PACAABrfgA== Date: Fri, 22 Aug 2014 18:50:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <1ECCA331166C3D4F9E0C72EAB08D4835@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/WMekPc1F-iJjSCKWzPwH5FOEm88 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 18:50:58 -0000 Carlos/Wes: BTW, as I was taking another look at the -01 text (I know you have edits ready to commit), there's a couple more minor comments related to the references: 1. 3.2.1. (LDP) "Gap: Major, update to RFC 5036 in progress that should close this gap." The in-line reference points to rfc5036, but it should point to I-D.ietf-mpls-ldp-ipv6. 2. 3.5. (MIBs) "Gap: Major. Work underway to update RFC3811.." Same thing, the reference to the update should point to I-D.manral-mpls-rfc3811bis. Thanks! Alvaro. From nobody Fri Aug 22 12:41: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 0C8721A061D; Fri, 22 Aug 2014 12:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 Qt4KJP8c9YYD; Fri, 22 Aug 2014 12:41:13 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B981A058E; Fri, 22 Aug 2014 12:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1387; q=dns/txt; s=iport; t=1408736473; x=1409946073; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CW4M5oPv5ijrCzERn0VLc3zaf4XySgC4jFedEKb0YVo=; b=ls1SLHUCAiut96D/dNo/T2pZqAik56BO9qu2Q6pI5MRoOfkaRXrUzj8x HOyD/8ZPsSsekOUmSlQXVG1qi+90J/hpAOxHwKYHiOOmB+r1ZabLNXFIm 1heRBHVR3Zb2l13fpLRmc65TGNTWUGxsYmD6dPuo6m+Qip4CGbJyReYvr s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAP2b91OtJA2E/2dsb2JhbABZgmojgSoE1CcBgRAWd4QDAQEBBDo/DAQCAQgRAwECAR4QIREdCAIEAQ0FG4gTAxEBv1cNhRkXjR+CLQcGhEYBBI8TghOJE4IQjleGNYNebAGBR4EHAQEB X-IronPort-AV: E=Sophos;i="5.04,383,1406592000"; d="scan'208";a="71610336" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 22 Aug 2014 19:41:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s7MJfCwg007047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 19:41:12 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 14:41:12 -0500 From: "Carlos Pignataro (cpignata)" To: "Alvaro Retana (aretana)" , Dhruv Dhody , "George, Wes" Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac+8jNhDJV9wXHg8TGujGdgCLK4CYQA4R/uAABf/TQAAGKwogAAJK2EA//+/PACAAEivgP//0YgAgAAOyAA= Date: Fri, 22 Aug 2014 19:41:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [64.102.157.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/s45F_9itG9c8985oLGWqN3m03Ok Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 19:41:15 -0000 -----Original Message----- From: Alvaro Retana Date: Friday, August 22, 2014 at 2:48 PM To: Dhruv Dhody , Carlos Pignataro , Wes George Cc: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 >On 8/22/14 1:34 PM, "Dhruv Dhody" wrote: > >>we could explicitly state that the aim of the pointers in this >>appendix is to let the reader note that there are some proposed >>solutions in IETF, but they are work in progress and do not have >>consensus at the time of publication. There could be other solutions >>proposed at future time and the pointers should not be considered >>normative in any way. > >Maybe we could make everyone happy if we add some "disclaimer" text >(similar to what Dhruv wrote above). I'm thinking that it could go in >Section 4 (Gap Summary) (no need for an appendix). > >This way we don't have to change the text anymore..we can leave the >references as-is..and we address any potential mishap to the WIP. > >Thoughts? Works for me. Thanks, Carlos. > >Alvaro. > From nobody Mon Aug 25 00:23: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 A59341A8AB1 for ; Mon, 25 Aug 2014 00:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vn4S5dfiu1nv for ; Mon, 25 Aug 2014 00:23:35 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992361A8AAD for ; Mon, 25 Aug 2014 00:23:35 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id w10so19801004pde.4 for ; Mon, 25 Aug 2014 00:23:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:from:to:cc:subject:date:organization :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=XKjshHwjCmTMt8eE8OuXPW0kNa7sbQTB80yVL7uQZX8=; b=giiC02annkwGs+Y3L52hylPg5hX6qvi5HcIwqHV3CSLEY7dgx2jQCDTNYAtY6q5JPl Sn9Kd++ksko3gZXgaRkB/BbOY2GCJGwxEsQJoKjhzQ5T99X9RSJYmFFXSDPbRvuDYuZo /lJjuDGxRh0VYENsQPxKaoA+8yuXg5ZOCN5rtfwhvEah6YwH/e7ST/D4odHdiOKihz96 nXRH7iQ3LkBma+ThLJMGYgorH04WapVRNoCFOxmmOXGGSCcJIv2AzIscIsOYpLmfBZZ0 QIHXNo/NSREPLT77UAzZQqGdHZ7oNZbYUGSXByWkYaP6AyGIUNF/WETCG1Z9IdMxfS12 u0wA== X-Gm-Message-State: ALoCoQnpWaLvy45GLT/yB6WtkIQN2JvWjx/mqIF90rLmQ+GXIlvkkGNPGeQrZ5XUJ1oaDLgfdJq5 X-Received: by 10.68.112.225 with SMTP id it1mr26422799pbb.23.1408951410760; Mon, 25 Aug 2014 00:23:30 -0700 (PDT) Received: from Manav ([106.51.35.4]) by mx.google.com with ESMTPSA id qt2sm36485106pbb.29.2014.08.25.00.23.28 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Aug 2014 00:23:29 -0700 (PDT) From: "Manav Bhatia" To: Date: Mon, 25 Aug 2014 12:53:28 +0530 Organization: Ionos Networks Message-ID: <087c01cfc035$7944b7a0$6bce26e0$@ionosnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/ANRK67CH0JXO9Q06MSDydQ/vMhA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/XMLYXeLHK3ttmFM9X_IOgqKmY6Q Cc: draft-ietf-roll-security-threat.all@tools.ietf.org, rtg-dir@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-security-threats-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: manav@ionosnetworks.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:23:37 -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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-ietf-roll-security-threats-09 Reviewer: Manav Bhatia Review Date: 25-08-14 IETF LC End Date: 28-08-14 Intended Status: Informational Summary: I have some concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: This document presents a threat analysis for securing the routing protocols used in LLNs which are more prone to packet losses and other vulnerabilities. It then discusses how those attacks/threats can be mitigated. Major Issues: (1) Sec 7.2.2. "Countering Overclaiming and Misclaiming Attacks" says that " counter to overclaiming and misclaiming may employ: comparison with historical routing/topology data;" I don't understand how this will work. Assume node A was always a leaf node and was never attached to any routing device. Later, a new router gets attached to this node. The node A now starts advertising this new router. How will the peers know whether it's a legitimate advertisement or an "overclaim" from node A? I don't agree with notion that somebody could look at the historical data to figure out if a router is over/under claiming. I also don't think it's a good idea to suggest that we "restrict realizable network topologies" to counter overclaim/misclaim attacks. (2) Sec 7.3.2 "Countering Overload Attacks" suggests that "overload attacks" can be countered by "isolate nodes which send traffic above a certain threshold based on system operation characteristics;". Has this been adequately discussed in the WG? It's certainly possible that in an event of reroute/reconvergence a certain node can momentarily get more traffic than the threshold. Ordinarily, such nodes only drop the additional traffic. However, this document recommends "isolating" such nodes. Doing this imo can actually worsen the problem and will have a cascading effect where a different node now becomes overloaded. I would suggest that a better way to avoid the overload attack is by treating such routers/nodes as leaf nodes in their graph. This would mean that we use this router/node for only reaching the directly connected devices and is never placed on the transit path to reach other nodes/routers. Minor Issues: (1) A common threat in routing protocols is that there is some unauthorized entity that somehow manages to gain access to keying material. Using this material, the attacker can send packets that pass the authenticity checks based on Message Authentication Codes (MACs). The most obvious way to mitigate such threat is by periodically changing the keys currently in use by the legitimate routing peers. Hence routing protocols designed for LLN must provide provision to easily change their keying material. Additionally security mechanisms designed for RPL must be such that the operators can quickly change keys without disrupting the routing system (data loss) and with minimal operational overhead/expense. If there is a significant overhead than this can lead to the keys not being changed often enough. I don't think this aspect is covered in the document. (2) Nodes in this environment can be installed but not switched on for quite some time. How would such devices get the updated keying material if it has changed by the time these get turned on? On a related note, what happens if these nodes support an authentication/encryption algorithm that gets deprecated by the time these nodes get switched on -- can happen if this particular node lies dormant for a few years before its turned on (refer to sec 4.3) (3) An automated key management protocol is a very important component of the security framework. Do all nodes in the LLN need to be manually configured? This may not be possible if there are large number of nodes in the routing domain. Wouldn't it make sense to actually discuss this (4) Sec 4.4. "RPL Security Objectives". Are we interested in message contents validation? Lest there is any doubt let me clarify that I am not talking about message integrity. I am talking about ensuring that a claim made in the route advertisement is indeed correct before accepting it (like SIDR). If we're not doing this, then it might help to explicitly state that message content validation is out of scope. If you're adding this, then a note or two on why would be extremely helpful. (5) Sec 4.4 says " Hence, routing in LLNs needs to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials." Can you explain this a bit more? Will this not lead to a circular dependency where routing bootstraps security, but you need security already in place for routing to work (to ensure we're speaking to an authorized node)? (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really suggesting that RPL should redundantly flood protocol messages over multiple paths in the hope that at least one will make it to the destination. Given the delicate energy and network utilization constraints this just doesn't look right. Shouldn't we focus more on ensuring that we don't get an insider malicious node than on what we can do once we have one inside our routing domain? (7) Sec 7.3.3 suggests "dynamically selecting the next hop from a set of candidates." to counter selective forwarding attacks. I am not sure i completely understand the point. Are you suggesting that we should consider multiple paths when constructing the shortest path tree? This will only work when you have ECMP because its only then that you have a set of nexthops that you can use without affecting the total cost to reach the destination. Without ECMP, how can you have a set of nexthops to choose from? I don't think you're alluding to pinning the path here? (8)7.3.4 "Countering Sinkhole Attacks" suggests "isolate nodes which receive traffic above a certain threshold;". I disagree doing this without further qualifying on what's meant by a "certain threshold" for the same reason as i cited above in (4). Nits: (1) There are several instances where RFC 2119 keywords are used. While I personally don't have an issue with using those keywords in an Informational draft, I was grilled in the IESG review on this and went through the pain of removing those at the last minute. (2) Sec 6 describes the threats and the possible attacks on RPL. In this context the title of Sec 6.1 is very clear and the reader understands the threat/attack being discussed in the following subsection. However the title of Sec 6.2 is very vague. I had to read the entire subsection to understand what the subsection was about. I think what you want to cover are the threats you get exposed to if your system *lacks* confidentiality. Cheers, Manav From nobody Mon Aug 25 00:28: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 278B01A8AB9 for ; Mon, 25 Aug 2014 00:28:25 -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 Dhmx-IZs28dC for ; Mon, 25 Aug 2014 00:28:21 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC7C1A8AB7 for ; Mon, 25 Aug 2014 00:28:21 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so20134330pab.2 for ; Mon, 25 Aug 2014 00:28:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=XKjshHwjCmTMt8eE8OuXPW0kNa7sbQTB80yVL7uQZX8=; b=jrGz/R8unRFOh27gUpVDZPgOi2975ojJX78F22Yn4sZFVlw6rR56tvpOvbVPxsfxum k0gT/3EfAArJidPzFYAcOefnLIJcXUCqJEWKD5B6toM/OvRDTb1ku3zUYLESL31KYyYK kV3lC6puAIEwPC+Nm1wPk59Kr7JXbRJvs60RGmRfInFtYipWMRgXeNfC+0bDijY4mvVz xfumo37rFd9H6qQw5Rv3nI03a1NKTQlu5Ss2l1e8ZjUIN21H9vJKCQmj6JzwKLPYY6zi 1SAkExAzxlb8SAWIVayoIcbjLqMNRP/M7sqcdIAJN8x//WMcXo1bxjFw/M9N/kNU6cc0 utsg== X-Gm-Message-State: ALoCoQlbqDNf0ahhb4WoXT1VaqUwe1A9B0CVCYWtQGK8MbXxRRggUZ0AwPASOJtoH4R3O/Th3CSq X-Received: by 10.70.60.169 with SMTP id i9mr1955024pdr.166.1408951698009; Mon, 25 Aug 2014 00:28:18 -0700 (PDT) Received: from Manav ([106.51.35.4]) by mx.google.com with ESMTPSA id w10sm36502446pbt.17.2014.08.25.00.28.15 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Aug 2014 00:28:17 -0700 (PDT) From: "Manav Bhatia" To: References: In-Reply-To: Date: Mon, 25 Aug 2014 12:58:14 +0530 Organization: Ionos Networks Message-ID: <087e01cfc036$248051b0$6d80f510$@ionosnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGvra/YT5nnnh0ICjpj6clbz8EP+pwhELAA Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Q_CL6pga5QWS3_YRjrsFd0uytng Cc: draft-ietf-roll-security-threats.all@tools.ietf.org, rtg-dir@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-roll-security-threats-09.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: manav@ionosnetworks.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 07:28:25 -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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 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-ietf-roll-security-threats-09 Reviewer: Manav Bhatia Review Date: 25-08-14 IETF LC End Date: 28-08-14 Intended Status: Informational Summary: I have some concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: This document presents a threat analysis for securing the routing protocols used in LLNs which are more prone to packet losses and other vulnerabilities. It then discusses how those attacks/threats can be mitigated. Major Issues: (1) Sec 7.2.2. "Countering Overclaiming and Misclaiming Attacks" says that " counter to overclaiming and misclaiming may employ: comparison with historical routing/topology data;" I don't understand how this will work. Assume node A was always a leaf node and was never attached to any routing device. Later, a new router gets attached to this node. The node A now starts advertising this new router. How will the peers know whether it's a legitimate advertisement or an "overclaim" from node A? I don't agree with notion that somebody could look at the historical data to figure out if a router is over/under claiming. I also don't think it's a good idea to suggest that we "restrict realizable network topologies" to counter overclaim/misclaim attacks. (2) Sec 7.3.2 "Countering Overload Attacks" suggests that "overload attacks" can be countered by "isolate nodes which send traffic above a certain threshold based on system operation characteristics;". Has this been adequately discussed in the WG? It's certainly possible that in an event of reroute/reconvergence a certain node can momentarily get more traffic than the threshold. Ordinarily, such nodes only drop the additional traffic. However, this document recommends "isolating" such nodes. Doing this imo can actually worsen the problem and will have a cascading effect where a different node now becomes overloaded. I would suggest that a better way to avoid the overload attack is by treating such routers/nodes as leaf nodes in their graph. This would mean that we use this router/node for only reaching the directly connected devices and is never placed on the transit path to reach other nodes/routers. Minor Issues: (1) A common threat in routing protocols is that there is some unauthorized entity that somehow manages to gain access to keying material. Using this material, the attacker can send packets that pass the authenticity checks based on Message Authentication Codes (MACs). The most obvious way to mitigate such threat is by periodically changing the keys currently in use by the legitimate routing peers. Hence routing protocols designed for LLN must provide provision to easily change their keying material. Additionally security mechanisms designed for RPL must be such that the operators can quickly change keys without disrupting the routing system (data loss) and with minimal operational overhead/expense. If there is a significant overhead than this can lead to the keys not being changed often enough. I don't think this aspect is covered in the document. (2) Nodes in this environment can be installed but not switched on for quite some time. How would such devices get the updated keying material if it has changed by the time these get turned on? On a related note, what happens if these nodes support an authentication/encryption algorithm that gets deprecated by the time these nodes get switched on -- can happen if this particular node lies dormant for a few years before its turned on (refer to sec 4.3) (3) An automated key management protocol is a very important component of the security framework. Do all nodes in the LLN need to be manually configured? This may not be possible if there are large number of nodes in the routing domain. Wouldn't it make sense to actually discuss this (4) Sec 4.4. "RPL Security Objectives". Are we interested in message contents validation? Lest there is any doubt let me clarify that I am not talking about message integrity. I am talking about ensuring that a claim made in the route advertisement is indeed correct before accepting it (like SIDR). If we're not doing this, then it might help to explicitly state that message content validation is out of scope. If you're adding this, then a note or two on why would be extremely helpful. (5) Sec 4.4 says " Hence, routing in LLNs needs to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials." Can you explain this a bit more? Will this not lead to a circular dependency where routing bootstraps security, but you need security already in place for routing to work (to ensure we're speaking to an authorized node)? (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really suggesting that RPL should redundantly flood protocol messages over multiple paths in the hope that at least one will make it to the destination. Given the delicate energy and network utilization constraints this just doesn't look right. Shouldn't we focus more on ensuring that we don't get an insider malicious node than on what we can do once we have one inside our routing domain? (7) Sec 7.3.3 suggests "dynamically selecting the next hop from a set of candidates." to counter selective forwarding attacks. I am not sure i completely understand the point. Are you suggesting that we should consider multiple paths when constructing the shortest path tree? This will only work when you have ECMP because its only then that you have a set of nexthops that you can use without affecting the total cost to reach the destination. Without ECMP, how can you have a set of nexthops to choose from? I don't think you're alluding to pinning the path here? (8)7.3.4 "Countering Sinkhole Attacks" suggests "isolate nodes which receive traffic above a certain threshold;". I disagree doing this without further qualifying on what's meant by a "certain threshold" for the same reason as i cited above in (4). Nits: (1) There are several instances where RFC 2119 keywords are used. While I personally don't have an issue with using those keywords in an Informational draft, I was grilled in the IESG review on this and went through the pain of removing those at the last minute. (2) Sec 6 describes the threats and the possible attacks on RPL. In this context the title of Sec 6.1 is very clear and the reader understands the threat/attack being discussed in the following subsection. However the title of Sec 6.2 is very vague. I had to read the entire subsection to understand what the subsection was about. I think what you want to cover are the threats you get exposed to if your system *lacks* confidentiality. Cheers, Manav From nobody Mon Aug 25 06:01: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 7A93A1A06DF; Fri, 22 Aug 2014 10:34:55 -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 UWoCRTagRwkK; Fri, 22 Aug 2014 10:34:52 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E73B1A0702; Fri, 22 Aug 2014 10:34:52 -0700 (PDT) Received: by mail-ig0-f170.google.com with SMTP id h3so1492248igd.5 for ; Fri, 22 Aug 2014 10:34: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:content-transfer-encoding; bh=kpeAM8YOuevG9OamOFLF7sBGiPKLvL5ai7XBXo613Vo=; b=Qk1DTdI8mht+oKgpmARE1ovScpx/1Au1kX1fJDNS5Sq8cdjNHp+Jf9mQaY2rvH9hOk ZV+QD4ipApF/U83pniF4f+E1xmyrZmVMACErNHWdZZuE/G9Ai3iUkjc3KUCWRwB3+8cQ fW009jh8KvsX2CcpIoMDxE+xgHEX8FYA7z4Hn38cbIN9T5QTOzQwkAO3ENbks4awRel3 p8epo4Lqo8nKQmiLWZsIIAgeqAr0XzGyO9WO/zGl8u4qOC+F4q+B7GNlc3UEuBJ+rob0 NsILp+rYcNL++6NsO9SnNmJndtlMeY4Lshv3Q8Ir6TiumBUBDnY410+eGp/mTjiTPXWJ Rb0Q== MIME-Version: 1.0 X-Received: by 10.50.111.167 with SMTP id ij7mr28213182igb.49.1408728891810; Fri, 22 Aug 2014 10:34:51 -0700 (PDT) Received: by 10.50.189.170 with HTTP; Fri, 22 Aug 2014 10:34:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 22 Aug 2014 23:04:51 +0530 Message-ID: From: Dhruv Dhody To: "Carlos Pignataro (cpignata)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/8RxMoJXpID2pbr7vNkGp6Oc6V10 X-Mailman-Approved-At: Mon, 25 Aug 2014 06:00:57 -0700 Cc: "mpls@ietf.org" , "George, Wes" , "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "rtg-ads@tools.ietf.org" , "Alvaro Retana \(aretana\)" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 17:34:55 -0000 > -----Original Message----- > From: , Wes George > Date: Friday, August 22, 2014 at 1:06 PM > To: Carlos Pignataro , Dhruv Dhody > , Alvaro Retana > Cc: "rtg-ads@tools.ietf.org" , "rtg-dir@ietf.org" > , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" > , "mpls@ietf.org" > > Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 > >> >>>>How about we move the pointers to any work-in-progress to address the >>>>gaps to appendix, would that be a good compromise? >>> >>>I would not want to loose the consolidated references, but perhaps we >>>need >>>to be more precise about a why we are pointing to each I-D. Pointing as >>>expanding the gap is OK, and maybe moving the =C2=B3solution I-Ds=C2=B2 = to an >>>Appendix is a good idea. >> >>I'm not convinced that much will be gained by such a change. It seems lik= e >>change for the sake of change. I will go along with it if WG consensus >>pushes that direction, but my preference would be to leave the references >>as-is. If we know something is in progress that is trying to address the >>problem, why not document what we know in the same places as we discuss >>the gaps? What value is there in hiding these things in an appendix just >>because we aren't completely certain that what we believe will address th= e >>gap will actually address the gap? > > Personally I do not have a particular preference between leaving citation= s > to I-Ds where they are or moving them (as co-editor I prefer leaving them > where they are :-) > > But the point I think is important to clarify in the document is whether = a > draft is referenced because it describes a gap or because it describes a > potential solution to a gap. > > Thanks, > > Carlos. I agree that the clarification as Carlos suggested would help. When I suggested moving the pointers-to-solutions to appendix, my thoughts was - since we do not have consensus on the solutions yet; we could explicitly state that the aim of the pointers in this appendix is to let the reader note that there are some proposed solutions in IETF, but they are work in progress and do not have consensus at the time of publication. There could be other solutions proposed at future time and the pointers should not be considered normative in any way. And a suitable text can be added for this. Change for the sake of change was not my intention :) Dhruv From nobody Mon Aug 25 06:01:11 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 982091A069B; Fri, 22 Aug 2014 10:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.668, 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 dC9W5vMogSAR; Fri, 22 Aug 2014 10:06:33 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 53F801A069A; Fri, 22 Aug 2014 10:06:33 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,382,1406606400"; d="scan'208";a="469878716" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 22 Aug 2014 13:06:03 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 22 Aug 2014 13:06:32 -0400 From: "George, Wes" To: "Carlos Pignataro (cpignata)" , Dhruv Dhody , "Alvaro Retana (aretana)" Date: Fri, 22 Aug 2014 13:06:30 -0400 Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac++K2wFX3CjzDF/Sz68mP/z2ElwOg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/Yxmg4ZWhGMgINx_14WbWKxuyXfE X-Mailman-Approved-At: Mon, 25 Aug 2014 06:00:58 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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: Fri, 22 Aug 2014 17:06:34 -0000 DQo+PkhvdyBhYm91dCB3ZSBtb3ZlIHRoZSBwb2ludGVycyB0byBhbnkgd29yay1pbi1wcm9ncmVz cyB0byBhZGRyZXNzIHRoZQ0KPj5nYXBzIHRvIGFwcGVuZGl4LCB3b3VsZCB0aGF0IGJlIGEgZ29v ZCBjb21wcm9taXNlPw0KPg0KPkkgd291bGQgbm90IHdhbnQgdG8gbG9vc2UgdGhlIGNvbnNvbGlk YXRlZCByZWZlcmVuY2VzLCBidXQgcGVyaGFwcyB3ZSBuZWVkDQo+dG8gYmUgbW9yZSBwcmVjaXNl IGFib3V0IGEgd2h5IHdlIGFyZSBwb2ludGluZyB0byBlYWNoIEktRC4gUG9pbnRpbmcgYXMNCj5l eHBhbmRpbmcgdGhlIGdhcCBpcyBPSywgYW5kIG1heWJlIG1vdmluZyB0aGUgwrNzb2x1dGlvbiBJ LURzwrIgdG8gYW4NCj5BcHBlbmRpeCBpcyBhIGdvb2QgaWRlYS4NCg0KSSdtIG5vdCBjb252aW5j ZWQgdGhhdCBtdWNoIHdpbGwgYmUgZ2FpbmVkIGJ5IHN1Y2ggYSBjaGFuZ2UuIEl0IHNlZW1zIGxp a2UNCmNoYW5nZSBmb3IgdGhlIHNha2Ugb2YgY2hhbmdlLiBJIHdpbGwgZ28gYWxvbmcgd2l0aCBp dCBpZiBXRyBjb25zZW5zdXMNCnB1c2hlcyB0aGF0IGRpcmVjdGlvbiwgYnV0IG15IHByZWZlcmVu Y2Ugd291bGQgYmUgdG8gbGVhdmUgdGhlIHJlZmVyZW5jZXMNCmFzLWlzLiBJZiB3ZSBrbm93IHNv bWV0aGluZyBpcyBpbiBwcm9ncmVzcyB0aGF0IGlzIHRyeWluZyB0byBhZGRyZXNzIHRoZQ0KcHJv YmxlbSwgd2h5IG5vdCBkb2N1bWVudCB3aGF0IHdlIGtub3cgaW4gdGhlIHNhbWUgcGxhY2VzIGFz IHdlIGRpc2N1c3MNCnRoZSBnYXBzPyBXaGF0IHZhbHVlIGlzIHRoZXJlIGluIGhpZGluZyB0aGVz ZSB0aGluZ3MgaW4gYW4gYXBwZW5kaXgganVzdA0KYmVjYXVzZSB3ZSBhcmVuJ3QgY29tcGxldGVs eSBjZXJ0YWluIHRoYXQgd2hhdCB3ZSBiZWxpZXZlIHdpbGwgYWRkcmVzcyB0aGUNCmdhcCB3aWxs IGFjdHVhbGx5IGFkZHJlc3MgdGhlIGdhcD8NCg0KVGhhbmtzLA0KDQpXZXMNCg0KDQpBbnl0aGlu ZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkgY29tcGFueeKAmXMgbWFpbCBz ZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQoNClRo aXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2Fy bmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBj b25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdh cm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29w eWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQg YXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5 IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxl dGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50 b3V0Lg0K From nobody Mon Aug 25 06:01: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 F0FED1A9083; Mon, 25 Aug 2014 05:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.668, 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 BIKBoqiM8xcw; Mon, 25 Aug 2014 05:41:32 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id D2A201A9082; Mon, 25 Aug 2014 05:41:31 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.04,397,1406606400"; d="scan'208";a="472811971" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Aug 2014 08:40:46 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 25 Aug 2014 08:41:30 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "Carlos Pignataro (cpignata)" Date: Mon, 25 Aug 2014 08:41:31 -0400 Thread-Topic: [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-01 Thread-Index: Ac/AYeSUj/uHNwcbR/2RPaf3IY2GsA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-dir/RpdrUwpP6nzsTehs4ihWSrvM2rY X-Mailman-Approved-At: Mon, 25 Aug 2014 06:00:58 -0700 Cc: "rtg-dir@ietf.org" , "draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] [mpls] RtgDir review: draft-ietf-mpls-ipv6-only-gap-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, 25 Aug 2014 12:41:33 -0000 QWx2YXJvIC0NCg0KV2hhdCB5b3UncmUgYWN0dWFsbHkgc2VlaW5nIGlzIHRoZSBhdXRvbWF0aWMg cHJvY2Vzc2luZyB0aGF0IHNlZXMNCiJSRkNOTk5OIiBhbmQgbWFrZXMgaXQgYSBoeXBlcmxpbmsg aW4gdGhlIEhUTUwgdmVyc2lvbi4gV2UgZGlkbid0IGFjdHVhbGx5DQphZGQgdGhlIHJlZmVyZW5j ZSB0byB0aGUgd29yayBpbiBwcm9ncmVzcyB0aGVyZSBhdCBhbGwuIEkgY2FuIGFkZCBpdC4NClRo YW5rcywNCg0KV2VzDQoNCg0KT24gOC8yMi8xNCwgMjo1MCBQTSwgIkFsdmFybyBSZXRhbmEgKGFy ZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb20+IHdyb3RlOg0KDQo+Q2FybG9zL1dlczoNCj4NCj5C VFcsIGFzIEkgd2FzIHRha2luZyBhbm90aGVyIGxvb2sgYXQgdGhlIC0wMSB0ZXh0IChJIGtub3cg eW91IGhhdmUgZWRpdHMNCj5yZWFkeSB0byBjb21taXQpLCB0aGVyZSdzIGEgY291cGxlIG1vcmUg bWlub3IgY29tbWVudHMgcmVsYXRlZCB0byB0aGUNCj5yZWZlcmVuY2VzOg0KPg0KPjEuIDMuMi4x LiAoTERQKSAiR2FwOiBNYWpvciwgdXBkYXRlIHRvIFJGQyA1MDM2IGluIHByb2dyZXNzIHRoYXQg c2hvdWxkDQo+Y2xvc2UgdGhpcyBnYXAuIiAgVGhlIGluLWxpbmUgcmVmZXJlbmNlIHBvaW50cyB0 byByZmM1MDM2LCBidXQgaXQgc2hvdWxkDQo+cG9pbnQgdG8gSS1ELmlldGYtbXBscy1sZHAtaXB2 Ni4NCj4NCj4yLiAzLjUuIChNSUJzKSAiR2FwOiBNYWpvci4gV29yayB1bmRlcndheSB0byB1cGRh dGUgUkZDMzgxMS4uIiAgU2FtZQ0KPnRoaW5nLCB0aGUgcmVmZXJlbmNlIHRvIHRoZSB1cGRhdGUg c2hvdWxkIHBvaW50IHRvDQo+SS1ELm1hbnJhbC1tcGxzLXJmYzM4MTFiaXMuDQo+DQo+VGhhbmtz IQ0KPg0KPkFsdmFyby4NCj4NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg==