From acee.lindem@ericsson.com Fri Feb 1 08:41:46 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDA721F8F66; Fri, 1 Feb 2013 08:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKxWvHrIBEws; Fri, 1 Feb 2013 08:41:44 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id EBDBC21F8F63; Fri, 1 Feb 2013 08:41:43 -0800 (PST) X-AuditID: c6180641-b7f926d000000e79-a5-510bf047326a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 41.87.03705.740FB015; Fri, 1 Feb 2013 17:41:43 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 11:41:42 -0500 From: Acee Lindem To: "" Thread-Topic: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB" Thread-Index: AQHN/+vjIMzOHGj7rEKXcaQ9o4gGD5hlif4A Date: Fri, 1 Feb 2013 16:41:42 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE470B7F70@eusaamb101.ericsson.se> References: <94A203EA12AECE4BA92D42DBFFE0AE470B5BF8@eusaamb101.ericsson.se> <510ACA65.9010307@cisco.com> In-Reply-To: <510ACA65.9010307@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: text/plain; charset="us-ascii" Content-ID: <996F1415CE3C724DAF2DE455F808C68C@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZXLonXNf9A3egwfazihY7Z/ewWTz/eoHZ 4kbDDxaLN+/+sFksWPOU3eLCm9/MFut3P2KyOPd0DqMDh8eU3xtZPZYs+cnk8X3tNWaPV8e+ swSwRHHZpKTmZJalFunbJXBldF08xF5wwaVi/Y2HjA2MC0y7GDk5JARMJM6d/MMGYYtJXLi3 Hsjm4hASOMIo8e5DFzOEs4xR4viCBmaQKjYBHYnnj/6B2SIC+hJHPuwEK2IWOMAkcXT1CUaQ hLBAusTvoxOgijIkni3/xghhG0ksvfQBzGYRUJGYO2UtC4jNK+At8fDoTSYQW0ggS+L+0e9g cU4BTYkV246C2YxA530/tQashllAXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuErSzxfc4jFoh6 HYkFuz+xQdjWElsev2WEsLUlli18zQxxg6DEyZlPWCYwis9CsmIWkvZZSNpnIWmfhaR9ASPr KkaO0uLUstx0I8NNjMBIPSbB5riDccEny0OM0hwsSuK8oa4XAoQE0hNLUrNTUwtSi+KLSnNS iw8xMnFwSjUwxjyPeW73wf+f1032fy0THdzfS03+dkVPR/SkTdeByct9+SbxnfozOXXBtcnr My6YbTj9geFdfW5shCRHXtny7Z26l4T2rBdbsc8ruHN5iEx1bUraft8bq2dzPU/Lk2/vqhav 0U80TC8zjZ294O26e292Pbh3ZOvRLw7luoI2RmYmH7pfvOXtVGIpzkg01GIuKk4EAA99elmi AgAA Cc: "rtg-dir@ietf.org" , Clarence FilsFils , Pierre Francois , Olivier Bonaventure , "Stefano Previdi \(sprevidi\)" , "Mike Shand \(mshand\)" , "rtgwg@ietf.org" Subject: Re: [RTG-DIR] Routing Directorate Review of "Framework for Loop-free convergence using oFIB" X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 16:41:46 -0000 Hi Stewart, I'm looking at the -09 version. I'm happy with it. I only have one comment = that I think could be a further improvement - see #1 below.=20 =20 On Jan 31, 2013, at 2:47 PM, Stewart Bryant wrote: > On 30/01/2013 18:33, Acee Lindem wrote: >> Authors, et al, >> I have been selected as the Routing Directorate reviewer for this draft.= The Routing Directorate seeks to review all routing or routing-related dra= fts as they pass through IETF last call and IESG review, and sometimes on s= pecial request. The purpose of the review is to provide assistance to the R= outing 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 discuss= ion or by updating the draft. >> Document: draft-ietf-rtgwg-ipfrr-ordered-fib-08 >> Reviewer: Acee Lindem >> Review Date: January 30, 2013 >> IETF LC End Date: January 31, 2013 >> Intended Status: informational >> Summary: This document is basically ready for publication, but has clari= fication that should be considered prior to publication. >> Comments: The document accomplishes what it sets out to achieve in docum= enting the ordered FIB mechanism for avoidance of transient loops. While Ap= pendix B is useful, I think the document would be better without Appendix A= . Of course, this is just my opinion. >=20 > AAH took a lot of thought, so we would rather not loose it, if it works b= etter I could reverse the order of the appendixes. Ok - it does take a lot of effort to understand the AAH state machines but = since it is in an appendix, the reader can choose to skip it.=20 >>=20 >> Major Issues: None >>=20 >> Minor Issues: >> 1. The document could benefit for a precise definition of a = "non-urgent topology change". From what I gathered, this is any change that= can be deferred during the ordered FIB delay. > The abstract now says > "This mechanism can be used in the case of non-urgent (management action)= link or node shutdowns and restarts or link metric changes." >=20 > 3.1.1 says >=20 > "First consider the non-urgent failure of a link (i.e. where an operator = or a network management system (NMS) shuts down a link thereby removing it = from the currently active topology) or the increase of a link metric by the= operator or NMS ." >=20 > The point is of course that although a link is shut down rather than fail= ing, a remote node cannot distinguish the two cases. Ok. For both 3.1.1 and 3.1.2, you may also want to point out the use case o= f reconvergence of IPFRR repaired path.=20 >=20 >> 2. Similarly, the document could benefit from a precise defi= nition of the "rSPF". I checked RFC 5715 and it is not defined there either= . I believe our discussions indicate that this is simply an SPF where the s= hortest path back to us is used as the cost. For example, for the first pas= s, the SPF would use our neighbor's link cost rather than our own. > We use rSPT in here. >=20 > As you know we are looking for a formal definition. >=20 > I have put in Section 5 >=20 > This computation required the introduction of the concept of a reverse Sh= ortest Path Tree (rSPT). The rSPT uses the cost towards the root rather tha= n from it and yields the best paths towards the root from other nodes in th= e network > [I-D.draft-bryant-ipfrr-tunnels]. Ok. I think this will suffice for anyone who has been remotely following th= e IPFRR discussion.=20 >=20 > If there is a better ref we can swap in Auth48. >=20 >=20 >=20 >=20 >> 3. It would be good to state early on that the current oFIB = mechanism is limited to a single link or node failure and that multiple unr= elated failures result in reversion to normal FIB convergence. > Done (in section 2). >> 4. Make sure the hold down timer is defined precisely and ea= rly in the document. Currently, this doesn't happen until section 8.2. > On first use it says: >=20 > If all events received within some hold-down period (the time that a rout= er waits to acquire a set of LSPs which should be processed together) h Right. I see that now.=20 >> 5. Upon the initial reading, one may think there is some cor= respondence between the Router (R) in sections 4 and the Router (R) in sect= ion 5. Can this be clearer? Perhaps, (R) is not needed in section 4 since i= n all other sections, it refers to the computing router. > R is now removed. >=20 > As has been described, a single event such as the failure or restoration = of a single link, single router or a linecard may be notified to the rest o= f the network as a set of individual link change events. It is necessary to= deduce from this collection of link state notifications the type of event = that has occurred in the network and hence the required ordering. >=20 > When a link change event is received which impacts the receiving router's= FIB, the routers at the near and far end of the link are noted. >=20 > If all events received within some hold-down period (the time that a rout= er waits to acquire a set of LSPs which should be processed together) have = a single router in common, then it is assumed that the change reflects an e= vent (line-card or router change) concerning that router. >=20 > In the case of a link change event, the router at the far end of the link= is deemed to be the common router. >=20 > All ordering computations are based on treating the common router as the = root for both link and node events. Good.=20 >=20 >=20 >> 6. In section 5, I have trouble envisioning a case where a r= outer would not be in an pre or post failure SPT. I guess if it had no loop= backs and only unnumbered interfaces or only interfaces to broadcast links = offering a longer path??? > This is the case where you have an unused link (due to costs), i.e. a lin= k not on any shortest path. That would make sense for a link failure. For a node failure, it is harder = to visualize such a topology.=20 >=20 >> 7. In section 6.2, it would be instructive to say that a Lin= k Down condition is represented by an infinite metric (or otherwise cover t= his condition). > I have added "Inclusion or removal of link" to the information list. Explicit specification works as well.=20 >> 8. In section 8.5, I believe this a different hold down time= r than the one used to group LSPs related to the same failure. > Yes. >=20 > I have changes this to AAH_Hold_down_timer expires Great.=20 >=20 > Pierre and Mike please check this. >>=20 >> Nits: >>=20 >> 1. Abstract - replace "However mechanism" with "However the mechan= ism". I chose singular since it is singular in the preceding text. > done >> 2. Introduction - replace "base (FIB)" with "bases (FIBs)" in the = first sentence. > Done >=20 >> 3. Page 5, replace "change order no" with "change order, no". > Done >> 4. Page 9, suggest adding "IGP " to "reverse connectivity check". > Done >> 5. Page 10, suggest using parenthesis rather than relying on arith= metic precedence for equations, e.g., T0 + H + (rank * MAX_FIB) > Done >> 6. There is a mixture of "neighbor" and "neighbour" in the documen= t. Of course, I prefer the US English to UK English since this is what all = the OSPF RFCs use. > I will deal - but given we are Europeans... :) I figured that. ;^) You did miss one:=20 A.3.2. Per Neighbor State Machine >=20 >> 7. Section 8.1, the actions are formatting inconsistently. In one = case, as a paragraph and the other as a list. > Done > 8. Page 19, replace "algorithms i.e." with "algorithm= s, i.e.". > Done >> 9. Page 19 and Page 22, use of (PNSM) and (PN) is inconsistent. > Done >> 10. Page 23, Run-on sentence beginning "Manual configuration...". > Done >> 11. There some instances where the opening clause for a sentence is p= receded with a comma and some where it is not. I prefer the former. For exa= mple, section 4.2 appears to be written in a different style with missing p= unctuation. >>=20 >>=20 > I think I got them, but RFC Editor will get this Thanks, Acee=20 >=20 > Thanks for the review >=20 > Stewart >=20 >> Thanks, >> Acee >>=20 >>=20 >>=20 >>=20 >=20 >=20 > --=20 > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 From rcallon@juniper.net Fri Feb 15 13:35:30 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEABE21F8550 for ; Fri, 15 Feb 2013 13:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+oCd-p5amgt for ; Fri, 15 Feb 2013 13:35:30 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2A37C21F84E2 for ; Fri, 15 Feb 2013 13:35:28 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUR6qH3CG1ICqDMnnx8XxPFUsmsUuTS6J@postini.com; Fri, 15 Feb 2013 13:35:28 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Feb 2013 13:33:04 -0800 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Feb 2013 13:33:04 -0800 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.30) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Feb 2013 13:41:45 -0800 Received: from mail201-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 15 Feb 2013 21:33:02 +0000 Received: from mail201-va3 (localhost [127.0.0.1]) by mail201-va3-R.bigfish.com (Postfix) with ESMTP id A628A70066A for ; Fri, 15 Feb 2013 21:33:02 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzc89bhc857hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail201-va3 (localhost.localdomain [127.0.0.1]) by mail201-va3 (MessageSwitch) id 1360963980671867_26250; Fri, 15 Feb 2013 21:33:00 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.236]) by mail201-va3.bigfish.com (Postfix) with ESMTP id A0CE0400065; Fri, 15 Feb 2013 21:33:00 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 15 Feb 2013 21:33:00 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.21]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0263.000; Fri, 15 Feb 2013 21:32:57 +0000 From: Ross Callon To: "rtg-ads@tools.ietf.org" , "fltemplin@acm.org" Thread-Topic: RtgDir review: draft-templin-ironbis-12.txt Thread-Index: Ac4LxAQ1F+8AQ3ISRJWm/m3A/LVG+w== Date: Fri, 15 Feb 2013 21:32:57 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9B@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9BCH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ACM.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "rtg-dir@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-templin-ironbis-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:35:30 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9BCH1PRD0510MB355_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVu dHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3Ro ZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0 byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC4NCg0KRG9jdW1lbnQ6ICAgICAgIGRyYWZ0LXRlbXBsaW4taXJvbmJpcy0xMi50eHQNClJldmll d2VyOiAgICAgICBSb3NzIENhbGxvbg0KUmV2aWV3IERhdGU6ICAgIEZlYnJ1YXJ5IDE1LCAyMDEz DQpJRVRGIExDIEVuZCBEYXRlOiBGZWJydWFyeSAxOCwgMjAxMw0KSW50ZW5kZWQgU3RhdHVzOiBp bmZvcm1hdGlvbmFsDQoNClN1bW1hcnk6IFRoaXMgZG9jdW1lbnQgaXMgYmFzaWNhbGx5IHJlYWR5 IGZvciBwdWJsaWNhdGlvbiwgYnV0IGhhcyBhIGZldyBtaW5vciBpc3N1ZXMgYW5kIG9uZSBtYWpv ciBpc3N1ZSB0aGF0IG5lZWRzIHRvIGJlIHJlc29sdmVkIHByaW9yIHRvIHB1YmxpY2F0aW9uLiBJ IHJlY29tbWVuZCB0aGF0IHRoZSByb3V0aW5nIEFEcyBkaXNjdXNzIHRoZXNlIGlzc3VlcywgcGFy dGljdWxhcmx5IHRoZSBvbmUgbWFqb3IgaXNzdWUsIHdpdGggdGhlIGF1dGhvci4NCg0KQ29tbWVu dHM6IEkgZm91bmQgdGhlIGRvY3VtZW50IHRvIGJlIHZlcnkgcmVhZGFibGUgYW5kIGdlbmVyYWxs eSB3ZWxsIHdyaXR0ZW4uIFRoZXJlIGFyZSBvbmx5IGEgZmV3IHNwZWNpZmljIGlzc3VlcyB0byBy ZXNvbHZlLg0KDQpNYWpvciBJc3N1ZToNCg0KSSBiZWxpZXZlIHRoYXQgdGhlIGRvY3VtZW50IHNo b3VsZCBiZSBleHBlcmltZW50YWwgcmF0aGVyIHRoYW4gaW5mb3JtYXRpb25hbC4gSSBzdWdnZXN0 IHRoYXQgdGhlIGF1dGhvciBkaXNjdXNzIHRoaXMgd2l0aCB0aGUgcm91dGluZyBBRHMuICBNeSBj b21tZW50IGJlbG93IGFib3V0IG1hbmFnZWFiaWxpdHkgY29uc2lkZXJhdGlvbnMgaXMgb25seSBv bmUgZXhhbXBsZSBvZiB3aHkgZXhwZXJpbWVudGFsIHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUg SU1ITy4NCg0KTWlub3IgSXNzdWVzOg0KDQpJIGFtIGFzc3VtaW5nIHRoYXQgdGhlIFJGQyB3aWxs IGNhcnJ5IHRoZSBub3JtYWwgd2FybmluZyB0aGF0IHRoaXMgaXMgbm90IGEgc3RhbmRhcmQgb2Yg YW55IGtpbmQsIGFuZCBpcyBub3QgY3VycmVudGx5IGEgY2FuZGlkYXRlIHRvIGJlY29tZSBhIHN0 YW5kYXJkLg0KDQpTZWN0aW9uIDE5LCByZWZlcmVuY2VzOg0KDQoxOS4yLiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlcw0KDQogICBbQUVST10gICAgIFRlbXBsaW4sIEYuLCBFZC4sICJBc3ltbWV0cmlj IEV4dGVuZGVkIFJvdXRlIE9wdGltaXphdGlvbg0KICAgICAgICAgICAgICAoQUVSTykiLCBXb3Jr IGluIFByb2dyZXNzLCBKdW5lIDIwMTEuDQoNCiAgIC4uLg0KDQogICBbSU5UQVJFQS1TRUFMXQ0K ICAgICAgICAgICAgICBUZW1wbGluLCBGLiwgRWQuLCAiVGhlIFN1Ym5ldHdvcmsgRW5jYXBzdWxh dGlvbiBhbmQNCiAgICAgICAgICAgICAgQWRhcHRhdGlvbiBMYXllciAoU0VBTCkiLCBXb3JrIGlu IFByb2dyZXNzLCBGZWJydWFyeSAyMDExLg0KDQogICBbSU5UQVJFQS1WRVRdDQogICAgICAgICAg ICAgIFRlbXBsaW4sIEYuLCBFZC4sICJWaXJ0dWFsIEVudGVycHJpc2UgVHJhdmVyc2FsIChWRVQp IiwNCiAgICAgICAgICAgICAgV29yayBpbiBQcm9ncmVzcywgSmFudWFyeSAyMDExLg0KDQoNCkkg ZG9u4oCZdCBzZWUgaG93IFtJTlRBUkVBLVZFVF0sIFtJTlRBUkVBLVNFQUxdLCBhbmQgW0FFUk9d IGNhbiBiZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZXMuIEl0IGlzIGNsZWFyIHRoYXQgeW91IG5l ZWQgdGhlc2UgcHJvdG9jb2xzIGluIG9yZGVyIHRvIGltcGxlbWVudCBkcmFmdC10ZW1wbGluLWly b25iaXMtMTIudHh0LCB3aGljaCBpbXBsaWVzIHRoYXQgdGhlc2UgbmVlZCB0byBiZSBub3JtYXRp dmUgcmVmZXJlbmNlcy4gQWxzbywgSSBmb3VuZCBpdCBkaWZmaWN1bHQgdG8ga25vdyB3aGljaCB2 ZXJzaW9uIHRoZXNlIHJlZmVyZW5jZXMgYXJlIHRvLiBBcmUgdGhleSB0bywgcmVzcGVjdGl2ZWx5 LCBSRkMgNjcwNiwgUkZDIDUzMjAsIGFuZCBSRkMgNTU1OD8NCg0KDQpBbHNvLCBJIGRpZG7igJl0 IG5vdGljZSBhbnkgZGlzY3Vzc2lvbiBvZiBtYW5hZ2VhYmlsaXR5LiBUaGlzIGlzIGEgbWFqb3Ig aXNzdWUgdGhhdCBuZWVkcyBjb25zaWRlcmF0aW9uLiBJZiB0aGUgZG9jdW1lbnQgc3RhdHVzIGlz IOKAnGV4cGVyaW1lbnRhbOKAnSB0aGVuIEkgc3VwcG9zZSB0aGF0IGl0IGlzIG9rYXkgdG8gc3Rh cnQgZXhwZXJpbWVudHMgd2l0aG91dCBPQU0gc29sdXRpb25zIGluIHBsYWNlLCBidXQgY29uc2lk ZXJhYmxlIHRob3VnaHQgb24gdGhpcyB3aWxsIGJlIG5lZWRlZCBiZWZvcmUgZGVwbG95bWVudHMg Y2FuIGJlIGNvbnNpZGVyZWQgdG8gYmUgb3BlcmF0aW9uYWwuIFNpbWlsYXJseSBJIGRpZG7igJl0 IHNlZSBhIGRpc2N1c3Npb24gb2YgaG93IG9wZXJhdGlvbiBjb250aW51ZXMgdGhyb3VnaCB0aGUg ZmFpbHVyZXMgb2Ygc2VydmVycyBvciBsb3N0IHBhY2tldHMuDQoNCg0KDQo= --_000_62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9BCH1PRD0510MB355_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGVsbG8sIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRv IHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFz cyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBv biBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mDQp0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwiPjxmb250IGNvbG9yPSJi bHVlIj48dT5odHRwOi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1s PC91PjwvZm9udD48L2E+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BbHRob3VnaCB0 aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFE cywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3 aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSByZWNlaXZlLCBh bmQgc3RyaXZlIHRvIHJlc29sdmUgdGhlbSB0aHJvdWdoIGRpc2N1c3Npb24gb3IgYnkgdXBkYXRp bmcgdGhlIGRyYWZ0Lg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Eb2N1bWVudDom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZHJhZnQtdGVtcGxpbi1p cm9uYmlzLTEyLnR4dDwvZGl2Pg0KPGRpdj5SZXZpZXdlcjombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9zcyBDYWxsb24gPC9kaXY+DQo8ZGl2PlJldmlldyBEYXRl OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGZWJydWFyeSAxNSwgMjAxMzwvZGl2Pg0KPGRpdj5J RVRGIExDIEVuZCBEYXRlOiBGZWJydWFyeSAxOCwgMjAxMzwvZGl2Pg0KPGRpdj5JbnRlbmRlZCBT dGF0dXM6IGluZm9ybWF0aW9uYWwgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TdW1t YXJ5OiBUaGlzIGRvY3VtZW50IGlzIGJhc2ljYWxseSByZWFkeSBmb3IgcHVibGljYXRpb24sIGJ1 dCBoYXMgYSBmZXcgbWlub3IgaXNzdWVzIGFuZCBvbmUgbWFqb3IgaXNzdWUgdGhhdCBuZWVkcyB0 byBiZSByZXNvbHZlZCBwcmlvciB0byBwdWJsaWNhdGlvbi4gSSByZWNvbW1lbmQgdGhhdCB0aGUg cm91dGluZyBBRHMgZGlzY3VzcyB0aGVzZSBpc3N1ZXMsIHBhcnRpY3VsYXJseSB0aGUgb25lIG1h am9yIGlzc3VlLCB3aXRoIHRoZQ0KYXV0aG9yLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2PkNvbW1lbnRzOiBJIGZvdW5kIHRoZSBkb2N1bWVudCB0byBiZSB2ZXJ5IHJlYWRhYmxlIGFu ZCBnZW5lcmFsbHkgd2VsbCB3cml0dGVuLiBUaGVyZSBhcmUgb25seSBhIGZldyBzcGVjaWZpYyBp c3N1ZXMgdG8gcmVzb2x2ZS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5NYWpvciBJ c3N1ZTogPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGJlbGlldmUgdGhhdCB0aGUg ZG9jdW1lbnQgc2hvdWxkIGJlIGV4cGVyaW1lbnRhbCByYXRoZXIgdGhhbiBpbmZvcm1hdGlvbmFs LiBJIHN1Z2dlc3QgdGhhdCB0aGUgYXV0aG9yIGRpc2N1c3MgdGhpcyB3aXRoIHRoZSByb3V0aW5n IEFEcy4mbmJzcDsgTXkgY29tbWVudCBiZWxvdyBhYm91dCBtYW5hZ2VhYmlsaXR5IGNvbnNpZGVy YXRpb25zIGlzIG9ubHkgb25lIGV4YW1wbGUgb2Ygd2h5IGV4cGVyaW1lbnRhbCB3b3VsZCBiZSBt b3JlIGFwcHJvcHJpYXRlDQpJTUhPLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1p bm9yIElzc3VlczogPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGFtIGFzc3VtaW5n IHRoYXQgdGhlIFJGQyB3aWxsIGNhcnJ5IHRoZSBub3JtYWwgd2FybmluZyB0aGF0IHRoaXMgaXMg bm90IGEgc3RhbmRhcmQgb2YgYW55IGtpbmQsIGFuZCBpcyBub3QgY3VycmVudGx5IGEgY2FuZGlk YXRlIHRvIGJlY29tZSBhIHN0YW5kYXJkLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ U2VjdGlvbiAxOSwgcmVmZXJlbmNlczogPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48 Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MHB0OyI+MTkuMi4mbmJzcDsgSW5mb3JtYXRpdmUgUmVmZXJlbmNlczwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwcHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+ Jm5ic3A7Jm5ic3A7IFtBRVJPXSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUZW1wbGluLCBGLiwg RWQuLCAmcXVvdDtBc3ltbWV0cmljIEV4dGVuZGVkIFJvdXRlIE9wdGltaXphdGlvbjwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKEFFUk8pJnF1 b3Q7LCBXb3JrIGluIFByb2dyZXNzLCBKdW5lIDIwMTEuPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTBwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNv dXJpZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsm bmJzcDsgLi4uPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBO ZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJzcDsgW0lOVEFSRUEtU0VBTF08L3Nw YW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRlbXBs aW4sIEYuLCBFZC4sICZxdW90O1RoZSBTdWJuZXR3b3JrIEVuY2Fwc3VsYXRpb24gYW5kPC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBZGFwdGF0 aW9uIExheWVyIChTRUFMKSZxdW90OywgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAxMS48 L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTBwdDsiPiZuYnNwOyZuYnNwOyBbSU5UQVJFQS1WRVRdPC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ291cmllciBOZXciIHNpemU9IjIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTBwdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUZW1wbGluLCBGLiwgRWQu LCAmcXVvdDtWaXJ0dWFsIEVudGVycHJpc2UgVHJhdmVyc2FsIChWRVQpJnF1b3Q7LDwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV29yayBpbiBQ cm9ncmVzcywgSmFudWFyeSAyMDExLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZh Y2U9IkNvdXJpZXIgTmV3IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4m bmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIg c2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9u dD48L2Rpdj4NCjxkaXY+SSBkb27igJl0IHNlZSBob3cgW0lOVEFSRUEtVkVUXSwgW0lOVEFSRUEt U0VBTF0sIGFuZCBbQUVST10gY2FuIGJlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlcy4gSXQgaXMg Y2xlYXIgdGhhdCB5b3UgbmVlZCB0aGVzZSBwcm90b2NvbHMgaW4gb3JkZXIgdG8gaW1wbGVtZW50 IGRyYWZ0LXRlbXBsaW4taXJvbmJpcy0xMi50eHQsIHdoaWNoIGltcGxpZXMgdGhhdCB0aGVzZSBu ZWVkIHRvIGJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzLiBBbHNvLCBJIGZvdW5kDQppdCBkaWZmaWN1 bHQgdG8ga25vdyB3aGljaCB2ZXJzaW9uIHRoZXNlIHJlZmVyZW5jZXMgYXJlIHRvLiBBcmUgdGhl eSB0bywgcmVzcGVjdGl2ZWx5LCBSRkMgNjcwNiwgUkZDIDUzMjAsIGFuZCBSRkMgNTU1OD88L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BbHNvLCBJIGRp ZG7igJl0IG5vdGljZSBhbnkgZGlzY3Vzc2lvbiBvZiBtYW5hZ2VhYmlsaXR5LiBUaGlzIGlzIGEg bWFqb3IgaXNzdWUgdGhhdCBuZWVkcyBjb25zaWRlcmF0aW9uLiBJZiB0aGUgZG9jdW1lbnQgc3Rh dHVzIGlzIOKAnGV4cGVyaW1lbnRhbOKAnSB0aGVuIEkgc3VwcG9zZSB0aGF0IGl0IGlzIG9rYXkg dG8gc3RhcnQgZXhwZXJpbWVudHMgd2l0aG91dCBPQU0gc29sdXRpb25zIGluIHBsYWNlLCBidXQg Y29uc2lkZXJhYmxlIHRob3VnaHQNCm9uIHRoaXMgd2lsbCBiZSBuZWVkZWQgYmVmb3JlIGRlcGxv eW1lbnRzIGNhbiBiZSBjb25zaWRlcmVkIHRvIGJlIG9wZXJhdGlvbmFsLiBTaW1pbGFybHkgSSBk aWRu4oCZdCBzZWUgYSBkaXNjdXNzaW9uIG9mIGhvdyBvcGVyYXRpb24gY29udGludWVzIHRocm91 Z2ggdGhlIGZhaWx1cmVzIG9mIHNlcnZlcnMgb3IgbG9zdCBwYWNrZXRzLiA8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bh bj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9BCH1PRD0510MB355_-- From lberger@labn.net Sun Feb 17 05:55:58 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D973021F8A25 for ; Sun, 17 Feb 2013 05:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.823 X-Spam-Level: X-Spam-Status: No, score=-101.823 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nap9uEsLFiRT for ; Sun, 17 Feb 2013 05:55:57 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 3521921F87D5 for ; Sun, 17 Feb 2013 05:55:57 -0800 (PST) Received: (qmail 16645 invoked by uid 0); 17 Feb 2013 13:55:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 17 Feb 2013 13:55:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=fJWeOFvs91aE9jdiRUFAHb0vv0IWjnYAARJLRCSWmWI=; b=h8HGCr6Ti3CqkPDwtCsuCjHEZJFzA05CGovoyjIzpQRzTq87hNqC52W+k2fwMFn5hkvOWBQnEHOirIQou76gyc4+nFgY1PfF1gVx4k7Jfq+8yQGa0kYdxZDjYuwOfQG/; Received: from box313.bluehost.com ([69.89.31.113]:37052 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1U74iN-0004Lv-GO; Sun, 17 Feb 2013 06:55:35 -0700 Message-ID: <5120E158.8080705@labn.net> Date: Sun, 17 Feb 2013 08:55:36 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" X-Enigmail-Version: 1.5 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} Cc: rtg-dir@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org, mpls@ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 13:55:59 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-mpls-tp-ethernet-addressing-05.txt Reviewer: Lou Berger Review Date: 2013-02-17 IETF LC End Date: 2013-02-18 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: This document is pretty straight forward and I don't have any major issues with it. I found the "MAC address discovery" a bit thinly defined. This document relies on the mechanisms defined in draft-ietf-mpls-gach-adv which has just entered last call. Major Issues: I think the "MAC address discovery" mechanisms defined in Section 4, need some additional details in order to ensure independent interoperable implementations. I don't think any of these issues should difficult or controversial, but I think they should be blocking. I think the following really needs to be covered: - The frequency in which the discovery information needs to be (re)sent & retained. (I think this is simply 1 or 2 sentences that relate back to Lifetime defined in gach-adv.) - Some guidance on how address changes should be handled. - Some guidance on how MTU changes should be handled. - MTU scope needs to be defined. It is completely unclear if MTU is intended to be the MTU based on the maximum frame size supported by the sending physical interface represented in the Source MAC Address TLV, or the MTU supported by the logical (IP) interface associated with the Source Address TLV. The ability to advertise the latter is IMO the minimum required, which I assume was the intent of the document, and just needs to be clarified. Also the basic term should be defined (via appropriate reference). Minor Issues: Section 4: - since assignment of the mac address is not in this document: s/01-00-5e-80-00-0d/defined in Section 7 of [mpls-gach-adv] - TLV formats should be provided for the defined TLVs - "Persistent loss" should be defined in quantitative terms. Also which GAP messages, all? What about handling of the case where GAP messages are received, but no MAC address TLVs are included? Section 5: - Earlier in Section 4 you say, "...must behave as configured for this eventuality.", but such configuration isn't mentioned in section 5. - Reporting of MTU mismatch counts and/or details is probably worth mentioning (and optionally reporting). Section 6: - I think it would be worth mentioning that Section 5 based Address Discovery allows the advertised MAC to be different than the MAC frame source address, and covering related security implications. Nits: Section 2: - for clarity, s/these forms of/broadcast or multicast in "not known to be point-to-point, these forms of addressing MUST ..." One final comment: While I'm sure it's too late to make such a change, I think including MTU in the [mpls-gach-adv] Source Address TLV (in place of the reserved field) would have simplified the protocol. -- clearly this is not a blocking comment or one that really needs to be addressed. That's it, Lou From fltemplin@yahoo.com Mon Feb 18 08:53:37 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3EEC21F8A4E for ; Mon, 18 Feb 2013 08:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgO8BnGrfpQ0 for ; Mon, 18 Feb 2013 08:53:36 -0800 (PST) Received: from nm27-vm0.bullet.mail.bf1.yahoo.com (nm27-vm0.bullet.mail.bf1.yahoo.com [98.139.213.139]) by ietfa.amsl.com (Postfix) with ESMTP id BCE3C21F87E3 for ; Mon, 18 Feb 2013 08:53:35 -0800 (PST) Received: from [98.139.215.142] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2013 16:53:35 -0000 Received: from [98.139.212.194] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 18 Feb 2013 16:53:35 -0000 Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 18 Feb 2013 16:53:35 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 233483.93538.bm@omp1003.mail.bf1.yahoo.com Received: (qmail 49931 invoked by uid 60001); 18 Feb 2013 16:53:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361206415; bh=LhrZQTheqcrRgcDW2zE4hBkXZdCnKOxs2GeMx4ym0PU=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FqomG/cAKtgHNhosLadZgjegDpGfVukyKECepRAVirTzm1pXmswX8PSWp9Sbc/bkkfl/pqDjJmhu0bz8DbifSr/mVpKzEuoluwLhSBpsFCs7wg8Jgq/CogDh3tC9L21C4IycT08uTHvhTq4kaWrsj9GprdZ7nA6PvZfnzsvfets= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1FW7hoKMmDeKSOyvInuulW6dSo+XV9PflyKlCXVlvOXkX2/ml8VDk5ANYgzkf5fZcUUWYzgKuSYqfmki4mfRbokcZQ70ixaRKDmfVEVGcJvXho+tFHkXIZQB30CewkVRuPqMbWVVICBdfaz5KPmZH6Qay/29HEzkvKNrs2qFe8Q=; X-YMail-OSG: FNPDhXkVM1l3MhuowAHuuOcunSzkNWC67F3eHjewT5Ox2wP ZLcl7A4YoGuqH7DEm8BZUOESoxY2eI6kXOqHhXTZyDQEL_gx1vCZdJsfCaAs CNTeg5UvWN0s2AiUdKb3DVFQ2fCA6XAuG1I0qugY2HtNr48dVz9LcDuF.uXm fT7xKGb5vUDtkBylqehTg2lnueI8Nrji6ku0OwY7BJBk795MmXevpv6kPw8F h1ybGIoK85xcF35JFPx1oI9dHz08mLa4DohO4Es5a3.M6nHfhhxtXpQeYhRh fHtv3h0VaQxzn7XflsCky0lKQGSEQBOW4w2sKnZxRG9rzFPOM7KiP_Sz0SjN EtXrvVM4_.d2KCtIaLKFlGOkh.fMXxK.a4GkQTJZHMWduSfrOdiShDznqFCE PnY96EbolvpnJOlW7V_OMDYHs6HERgBdyNT72mqaCKqdPScbIJV998BQ8VXt WYZMgHsCuufwtjPLQslb3fLyqmLotal1MZ6PM5uKBtfjdyb.xno56DKZNbpP VLmhDdcMKVq83LyG9A94- Received: from [130.76.32.40] by web161904.mail.bf1.yahoo.com via HTTP; Mon, 18 Feb 2013 08:53:34 PST X-Rocket-MIMEInfo: 001.001, SGVsbG8gUm9zcywKClRoYW5rIHlvdSBmb3IgdGFraW5nIHRoZSB0aW1lIHRvIGxvb2sgYXQgdGhpcyBkb2N1bWVudC4gVG8geW91ciBzcGVjaWZpYyBxdWVzdGlvbgphYm91dCB3aGF0IGFyZSB0aGUgY29ycmVjdCByZWZlcmVuY2VzLCB0aGV5IGFyZSBhcyBmb2xsb3dzOgoKwqAgW0FFUk9dID0gUkZDNjcwNgrCoCBbSU5UQVJFQS1TRUFMXSA9ICdkcmFmdC10ZW1wbGluLWludGFyZWEtc2VhbCcKwqAgW0lOVEFSRUEtVkVUXSA9ICdkcmFmdC10ZW1wbGluLWludGFyZWEtdmV0JwoKUGxlYXNlIGxldCBtZSBrbm8BMAEBAQE- X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.134.513 References: <62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9B@CH1PRD0510MB355.namprd05.prod.outlook.com> Message-ID: <1361206414.47315.YahooMailNeo@web161904.mail.bf1.yahoo.com> Date: Mon, 18 Feb 2013 08:53:34 -0800 (PST) From: "Fred L. Templin" To: Ross Callon , "rtg-ads@tools.ietf.org" In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD309AD8C9B@CH1PRD0510MB355.namprd05.prod.outlook.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1435348337-109327278-1361206414=:47315" X-Mailman-Approved-At: Mon, 18 Feb 2013 09:07:36 -0800 Cc: "rtg-dir@ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-templin-ironbis-12.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Fred L. Templin" List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:53:37 -0000 --1435348337-109327278-1361206414=:47315 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Ross,=0A=0AThank you for taking the time to look at this document. To= your specific question=0Aabout what are the correct references, they are a= s follows:=0A=0A=C2=A0 [AERO] =3D RFC6706=0A=C2=A0 [INTAREA-SEAL] =3D 'draf= t-templin-intarea-seal'=0A=C2=A0 [INTAREA-VET] =3D 'draft-templin-intarea-v= et'=0A=0APlease let me know if you need any further correspondence from me = at this time.=0A=0ARegards - Fred=0Afltemplin@acm.org=0A=0A=0A=0A=0A=0A>___= _____________________________=0A> From: Ross Callon = =0A>To: "rtg-ads@tools.ietf.org" ; "fltemplin@acm.o= rg" =0A>Cc: "rtg-dir@ietf.org" =0A>S= ent: Friday, February 15, 2013 1:32 PM=0A>Subject: RtgDir review: draft-tem= plin-ironbis-12.txt=0A> =0A>=0A> =0A>Hello, =0A>=C2=A0=0A>I have been selec= ted as the Routing Directorate reviewer for this draft. The Routing Directo= rate seeks to review all routing or routing-related drafts as they pass thr= ough IETF last call and IESG review, and sometimes on special request. The = purpose of=0Athe review is to provide assistance to the Routing ADs. For mo= re information about the Routing Directorate, please see http://www.ietf.or= g/iesg/directorate/routing.html=0A>=C2=A0=0A>Although these comments are pr= imarily for the use of the Routing ADs, it would be helpful if you could co= nsider them along with any other IETF Last Call comments that you receive, = and strive to resolve them through discussion or by updating the draft. =0A= >=C2=A0=0A>Document:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-templi= n-ironbis-12.txt=0A>Reviewer:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ros= s Callon =0A>Review Date:=C2=A0=C2=A0=C2=A0=C2=A0 February 15, 2013=0A>IETF= LC End Date: February 18, 2013=0A>Intended Status: informational =0A>=C2= =A0=0A>Summary: This document is basically ready for publication, but has a= few minor issues and one major issue that needs to be resolved prior to pu= blication. I recommend that the routing ADs discuss these issues, particula= rly the one major issue, with the=0Aauthor. =0A>=C2=A0=0A>Comments: I found= the document to be very readable and generally well written. There are onl= y a few specific issues to resolve. =0A>=C2=A0=0A>Major Issue: =0A>=C2=A0= =0A>I believe that the document should be experimental rather than informat= ional. I suggest that the author discuss this with the routing ADs.=C2=A0 M= y comment below about manageability considerations is only one example of w= hy experimental would be more appropriate=0AIMHO. =0A>=C2=A0=0A>Minor Issue= s: =0A>=C2=A0=0A>I am assuming that the RFC will carry the normal warning t= hat this is not a standard of any kind, and is not currently a candidate to= become a standard.=0A>=C2=A0=0A>Section 19, references: =0A>=C2=A0=0A>19.2= .=C2=A0 Informative References=0A>=C2=A0=0A>=C2=A0=C2=A0 [AERO]=C2=A0=C2=A0= =C2=A0=C2=A0 Templin, F., Ed., "Asymmetric Extended Route Optimization=0A>= =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 (AERO)", Work in Progress, June 2011.=0A>=C2=A0=0A>=C2=A0=C2=A0 ...=0A>= =C2=A0=0A>=C2=A0=C2=A0 [INTAREA-SEAL]=0A>=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 Templin, F., Ed., "The Subnet= work Encapsulation and=0A>=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 Adaptation Layer (SEAL)", Work in Progress, = February 2011.=0A>=C2=A0=0A>=C2=A0=C2=A0 [INTAREA-VET]=0A>=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 Templin, F.= , Ed., "Virtual Enterprise Traversal (VET)",=0A>=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 Work in Progress, Janua= ry 2011.=0A>=C2=A0=0A>=C2=A0=0A>I don=E2=80=99t see how [INTAREA-VET], [INT= AREA-SEAL], and [AERO] can be informational references. It is clear that yo= u need these protocols in order to implement draft-templin-ironbis-12.txt, = which implies that these need to be normative references. Also, I found=0Ai= t difficult to know which version these references are to. Are they to, res= pectively, RFC 6706, RFC 5320, and RFC 5558?=0A>=C2=A0=0A>=C2=A0=0A>Also, I= didn=E2=80=99t notice any discussion of manageability. This is a major iss= ue that needs consideration. If the document status is =E2=80=9Cexperimenta= l=E2=80=9D then I suppose that it is okay to start experiments without OAM = solutions in place, but considerable thought=0Aon this will be needed befor= e deployments can be considered to be operational. Similarly I didn=E2=80= =99t see a discussion of how operation continues through the failures of se= rvers or lost packets. =0A>=C2=A0=0A>=C2=A0=0A>=C2=A0 =0A>=0A> --1435348337-109327278-1361206414=:47315 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hello Ross,

Th= ank you for taking the time to look at this document. To your specific ques= tion
about what are the correct references, they are as follows:

=   [AERO] =3D RFC6706
  [INTAREA-SEAL] =3D 'draft-templin-intar= ea-seal'
  [INTAREA-VET] =3D 'draft-templin-intarea-vet'

Ple= ase let me know if you need any further correspondence from me at this time= .

Regards - Fred
fltemplin@acm.org


<= span style=3D"font-weight:bold;">From: Ross Callon <rcallon@junip= er.net>
To: "rtg-ad= s@tools.ietf.org" <rtg-ads@tools.ietf.org>; "fltemplin@acm.org" <f= ltemplin@acm.org>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>
Sent: Friday, February 15, 2013 1:32 PM
Subject: RtgDir review: draft-t= emplin-ironbis-12.txt

=0A
= =0A=0A =0A =0A=0A=0A=0A=
=0A= =0A
Hello,
=0A
 
=0A
I have been selected as th= e Routing Directorate reviewer for this draft. The Routing Directorate seek= s 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 o= f=0Athe review is to provide assistance to the Routing ADs. For more inform= ation about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html
=0A
 
=0A
Although these comments are prim= arily for the use of the Routing ADs, it would be helpful if you could cons= ider them along with any other IETF Last Call comments that you receive, an= d strive to resolve them through discussion or by updating the draft.=0A=0A
 
=0A
Document:      = ;  draft-templin-ironbis-12.txt
=0A
Reviewer:  &nbs= p;     Ross Callon
=0A
Review Date: &nbs= p;   February 15, 2013
=0A
IETF LC End Date: February 18= , 2013
=0A
Intended Status: informational
=0A
 =0A
Summary: This document is basically ready for publication, but ha= s a few minor issues and one major issue that needs to be resolved prior to= publication. I recommend that the routing ADs discuss these issues, partic= ularly the one major issue, with the=0Aauthor.
=0A
 
= =0A
Comments: I found the document to be very readable and generally we= ll written. There are only a few specific issues to resolve.
=0A
=  
=0A
Major Issue:
=0A
 
=0A
I believ= e that the document should be experimental rather than informational. I sug= gest that the author discuss this with the routing ADs.  My comment be= low about manageability considerations is only one example of why experimen= tal would be more appropriate=0AIMHO.
=0A
 
=0A
Min= or Issues:
=0A
 
=0A
I am assuming that the RFC wil= l carry the normal warning that this is not a standard of any kind, and is = not currently a candidate to become a standard.
=0A
 
= =0A
Section 19, references:
=0A
 
=0A
19.2.  In= formative References
=0A
 
=0A&nb= sp;  [AERO]     Templin, F., Ed., "Asymmetric Exte= nded Route Optimization
=0A
     = ;         (AERO)", Work in Progress= , June 2011.
=0A
 
=0A
  = ; ...
=0A
 
=0A
   [INTA= REA-SEAL]
=0A
=        &= nbsp;      Templin, F., Ed., "The Subnetwork Encap= sulation and
=0A
      &nbs= p;       Adaptation Layer (SEAL)", Work in Pr= ogress, February 2011.
=0A
 
=0A<= div>&= nbsp;  [INTAREA-VET]
=0A
    &nb= sp;         Templin, F., Ed., "Virt= ual Enterprise Traversal (VET)",
=0A
   &n= bsp;          Work in Progress= , January 2011.
=0A
 
=0A
 <= /span>
=0A
I don=E2=80=99t see how [INTAREA-VET], [INTAREA-= SEAL], and [AERO] can be informational references. It is clear that you nee= d these protocols in order to implement draft-templin-ironbis-12.txt, which= implies that these need to be normative references. Also, I found=0Ait dif= ficult to know which version these references are to. Are they to, respecti= vely, RFC 6706, RFC 5320, and RFC 5558?
=0A
 
=0A
&n= bsp;
=0A
Also, I didn=E2=80=99t notice any discussion of manageabi= lity. This is a major issue that needs consideration. If the document statu= s is =E2=80=9Cexperimental=E2=80=9D then I suppose that it is okay to start= experiments without OAM solutions in place, but considerable thought=0Aon = this will be needed before deployments can be considered to be operational.= Similarly I didn=E2=80=99t see a discussion of how operation continues thr= ough the failures of servers or lost packets.
=0A
 
=0A=
 
=0A
 
=0A=0A
=0A=0A
=

--1435348337-109327278-1361206414=:47315-- From akatlas@juniper.net Mon Feb 18 08:56:17 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DC621F8C2F for ; Mon, 18 Feb 2013 08:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2FOtZU9+j4f for ; Mon, 18 Feb 2013 08:56:16 -0800 (PST) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 334ED21F8C0C for ; Mon, 18 Feb 2013 08:56:15 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKUSJdKAN7SCHbNNjt0EdWd4zoAEooFGnB@postini.com; Mon, 18 Feb 2013 08:56:15 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 18 Feb 2013 08:52:34 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 18 Feb 2013 08:52:33 -0800 Received: from TX2EHSOBE010.bigfish.com (65.55.88.11) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 18 Feb 2013 08:55:03 -0800 Received: from mail74-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.23; Mon, 18 Feb 2013 16:52:32 +0000 Received: from mail74-tx2 (localhost [127.0.0.1]) by mail74-tx2-R.bigfish.com (Postfix) with ESMTP id 920131800F3 for ; Mon, 18 Feb 2013 16:52:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -21 X-BigFish: PS-21(zzc85fh1418Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail74-tx2 (localhost.localdomain [127.0.0.1]) by mail74-tx2 (MessageSwitch) id 1361206350754730_11833; Mon, 18 Feb 2013 16:52:30 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.244]) by mail74-tx2.bigfish.com (Postfix) with ESMTP id A1EC538025A; Mon, 18 Feb 2013 16:52:30 +0000 (UTC) Received: from BY2PRD0510HT001.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 18 Feb 2013 16:52:30 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.56]) by BY2PRD0510HT001.namprd05.prod.outlook.com ([10.255.84.36]) with mapi id 14.16.0263.000; Mon, 18 Feb 2013 16:52:30 +0000 From: Alia Atlas To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-templin-intarea-seal-51.txt Thread-Index: Ac4N+FYN48xEu5TvRLWkgJqidXtWsg== Date: Mon, 18 Feb 2013 16:52:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_D1CF735B7C7B744582438550F826E01B20225CCABY2PRD0510MB389_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-Mailman-Approved-At: Mon, 18 Feb 2013 09:07:36 -0800 Cc: "rtg-dir@ietf.org" , "draft-templin-intarea-seal.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-templin-intarea-seal-51.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 16:56:18 -0000 --_000_D1CF735B7C7B744582438550F826E01B20225CCABY2PRD0510MB389_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see htt= p://www.ietf.org/iesg/directorate/routing.html 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-templin-intarea-seal-51.txt Reviewer: Alia Atlas Review Date: 18-Feb-2013 IETF LC End Date: 20-Feb-2013 Intended Status: Informational Summary: This document is basically ready for publication, but has nits that shou= ld be considered prior to publication Comments: The draft is generally very well written. There are a couple things tha= t could use a quick explanation, but it is basically very clear. Major Issues: This draft is targeted at Informational, but it is defining new function= ality, a new protocol, and is making obsolete an Experimental draft. I thi= nk that Experimental would be a more accurate target. Minor Issues: 1) This document talks about re-encapsulation without describing it or= defining when it might be needed. Even a brief sentence in terminology or= where re-encapsulation is first introduced would be useful to explain that= a segmented tunnel can exist and why - or why segmentation needs to be und= erstood by SEAL - as opposed to doing a decap/encap at the ETE/ITE? Nits: 1) Confusing typo: Last paragraph of p.25 says: "For SEAL packets, t= he ITE performs any necessary IP reassembly..." I think this should be the= ETE not the ITE. Regards, Alia --_000_D1CF735B7C7B744582438550F826E01B20225CCABY2PRD0510MB389_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
I have been selected as th= e Routing Directorate reviewer for this draft. The Routing Directorate seek= s 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 t= he Routing ADs. For more information about the Routing Directorate, please = see http://www.ie= tf.org/iesg/directorate/routing.html
Although these comments ar= e primarily for the use of the Routing ADs, it would be helpful if you coul= d consider them along with any other IETF Last Call comments that you recei= ve, and strive to resolve them through discussion or by updating the draft.
Document: draft-templin-in= tarea-seal-51.txt 
Reviewer: Alia Atlas
Review Date: 18-Feb-2013
IETF LC End Date: 20-Feb-2013
Intended Status: Informational
Summ= ary:
   This document is basically ready for publication, but has= nits that should be considered prior to publication
&nbs= p;
Comments:
   The draft is generally very well written.  There are= a couple things that could use a quick explanation, but it is basically ve= ry clear.
 
Major Issues:
   This draft is targeted at Informational, but it is defini= ng new functionality, a new protocol, and is making obsolete an Experimenta= l draft. I think that Experimental would be a more accurate target.
&nbs= p;
Minor Issues:
  1. This document talks about re-encapsulation without describing it or def= ining when it might be needed.  Even a brief sentence in terminology o= r where re-encapsulation is first introduced would be useful to explain tha= t a segmented tunnel can exist and why – or why segmentation needs to be understood by SEAL – as oppos= ed to doing a decap/encap at the ETE/ITE?
&nbs= p;
Nits:
  1. Confusing typo:  Last paragraph of p.25 says:  “For SEA= L packets, the ITE performs any necessary IP reassembly…” = I think this should be the ETE not the ITE.
    2.
&nbs= p;
Rega= rds,
Alia=
&nbs= p;
 --_000_D1CF735B7C7B744582438550F826E01B20225CCABY2PRD0510MB389_-- From fltemplin@yahoo.com Tue Feb 19 10:23:08 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0463521F88B9 for ; Tue, 19 Feb 2013 10:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW-41f5eQL8c for ; Tue, 19 Feb 2013 10:23:07 -0800 (PST) Received: from nm14-vm0.bullet.mail.bf1.yahoo.com (nm14-vm0.bullet.mail.bf1.yahoo.com [98.139.213.164]) by ietfa.amsl.com (Postfix) with SMTP id E0C3D21F8899 for ; Tue, 19 Feb 2013 10:23:06 -0800 (PST) Received: from [98.139.212.145] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 18:23:06 -0000 Received: from [98.139.212.240] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 18:23:06 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 19 Feb 2013 18:23:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 227944.42142.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 62827 invoked by uid 60001); 19 Feb 2013 18:23:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361298185; bh=MzL2wPPS+olN9l5RCpxLIcO69aSOQ5b/bfbVqcSZgvw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hbZ6ARjZs+gwsE/zWfkOIDY4FRxm8T24yVvxUMRmOSdtj89THC1CxfKegtrJgSeSexiJO8VXRdOW8+4W0Pgzqhi7XFfZm3cDt8Itm7vE5dYcSJbPoD83bEZ2/k6NAPLhILiU7SgeKeS86bKvl9V8g+vp6f5gQpzE/aAScdPgFJo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BpMxUjueyLiMfe5zxdyk0QbFuWZhy1ZuXWBTyTogcAmDtQalF/pWxASK7UQaupO0RUlsOWCGpSvoh0LL1GzeB6aaQU9V3CAr/bZ/XcyY9o9UoQ1FskEfy8gpOAYF4zgHbHJShTc1ALbtVld997DHPA1MXBSK6tWAkx+qLaqsq6I=; X-YMail-OSG: xd6O8uoVM1ksbL6wZgynAIUyfhTjtXKQgrUuY91SAD6vz0X _Gbs280WMCPO3XhU8vm52aHA898TNEDtWlErDoaCG8t32tA3mvIlBvVqwtQb f2_YIiRCHfIK0U07EeQ.gQ.LJ2HZ6bjKIyu0x3m36WCQAdOWRhZzYr97zL9j yunBhyPfvU.Rm0FSwRwZ31nXikEWcEpi861.bZveAAO0qJUj546Y5rUuQWTS Mvbgmpor6HG0MOVf3i0OjkA4R2ytML0IVii62KKOb869YYSFL8BWgq7WhkND ajqnBNwrk7B7tymboHydVxx1hiB8yhAidvjM8el1nsiF7zGDuq4tX2Wf.PRk xv8Dn7k.AeOkC82jhhwvQREqkzu.LbFazCfKToEI8cG3PZCwiilL2PCwrTgN QIJ1eJ5BMqkNQuhg9mnyr2HaNBded3YyEdy2LFqoI7l7a_xlrpcWCBiNV6BN HvGB72VK0jpth9M3dCshNY2aoKif0t5nc1FjvxqdAyr04_PJJDjnAVAiFdUe XzI3LG9XkFPthxU.bwzHM Received: from [130.76.32.40] by web161906.mail.bf1.yahoo.com via HTTP; Tue, 19 Feb 2013 10:23:05 PST X-Rocket-MIMEInfo: 001.001, SGVsbG8gQWxpYSwKClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgY29tbWVudHMsIGFuZCBwbGVhc2Ugc2VlIGJlbG93IGZvciBwcm9wb3NlZApyZXNvbHV0aW9uczoKCkZyZWQKZmx0ZW1wbGluQGFjbS5vcmcKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo.IEZyb206IEFsaWEgQXRsYXMgPGFrYXRsYXNAanVuaXBlci5uZXQ.Cj5UbzogInJ0Zy1hZHNAdG9vbHMuaWV0Zi5vcmciIDxydGctYWRzQHRvb2xzLmlldGYub3JnPiAKPkNjOiAicnRnLWRpckBpZXRmLm9yZyIgPHJ0Zy1kaXJAaWUBMAEBAQE- X-RocketYMMF: fltemplin X-Mailer: YahooMailWebService/0.8.134.513 References: Message-ID: <1361298185.59883.YahooMailNeo@web161906.mail.bf1.yahoo.com> Date: Tue, 19 Feb 2013 10:23:05 -0800 (PST) From: "Fred L. Templin" To: Alia Atlas , "rtg-ads@tools.ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 19 Feb 2013 10:30:27 -0800 Cc: "rtg-dir@ietf.org" , "fltemplin@acm.org" , "draft-templin-intarea-seal.all@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-templin-intarea-seal-51.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Fred L. Templin" List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:23:08 -0000 Hello Alia,=0A=0AThank you very much for your comments, and please see belo= w for proposed=0Aresolutions:=0A=0AFred=0Afltemplin@acm.org=0A=0A=0A_______= _________________________=0A> From: Alia Atlas =0A>To:= "rtg-ads@tools.ietf.org" =0A>Cc: "rtg-dir@ietf.or= g" ; "draft-templin-intarea-seal.all@tools.ietf.org" =0A>Sent: Monday, February 18, = 2013 8:52 AM=0A>Subject: RtgDir review: draft-templin-intarea-seal-51.txt= =0A> =0A>=0A> =0A>Hello,=0A>I have been selected as the Routing Directorate= reviewer for this draft. The Routing Directorate seeks to review all routi= ng or routing-related drafts as they pass through IETF last call and IESG r= eview, and sometimes=0Aon special request. The purpose of the review is to = provide assistance to the Routing ADs. For more information about the Routi= ng Directorate, please see=0Ahttp://www.ietf.org/iesg/directorate/routing.h= tml=0A>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=0Ad= iscussion or by updating the draft.=0A>Document: draft-templin-intarea-seal= -51.txt=C2=A0=0A>Reviewer: Alia Atlas=0A>Review Date: 18-Feb-2013=0A>IETF L= C End Date: 20-Feb-2013=0A>Intended Status: Informational=0A>Summary:=0A>= =C2=A0=C2=A0 This document is basically ready for publication, but has nits= that should be considered prior to publication=0A>=C2=A0=0A>Comments:=0A>= =C2=A0=C2=A0 The draft is generally very well written.=C2=A0 There are a co= uple things that could use a quick explanation, but it is basically very cl= ear.=0A>=C2=A0=0A>Major Issues:=0A>=C2=A0=C2=A0 This draft is targeted at I= nformational, but it is defining new functionality, a new protocol, and is = making obsolete an Experimental draft.=C2=A0=C2=A0I think that Experimental= would be a more accurate target.=0A>=C2=A0=0A>Minor Issues:=0A>=C2=A0=C2= =A0=C2=A0=C2=A01. This document talks about re-encapsulation without descri= bing it or defining when it might be needed.=C2=A0 Even a brief sentence in= terminology or where re-encapsulation is first introduced would be useful = to explain that a segmented tunnel can exist and why=0A=E2=80=93 or why seg= mentation needs to be understood by SEAL =E2=80=93 as opposed to doing a de= cap/encap at the ETE/ITE?=0A=0ASection 5.2 ("SEAL Model of Operation") is t= he first mention of re-encapsulation, and explains it in a fairly=0Adetaile= d paragraph. Does this satisfy the concern?=0A=0A>=C2=A0=0A>Nits:=0A>=C2=A0= =C2=A0=C2=A0=C2=A0* Confusing typo:=C2=A0 Last paragraph of p.25 says:=C2= =A0 =E2=80=9CFor SEAL packets, the ITE performs any necessary IP reassembly= =E2=80=A6=E2=80=9D=C2=A0 I think this should be the ETE not the ITE.=0A=0AY= ou are correct. This should be ETE instead of ITE and will be fixed in the = next version.=0A=0A>Regards,=0A>Alia=0A From akatlas@juniper.net Tue Feb 19 10:31:05 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BBF21F8C4E for ; Tue, 19 Feb 2013 10:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9lmSeeav74j for ; Tue, 19 Feb 2013 10:31:04 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 32C4921F886A for ; Tue, 19 Feb 2013 10:31:04 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUSPE5WaddrITYWhbWrscMHSHqgCWdhul@postini.com; Tue, 19 Feb 2013 10:31:04 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 19 Feb 2013 10:28:29 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Tue, 19 Feb 2013 10:28:29 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.184) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 19 Feb 2013 10:30:54 -0800 Received: from mail130-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE018.bigfish.com (10.43.70.68) with Microsoft SMTP Server id 14.1.225.23; Tue, 19 Feb 2013 18:28:25 +0000 Received: from mail130-ch1 (localhost [127.0.0.1]) by mail130-ch1-R.bigfish.com (Postfix) with ESMTP id BA6C160138 for ; Tue, 19 Feb 2013 18:28:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -30 X-BigFish: PS-30(zz9371Ic89bh542I1432I1418I11f6Nzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275ch1033IL17326ah8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail130-ch1 (localhost.localdomain [127.0.0.1]) by mail130-ch1 (MessageSwitch) id 1361298503611741_2118; Tue, 19 Feb 2013 18:28:23 +0000 (UTC) Received: from CH1EHSMHS021.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.229]) by mail130-ch1.bigfish.com (Postfix) with ESMTP id 88E6D160049; Tue, 19 Feb 2013 18:28:23 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CH1EHSMHS021.bigfish.com (10.43.70.21) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 19 Feb 2013 18:28:23 +0000 Received: from BY2PRD0510MB389.namprd05.prod.outlook.com ([169.254.4.56]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0263.000; Tue, 19 Feb 2013 18:28:23 +0000 From: Alia Atlas To: "Fred L. Templin" , "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-templin-intarea-seal-51.txt Thread-Index: Ac4N+FYN48xEu5TvRLWkgJqidXtWsgA1dKyAAAAfD1A= Date: Tue, 19 Feb 2013 18:28:22 +0000 Message-ID: References: <1361298185.59883.YahooMailNeo@web161906.mail.bf1.yahoo.com> In-Reply-To: <1361298185.59883.YahooMailNeo@web161906.mail.bf1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%ACM.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "rtg-dir@ietf.org" , "draft-templin-intarea-seal.all@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-templin-intarea-seal-51.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:31:05 -0000 SGkgRnJlZCwNCg0KT24gcmUtcmVhZGluZyA1LjIsIGl0IGRvZXMgZXhwbGFpbiByZS1lbmNhcHN1 bGF0aW9uIHdlbGwuICBJICB0aG91Z2h0IEkgaGFkIHNlZW4gcmUtZW5jYXBzdWxhdGlvbiBtZW50 aW9uZWQgYmVmb3JlIHRoYXQgLSBidXQgb24gaHVudGluZyB0aGUgdGV4dCwgSSBkb24ndCBmaW5k IGl0LiAgDQoNCkFsaWENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZyZWQg TC4gVGVtcGxpbiBbbWFpbHRvOmZsdGVtcGxpbkBhY20ub3JnXSANClNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDE5LCAyMDEzIDE6MjMgUE0NClRvOiBBbGlhIEF0bGFzOyBydGctYWRzQHRvb2xzLmll dGYub3JnDQpDYzogcnRnLWRpckBpZXRmLm9yZzsgZHJhZnQtdGVtcGxpbi1pbnRhcmVhLXNlYWwu YWxsQHRvb2xzLmlldGYub3JnOyBmbHRlbXBsaW5AYWNtLm9yZw0KU3ViamVjdDogUmU6IFJ0Z0Rp ciByZXZpZXc6IGRyYWZ0LXRlbXBsaW4taW50YXJlYS1zZWFsLTUxLnR4dA0KDQpIZWxsbyBBbGlh LA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIGNvbW1lbnRzLCBhbmQgcGxlYXNlIHNl ZSBiZWxvdyBmb3IgcHJvcG9zZWQNCnJlc29sdXRpb25zOg0KDQpGcmVkDQpmbHRlbXBsaW5AYWNt Lm9yZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IEFsaWEg QXRsYXMgPGFrYXRsYXNAanVuaXBlci5uZXQ+DQo+VG86ICJydGctYWRzQHRvb2xzLmlldGYub3Jn IiA8cnRnLWFkc0B0b29scy5pZXRmLm9yZz4NCj5DYzogInJ0Zy1kaXJAaWV0Zi5vcmciIDxydGct ZGlyQGlldGYub3JnPjsgDQo+ImRyYWZ0LXRlbXBsaW4taW50YXJlYS1zZWFsLmFsbEB0b29scy5p ZXRmLm9yZyIgDQo+PGRyYWZ0LXRlbXBsaW4taW50YXJlYS1zZWFsLmFsbEB0b29scy5pZXRmLm9y Zz4NCj5TZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE4LCAyMDEzIDg6NTIgQU0NCj5TdWJqZWN0OiBS dGdEaXIgcmV2aWV3OiBkcmFmdC10ZW1wbGluLWludGFyZWEtc2VhbC01MS50eHQNCj4gDQo+DQo+ IA0KPkhlbGxvLA0KPkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9y YXRlIHJldmlld2VyIGZvciB0aGlzIA0KPmRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBz ZWVrcyB0byByZXZpZXcgYWxsIHJvdXRpbmcgb3IgDQo+cm91dGluZy1yZWxhdGVkIGRyYWZ0cyBh cyB0aGV5IHBhc3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyANCj5yZXZpZXcsIGFu ZCBzb21ldGltZXMNCm9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlIHJldmll dyBpcyB0byBwcm92aWRlIGFzc2lzdGFuY2UgdG8gdGhlIFJvdXRpbmcgQURzLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZSBodHRw Oi8vd3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1sDQo+QWx0aG91Z2gg dGhlc2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBB RHMsIA0KPml0IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxv bmcgd2l0aCBhbnkgb3RoZXIgDQo+SUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVj ZWl2ZSwgYW5kIHN0cml2ZSB0byByZXNvbHZlIHRoZW0gDQo+dGhyb3VnaA0KZGlzY3Vzc2lvbiBv ciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+RG9jdW1lbnQ6IGRyYWZ0LXRlbXBsaW4taW50YXJl YS1zZWFsLTUxLnR4dA0KPlJldmlld2VyOiBBbGlhIEF0bGFzDQo+UmV2aWV3IERhdGU6IDE4LUZl Yi0yMDEzDQo+SUVURiBMQyBFbmQgRGF0ZTogMjAtRmViLTIwMTMNCj5JbnRlbmRlZCBTdGF0dXM6 IEluZm9ybWF0aW9uYWwNCj5TdW1tYXJ5Og0KPsKgwqAgVGhpcyBkb2N1bWVudCBpcyBiYXNpY2Fs bHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBidXQgaGFzIG5pdHMgdGhhdCANCj5zaG91bGQgYmUg Y29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlvbg0KPsKgDQo+Q29tbWVudHM6DQo+wqDCoCBU aGUgZHJhZnQgaXMgZ2VuZXJhbGx5IHZlcnkgd2VsbCB3cml0dGVuLsKgIFRoZXJlIGFyZSBhIGNv dXBsZSB0aGluZ3MgdGhhdCBjb3VsZCB1c2UgYSBxdWljayBleHBsYW5hdGlvbiwgYnV0IGl0IGlz IGJhc2ljYWxseSB2ZXJ5IGNsZWFyLg0KPsKgDQo+TWFqb3IgSXNzdWVzOg0KPsKgwqAgVGhpcyBk cmFmdCBpcyB0YXJnZXRlZCBhdCBJbmZvcm1hdGlvbmFsLCBidXQgaXQgaXMgZGVmaW5pbmcgbmV3 IGZ1bmN0aW9uYWxpdHksIGEgbmV3IHByb3RvY29sLCBhbmQgaXMgbWFraW5nIG9ic29sZXRlIGFu IEV4cGVyaW1lbnRhbCBkcmFmdC7CoMKgSSB0aGluayB0aGF0IEV4cGVyaW1lbnRhbCB3b3VsZCBi ZSBhIG1vcmUgYWNjdXJhdGUgdGFyZ2V0Lg0KPsKgDQo+TWlub3IgSXNzdWVzOg0KPsKgwqDCoMKg MS4gVGhpcyBkb2N1bWVudCB0YWxrcyBhYm91dCByZS1lbmNhcHN1bGF0aW9uIHdpdGhvdXQgZGVz Y3JpYmluZyBpdCANCj5vciBkZWZpbmluZyB3aGVuIGl0IG1pZ2h0IGJlIG5lZWRlZC7CoCBFdmVu IGEgYnJpZWYgc2VudGVuY2UgaW4gDQo+dGVybWlub2xvZ3kgb3Igd2hlcmUgcmUtZW5jYXBzdWxh dGlvbiBpcyBmaXJzdCBpbnRyb2R1Y2VkIHdvdWxkIGJlIA0KPnVzZWZ1bCB0byBleHBsYWluIHRo YXQgYSBzZWdtZW50ZWQgdHVubmVsIGNhbiBleGlzdCBhbmQgd2h5DQrigJMgb3Igd2h5IHNlZ21l bnRhdGlvbiBuZWVkcyB0byBiZSB1bmRlcnN0b29kIGJ5IFNFQUwg4oCTIGFzIG9wcG9zZWQgdG8g ZG9pbmcgYSBkZWNhcC9lbmNhcCBhdCB0aGUgRVRFL0lURT8NCg0KU2VjdGlvbiA1LjIgKCJTRUFM IE1vZGVsIG9mIE9wZXJhdGlvbiIpIGlzIHRoZSBmaXJzdCBtZW50aW9uIG9mIHJlLWVuY2Fwc3Vs YXRpb24sIGFuZCBleHBsYWlucyBpdCBpbiBhIGZhaXJseSBkZXRhaWxlZCBwYXJhZ3JhcGguIERv ZXMgdGhpcyBzYXRpc2Z5IHRoZSBjb25jZXJuPw0KDQo+wqANCj5OaXRzOg0KPsKgwqDCoMKgKiBD b25mdXNpbmcgdHlwbzrCoCBMYXN0IHBhcmFncmFwaCBvZiBwLjI1IHNheXM6wqAg4oCcRm9yIFNF QUwgcGFja2V0cywgdGhlIElURSBwZXJmb3JtcyBhbnkgbmVjZXNzYXJ5IElQIHJlYXNzZW1ibHni gKbigJ3CoCBJIHRoaW5rIHRoaXMgc2hvdWxkIGJlIHRoZSBFVEUgbm90IHRoZSBJVEUuDQoNCllv dSBhcmUgY29ycmVjdC4gVGhpcyBzaG91bGQgYmUgRVRFIGluc3RlYWQgb2YgSVRFIGFuZCB3aWxs IGJlIGZpeGVkIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCj5SZWdhcmRzLA0KPkFsaWENCg0KDQo= From adrian@olddog.co.uk Wed Feb 20 06:20:03 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08ACF21F8780; Wed, 20 Feb 2013 06:20:03 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzMQCa+wMQ8Z; Wed, 20 Feb 2013 06:20:02 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 374B421F877A; Wed, 20 Feb 2013 06:20:02 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1KEJsX9023001; Wed, 20 Feb 2013 14:19:54 GMT Received: from 950129200 ([37.61.186.220]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1KEJqeD022958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Feb 2013 14:19:53 GMT From: "Adrian Farrel" To: , , Date: Wed, 20 Feb 2013 14:19:53 -0000 Message-ID: <026701ce0f75$5ad6f430$1084dc90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4PdPb9ZxWLvqWbSVuMKXOs3YAF0Q== Content-Language: en-gb Cc: stbryant@cisco.com Subject: [RTG-DIR] Routing ADs Office Hours in Orlando X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 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: Wed, 20 Feb 2013 14:20:03 -0000 Hi, Stewart and I will hold office hours on Tuesday from 11.30(ish) to 13.00. Not sure how lunch will be working, but we will try to grab something that we can eat while you talk to us. (Moved from the usual Sunday afternoon to avoid a conflict with the IAOC's tutorial and open-house). Meeting room will be the IESG Office. Thanks, Adrian and Stewart From jdrake@juniper.net Wed Feb 20 07:22:15 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DB721F8771; Wed, 20 Feb 2013 07:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arITf8POkzJN; Wed, 20 Feb 2013 07:22:12 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id B4F1221F8788; Wed, 20 Feb 2013 07:22:10 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUSTqIRpWyDotKwExsiMm5HDfz/BMzykM@postini.com; Wed, 20 Feb 2013 07:22:10 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 20 Feb 2013 07:09:37 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Wed, 20 Feb 2013 07:09:37 -0800 Received: from am1outboundpool.messaging.microsoft.com (213.199.154.206) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 20 Feb 2013 07:12:02 -0800 Received: from mail17-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Feb 2013 15:09:35 +0000 Received: from mail17-am1 (localhost [127.0.0.1]) by mail17-am1-R.bigfish.com (Postfix) with ESMTP id ECB054000D9; Wed, 20 Feb 2013 15:09:34 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); (null); H:BL2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -25 X-BigFish: PS-25(zz9371I542I1432Ief7I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received: from mail17-am1 (localhost.localdomain [127.0.0.1]) by mail17-am1 (MessageSwitch) id 1361372973239648_14619; Wed, 20 Feb 2013 15:09:33 +0000 (UTC) Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.246]) by mail17-am1.bigfish.com (Postfix) with ESMTP id 2E07E360277; Wed, 20 Feb 2013 15:09:33 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Feb 2013 15:09:33 +0000 Received: from BL2PRD0510MB349.namprd05.prod.outlook.com ([169.254.1.189]) by BL2PRD0510HT001.namprd05.prod.outlook.com ([10.255.100.36]) with mapi id 14.16.0263.000; Wed, 20 Feb 2013 15:09:31 +0000 From: John E Drake To: "adrian@olddog.co.uk" , "rtgwg-chairs@tools.ietf.org" , "routing-discussion@ietf.org" , "rtg-dir@ietf.org" Thread-Topic: [RTG-DIR] Routing ADs Office Hours in Orlando Thread-Index: Ac4PdPb9ZxWLvqWbSVuMKXOs3YAF0QABzRQQ Date: Wed, 20 Feb 2013 15:09:30 +0000 Message-ID: <0182DEA5604B3A44A2EE61F3EE3ED69E1B2736E3@BL2PRD0510MB349.namprd05.prod.outlook.com> References: <026701ce0f75$5ad6f430$1084dc90$@olddog.co.uk> In-Reply-To: <026701ce0f75$5ad6f430$1084dc90$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.224.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "stbryant@cisco.com" Subject: Re: [RTG-DIR] Routing ADs Office Hours in Orlando X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:22:15 -0000 Stewart and Adrian, Just don't talk with your mouth full. Irrespectively Yours, John > -----Original Message----- > From: rtg-dir-bounces@ietf.org [mailto:rtg-dir-bounces@ietf.org] On > Behalf Of Adrian Farrel > Sent: Wednesday, February 20, 2013 6:20 AM > To: rtgwg-chairs@tools.ietf.org; routing-discussion@ietf.org; rtg- > dir@ietf.org > Cc: stbryant@cisco.com > Subject: [RTG-DIR] Routing ADs Office Hours in Orlando >=20 > Hi, >=20 > Stewart and I will hold office hours on Tuesday from 11.30(ish) to > 13.00. Not sure how lunch will be working, but we will try to grab > something that we can eat while you talk to us. >=20 > (Moved from the usual Sunday afternoon to avoid a conflict with the > IAOC's tutorial and open-house). >=20 > Meeting room will be the IESG Office. >=20 > Thanks, > Adrian and Stewart >=20 >=20 >=20 From aretana@cisco.com Fri Feb 22 14:35:52 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4340D1F0D0B for ; Fri, 22 Feb 2013 14:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpoKpy+8vY6c for ; Fri, 22 Feb 2013 14:35:49 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 309661F0D09 for ; Fri, 22 Feb 2013 14:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13653; q=dns/txt; s=iport; t=1361572549; x=1362782149; h=from:to:cc:subject:date:message-id:mime-version; bh=DPgVspt2HoURA2Y7icSwrxUEQ4UDPba3B5PsgyS9S6E=; b=Ai3Z+aotqYpQeLLUb2QY8yShZAO7DBrJTHG4wdV0kx18gbeZVmsr9fgp l+9xTPz2Ngdn0QmfT1Nwg+aYxRfyRgmRofpfnqcOLq6eyZkQBsu6Y+lFJ +tT1b+ikLqT4hXcqc0tEj9Mwxfoo/Jnt51QxA5R1jPSupTDwERMZKTqw2 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFTyJ1GtJV2a/2dsb2JhbABEgkO+cIEOFnOCIQEEeRIBHA5WJwQODQGICQy/Lo5dIBGCZmEDpx2DB4In X-IronPort-AV: E=Sophos;i="4.84,717,1355097600"; d="scan'208,217";a="180241739" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 22 Feb 2013 22:35:48 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1MMZmlA022819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 22:35:48 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.213]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Fri, 22 Feb 2013 16:35:47 -0600 From: "Alvaro Retana (aretana)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-cardenas-dff-09 Thread-Index: AQHOEUz1xiQCtXA2uk2TT8vKKkkfRQ== Date: Fri, 22 Feb 2013 22:35:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.130] Content-Type: multipart/alternative; boundary="_000_BBD66FD99311804F80324E8139B3C94ED80A5Dxmbalnx15ciscocom_" MIME-Version: 1.0 Cc: "rtg-dir@ietf.org" , "draft-cardenas-dff.all@tools.ietf.org" Subject: [RTG-DIR] RtgDir review: draft-cardenas-dff-09 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:35:52 -0000 --_000_BBD66FD99311804F80324E8139B3C94ED80A5Dxmbalnx15ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to t= he 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 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-cardenas-dff-09 Reviewer: Alvaro Retana Review Date: Feb. 22, 2013 IETF LC End Date: Feb. 24, 2013 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resol= ved before publication. Comments: This draft is very well written. It clearly describes the purpose and oper= ation of DFF in a well organized manner. Major Issues: No major issues found. Minor Issues: 1. The term "depth-first search" is used several times (in and out of qu= otes) to characterize DFF. It would be nice if the term was explained at s= ome point; the terminology section would be ideal. 2. The terms "route-over" and "mesh-under" should be defined for the cas= ual reader. 3. Both sections 4.1 and 6.1 give the impression that the Neighbor List = is made up of information received from ONLY "an external neighborhood disc= overy mechanism", when in fact (as was explained in sections 4 and 11) info= rmation from the RIB can also be used. It seems obvious that local RIB inf= ormation could be used; clarifying a little would go a long way. 4. Section 6 ("Information Sets") talks about what was described in sect= ion 4.1 as an "information base". Either terms is fine with me, but there = needs to be consistency. 5. Section 4.2 reads (last paragraph): "..if a router receives a Packet = with DUP =3D 1 (and RET =3D 0) that it has already forwarded, the Packet is= not considered looping, and successively forwarded to the next router.." = I'm at a loss of why would the router forward the packet if it is a duplica= te of one that it has already forwarded. Note also that the case where the= packet was in fact delivered, but no link layer confirmation was received = (so the sender set DUP :=3D 1 and retransmitted) is not covered in the deta= iled explanation in section 9.2 =97 this is a case where RET =3D 0 and the = tuple exits, but it is not a loop. 6. In section 9 the term "generated" is used to indicate that a router c= reates a packet that goes into the DFF domain. The Terminology section des= cribed "originator" as the router that adds the header. The terms should b= e consistent. 7. Given the conditions in the applicability statement I doubt that the = sequence numbers will wrap while tuples (with the lower numbers) are still = in the table. It would be nice to indicate what to do; maybe flush the tup= les is the answer or maybe just indicate that this is one of the items to g= ather experience during experimentation. Nits: 1. s/neighbors provided of by an external neighborhood discovery/neighbo= rs provided by an external neighborhood discovery In the first paragraph = in Section 4. 2. IMHO, the second paragraph in Section 4.1 doesn't provide any content= and could be deleted. 3. s/increasing the route cost of the route using the Next Hop/increasin= g the route cost of the router using the Next Hop In the second paragraph= in 4.2. 4. s/flag is included in the DFF Header/flag is set in the DFF header = When describing DUP in section 7. Using "included" just indicates that t= he flag is present, which it is even if set to 0. ;-) 5. s/Processed Tuples for a Packet is still/Processed Tuple for a Packet= is still When describing P_HOLD_TIME in section 8. 6. Terminology sections. I thought that section 2.2 did a good job, so = I found 14.1.1 and 14.2.4 redundant. 7. "Sequence Number" is not described when presenting the packet formats= . --_000_BBD66FD99311804F80324E8139B3C94ED80A5Dxmbalnx15ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hello,

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

Although these comments are primarily for the use of the Routing ADs, it 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-cardenas-dff-09
Reviewer: Alvaro Retana 
Review Date: Feb. 22, 2013
IETF LC End Date: Feb. 24, 2013 
Intended Status: Experimental

Summary:

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

Comments:

This draft is very well written.  It clearly describes the purpos= e and operation of DFF in a well organized manner.

Major Issues:

No major issues found.

Minor Issues:

  1. The term "depth-first search" is used several times (in and out o= f quotes) to characterize DFF.  It would be nice if the term was expla= ined at some point; the terminology section would be ideal.
  2. Both se= ctions 4.1 and 6.1 give the impression that the Neighbor List is made up of= information received from ONLY "an external neighborhood discovery mechanism", when in fact (as was explained in sections 4 and 11) information from the RIB can= also be used.  It seems obvious that local RIB information could be used; clarifying a little would go a long w= ay.
  3. Section 6 ("Information Sets") talks about what was described in = section 4.1 as an "information base".  Either terms is fine = with me, but there needs to be consistency.
  4. Section 4.2 reads (last paragraph): "..if a router receives a Packet with = DUP =3D 1 (and RET =3D 0) that it has already forwarded, the Packet is not considered looping, and successively forwarded to the nex= t router.."  I'm at a loss of why would the router forward the pa= cket if it is a duplicate of one that it has already forwarded.  Note also that the c= ase where the packet was in fact delivered, but no link layer confirmation = was received (so the sender set DUP :=3D 1 and retransmitted) is not covere= d in the detailed explanation in section 9.2 =97 this is a case where RET =3D 0 and&n= bsp;the tuple exits, but it is not a loop.
  5. In section 9 the = term "generated" is used to indicate that a router creates a pack= et that goes into the DFF domain.  The Terminology section described &= quot;originator" as the router that adds the header.  The terms s= hould be consistent.
  6. Given the conditions in the applicability stat= ement I doubt that the sequence numbers will wrap while tuples (with the lo= wer numbers) are still in the table.  It would be nice to indicate wha= t to do; maybe flush the tuples is the answer or maybe just indicate that this is one of the items to gather experience during experimentation.=

Nits:

  1. s/neighbors provided of by an external neighborhood discovery/neighbors provided by= an external neighborhood discovery   In the first paragraph in Sectio= n 4.
  2. IMHO, the second paragraph in Section 4.1 doesn't provide any content and c= ould be deleted.
  3. s/increasing the route cost of the route usin= g the Next Hop/in= creasing the route cost of the router using the Next Hop   In the second paragraph= in 4.2.
  4. s/flag is included in the DFF = ;Header/flag is set in the DFF header &nb= sp;   When describing DUP in section 7.  Using "include= d" just indicates that the flag is present, which it is even if set to= 0. ;-)
  5. s/Processed Tuples for a Packet is still/Processed T= uple for a Packet is still     When describing P_HOLD_TIME in section 8.
  6. Terminology sections.  I thought that sect= ion 2.2 did a good job, so I found 14.1.1 and 14.2.4 redundant.
    7. =
  7. "Sequence Number" is not de= scribed when presenting the packet formats.
--_000_BBD66FD99311804F80324E8139B3C94ED80A5Dxmbalnx15ciscocom_-- From adrian@olddog.co.uk Thu Feb 28 05:58:52 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4421F88A2; Thu, 28 Feb 2013 05:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSHeb7nAN4C5; Thu, 28 Feb 2013 05:58:51 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 495AA21F8881; Thu, 28 Feb 2013 05:58:51 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1SDwm0b020089; Thu, 28 Feb 2013 13:58:48 GMT Received: from 950129200 (089144192031.atnat0001.highway.a1.net [89.144.192.31]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1SDwUbn019733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 13:58:47 GMT From: "Adrian Farrel" To: Date: Thu, 28 Feb 2013 13:58:32 -0000 Message-ID: <008701ce15bb$bc87ff20$3597fd60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4VqBA9zxE3XKqsRzanD8+wl8QPvg== Content-Language: en-gb Cc: draft-mrw-abfab-trust-router@tools.ietf.org, rtg-dir@ietf.org, rtgwg-chairs@tools.ietf.org Subject: [RTG-DIR] Discussion topic for Routing Area Open Meeting in Orlando X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 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, 28 Feb 2013 13:58:52 -0000 Hi, In the Routing Area meeting in Orlando we will continue our occasional series of discussions of "routing in other areas". In this case we will spend some time on "Trust Routers". Although this topic is not about routing packets, the tree construction and "shortest" path computations have some resemblance to BGP and other routing protocols, and there are also similarities to the SIP routing issues that we heard about a while back. The authors say it would interesting to get some routing folks involved to make sure we avoid the well-understood pitfalls with those sorts of algorithms. It looks to me to me that there are many commonalities of functional concept even if the environment (i.e. application space) is free of many of the constraints we see on routers. As background reading, you might like to look at: http://datatracker.ietf.org/doc/ You can also look at two older (i.e., expired) drafts: http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-02 http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02 Thanks, Adrian From mrw@lilacglade.org Thu Feb 28 07:07:30 2013 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85EAC21F8C04; Thu, 28 Feb 2013 07:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv-WbAQfkM92; Thu, 28 Feb 2013 07:07:16 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 430A921F8BEA; Thu, 28 Feb 2013 07:07:16 -0800 (PST) Received: from new-host-4.home (pool-71-184-79-25.bstnma.fios.verizon.net [71.184.79.25]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.painless-security.com (Postfix) with ESMTPSA id 9AC6620144; Thu, 28 Feb 2013 10:02:18 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Margaret Wasserman In-Reply-To: <008701ce15bb$bc87ff20$3597fd60$@olddog.co.uk> Date: Thu, 28 Feb 2013 10:07:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <27839D85-247E-4BA3-8E4D-0250E40FBCEF@lilacglade.org> References: <008701ce15bb$bc87ff20$3597fd60$@olddog.co.uk> To: X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Thu, 28 Feb 2013 07:12:22 -0800 Cc: draft-mrw-abfab-trust-router@tools.ietf.org, rtg-dir@ietf.org, rtgwg-chairs@tools.ietf.org, routing-discussion@ietf.org Subject: Re: [RTG-DIR] Discussion topic for Routing Area Open Meeting in Orlando X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:07:30 -0000 On Feb 28, 2013, at 8:58 AM, "Adrian Farrel" = wrote: >=20 > As background reading, you might like to look at: > http://datatracker.ietf.org/doc/=09 This should be: http://datatracker.ietf.org/doc/draft-mrw-abfab-trust-router/ For those of you who are unfamiliar with Application Bridging Beyond the = Web (abfab), you might also wish to look at the abfab architecture = document to understand the environment in which the Trust Router is = intended to work. It can be found here: http://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ Margaret