From thomas.morin@orange.com Mon Dec 2 01:44:01 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A4B1AE0B6; Mon, 2 Dec 2013 01:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Glmz5tk98oT5; Mon, 2 Dec 2013 01:43:59 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 365541AE0A7; Mon, 2 Dec 2013 01:43:59 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 583743B4236; Mon, 2 Dec 2013 10:43:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2770D15805B; Mon, 2 Dec 2013 10:43:56 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 2 Dec 2013 10:43:55 +0100 From: To: "rtg-ads@tools.ietf.org" Subject: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Topic: RtgDir review: draft-ietf-bfd-on-lags-03 Thread-Index: AQHO70MEYTO6iOJ7iEi+neAeVWl4UA== Date: Mon, 2 Dec 2013 09:43:55 +0000 Message-ID: <19505_1385977436_529C565C_19505_3941_1_529C55A2.7010802@orange.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="utf-8" Content-ID: <79643554AEEE1844A5F56107BD07E487@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.30.60616 X-Mailman-Approved-At: Mon, 02 Dec 2013 10:17:38 -0800 Cc: "rtg-dir@ietf.org" , "rtg-bfd@ietf.org" , "draft-ietf-bfd-on-lags.all@tools.ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 09:44:01 -0000 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiANClRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtz IHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgDQpkcmFmdHMgYXMgdGhl eSBwYXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQgDQpzb21l dGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRv IHByb3ZpZGUgDQphc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3Jt YXRpb24gYWJvdXQgdGhlIFJvdXRpbmcgDQpEaXJlY3RvcmF0ZSwgcGxlYXNlIHNlZWh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCg0KQWx0aG91Z2ggdGhl c2UgY29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMs IGl0IA0Kd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3 aXRoIGFueSBvdGhlciBJRVRGIA0KTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUs IGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggDQpkaXNjdXNzaW9uIG9yIGJ5IHVw ZGF0aW5nIHRoZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtYmZkLW9uLWxhZ3MtMDMN ClJldmlld2VyOiBUaG9tYXMgTW9yaW4NClJldmlldyBEYXRlOiBEZWNlbWJlciAxc3QsIDIwMTMN CklFVEYgTEMgRW5kIERhdGU6IERlY2VtYmVyIDJuZCwgMjAxMw0KSW50ZW5kZWQgU3RhdHVzOiBQ cm9wb3NlZCBTdGFuZGFyZA0KDQpTdW1tYXJ5Og0KDQogICBUaGUgZG9jdW1lbnQgaXMgY29uY2lz ZSwgd2VsbCB3cml0dGVuLCBhbmQgcmFpc2VzIG5vIG1ham9yIGlzc3VlLg0KICAgSG93ZXZlciwg YnJpbmdpbmcgY2xhcmlmaWNhdGlvbnMgdG8gYSBmZXcgYXJlYXMgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgDQpwcmlvciB0byBwdWJsaWNhdGlvbi4NCg0KTWFqb3IgSXNzdWVzOg0KDQogICBOb25lLg0K DQoNCk1pbm9yIElzc3VlczoNCg0KLSBNaS4xKSBUaGUgZG9jdW1lbnQgbWVudGlvbnMgdGhlIHVz ZSBvZiBhIHNwZWNpZmljIFVEUCBwb3J0IGZvciB0aGUgDQptaWNyby1CRkQgc2Vzc2lvbnMgKDY3 ODQpLiBJdCBzaG91bGQgcHJvYmFibHkgZXhwbGFpbiB3aGF0IGlzIHRoZSANCmJlaGF2aW9yIGlm IEJGRCBtZXNzYWdlcyBmcm9tIGEgbWljcm8tQkZEIHNlc3Npb25zIGFyZSByZWNlaXZlZCBvbiB0 aGUgDQpub3JtYWwgQkZEIHBvcnQgKDM3ODQpLCBhbmQgdmljZS12ZXJzYSB3aGF0IGlzIHRoZSBi ZWhhdmlvciBmb3IgQkZEIA0KbWVzc2FnZXMgZnJvbSBhIG5vbi1CRkQgc2Vzc2lvbnMgaXMgcmVj ZWl2ZWQgb24gdGhlIG1pY3JvLUJGRCBVRFAgcG9ydC4NCg0KLSBNaS4yKSBUaGUgZG9jdW1lbnQg aW5kaWNhdGVzIGluIHNlY3Rpb24gMi4yIHRoYXQgIlRoZSBkZXRhaWxzIG9mIGhvdyANClt0aGUg ZGVzdGluYXRpb24gSVAgYWRkcmVzcyBvZiB0aGUgQkZEIHBlZXJdIGlzIGxlYXJuZWQgYXJlIG91 dHNpZGUgdGhlIA0Kc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4iLiAgRmlyc3QsIGFuIGV4YW1wbGUg b2YgYSBjb21tb24gcHJhY3RpY2Ugd291bGQgDQpiZSBncmVhdCB0byBwcm92aWRlIGFuIGlsbHVz dHJhdGlvbi4gIFNlY29uZCwgSSB3b3VsZCBmaW5kIGl0IHdvcnRoIA0KZG9jdW1lbnRpbmcgaG93 IHRoaXMgY2FuIGJlIGRvbmUgaW4gcHJhY3RpY2Ugb24gYW4gdW5udW1iZXJlZCBsaW5rDQoNCi0g TWkuMykgVGhlIG5vdGlvbiBvZiAiTDMgY29udGludWl0eSIgaXMgdXNlZCBpbiB0aGUgaW50cm9k dWN0aW9uLCBidXQgDQppdCBpcyBub3QgZXhwbGFpbmVkIHdoYXQgdGhpcyBtZWFuczsgaXQgd291 bGQgZGVzZXJ2ZSBiZWluZyBleHBsYWluZWQgYXMgDQp0aGUgaWRlYSBvZiAiY29udGludWl0eSIg bWF5IG5vdCBiZSBvYnZpb3VzIHRvIGludGVycHJldCBpbiBhIGNvbnRlY3QgDQp3aGVyZSBhIHNp bmdsZSBMMyBob3AgaXMgYmVpbmcgdGVzdGVkLg0KDQotIE1pLjQpIFNlY3Rpb24gNCBtZW50aW9u cyAiTE1NIiBhbmQgInNvbWUgSW50ZXJmYWNlIG1hbmFnZW1lbnQgbW9kdWxlIiANCndpdGhvdXQg cHJvdmlkaW5nIGFueSBkZWZpbml0aW9uIG5vciBleHBsYWluaW5nIHRoZSByb2xlIG9mIHN1Y2gg bW9kdWxlcy4NCg0KLSBNaS41KSBUaGUgYmVoYXZpb3IgZGVzY3JpYmVkIGluIHRoZSBBcHBlbmRp eCBsb29rcyB2ZXJ5IGltcG9ydGFudCBmb3IgDQpzbW9vdGggYWN0aXZhdGlvbiBvZiB0aGUgZmVh dHVyZSBpbiBhIHJlYWwgbmV0d29yayBhbmQgaXMgYWN0dWFsbHkgDQpzcGVjaWZpY2F0aW9uIHRl eHQuIEknbSB0aHVzIHN1cnByaXNlZCB0byBmaW5kIGl0IGluIGFuIEFwcGVuZGl4IC0tIA0Kd2hl cmUgaXQgY291bGQgYmUgbWlzc2VkIGJ5IGltcGxlbWVudG9ycy4gIEkgd291bGQgc3VnZ2VzdCBj b25zaWRlcmluZyANCm1vdmluZyB0aGlzIHRleHQgYW1vbmcgdGhlIHJlc3Qgb2YgdGVjaG5pY2Fs IHNwZWNpZmljYXRpb25zIHNlY3Rpb25zLg0KDQoNCioqIEVkaXRvcmlhbCBjb21tZW50czoNCg0K LSBFZC4xKSBJIHdvdWxkIHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIG1lbnRpb24gb2YgdGhlIHVzZSBv ZiBhIHNwZWNpZmljIA0KVURQIHBvcnQgZnJvbSB0aGUgQWJzdHJhY3QsIHdoaWNoIHdvdWxkIHRo ZW4gYmUgbW9yZSBjb25jaXNlIC0tIHRoZSANCm1vdGl2YXRpb24gZm9yIHVzaW5nIGEgc3BlY2lm aWMgVURQIHBvcnQgc28gY291bGQgYmUgcHJvdmlkZWQgaW4gc2VjdGlvbiANCjIuMi4NCg0KLSBF ZC4yKSBTZWN0aW9uIDIuMzogIkZvciB0aGUgZm9sbG93aW5nIEJGRCBwYWNrZXRzIHdpdGggVXAg c3RhdGUgdGhlIA0KTUFDIGFkZHJlc3MgZnJvbSB0aGUgcmVjZWl2ZWQgQkZEIHBhY2tldHMgZm9y IHRoZSBzZXNzaW9uIE1BWSBiZSB1c2VkIA0KaW5zdGVhZCBvZiB0aGUgZGVkaWNhdGVkIE1BQy4g Ig0KDQogICAgPT4gInRoZSBfc291cmNlXyBNQUMgYWRkcmVzcyBmcm9tIHRoZSByZWNlaXZlZCBC RkQgcGFja2V0cyIgPyANCihhZGRpbmcgInNvdXJjZSIgd291bGQgcmVtb3ZlIGFueSByaXNrIG9m IGFtYmlndW91cyBpbnRlcnByZXRhdGlvbikNCg0KLSBFZC4zKSBTZWN0aW9uIDU6ICJNQVkgcmVt b3ZlIHRoZSBtZW1iZXIgbGluayBmcm9tIHRoZSBsb2FkIGJhbGFuY2UgDQp0YWJsZSBvbmx5IHRo YXQgbWF0Y2hlcyB0aGUgYWRkcmVzcyBmYW1pbHkgb2YgdGhlIGZhaWxpbmcgQkZEIHNlc3Npb24i DQoNCiAgIEkgaGFkIGlzc3VlcyBwYXJzaW5nIHRoaXMgc2VudGVuY2U7IHdoYXQgYWJvdXQ6ICJN QVkgcmVtb3ZlIHRoZSANCm1lbWJlciBsaW5rIGZyb20gb25seSB0aGUgbG9hZCBiYWxhbmNlIHRh YmxlIHRoYXQgbWF0Y2hlcy4uLiINCg0KICAgRnVydGhlcm1vcmUsIGl0IHdvdWxkIGJlIG5pY2Ug dG8gYWRkIGEgY29sb24gYXQgdGhlIGVuZCBvZiB0aGUgDQpzZW50ZW5jZSB0byBpbmRpY2F0ZSB0 aGF0IHdoYXQgZm9sbG93cyBpcyBhbiBpbGx1c3RyYXRpb24gb2Ygd2hhdCBwcmVjZWRlcy4NCg0K ICAgTGFzdCwgSSB0aGluayBpdCB3b3VsZCBiZSB3b3J0aCBpbmRpY2F0aW5nIGV4cGxpY2l0bHkg dGhhdCAiVGhlIA0KbWVtYmVyIGxpbmsgTUFZIGFsc28gYmUgcmVtb3ZlZCBmcm9tIGJvdGggdGhl IEw0IGFuZCBMNiBsb2FkIGJhbGFuY2luZyANCnRhYmxlIi4NCg0KLSBFZC40KSBJIGJlbGlldmUg eW91IG5lZWQgdG8gdXBkYXRlIGNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIE5pdGluIEJhaGFkdXIu DQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQg Y29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVz IGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From adrian@olddog.co.uk Thu Dec 5 03:11:31 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5DD1ADED5; Thu, 5 Dec 2013 03:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IsFYLvmLRr6; Thu, 5 Dec 2013 03:11:25 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 23B381ADF38; Thu, 5 Dec 2013 03:11:23 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB5BBJOP030412; Thu, 5 Dec 2013 11:11:19 GMT Received: from 950129200 (no-dns-yet.demon.co.uk [62.49.66.12] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB5BBGix030374 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 11:11:18 GMT From: "Adrian Farrel" To: Subject: Tweak to charter text Date: Thu, 5 Dec 2013 11:11:16 -0000 Message-ID: <12f301cef1aa$b8fd5eb0$2af81c10$@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: Ac7xqq9+/mQ8eALHTgaLTLWHSyR9ew== Content-Language: en-gb Cc: iesg@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 11:11:31 -0000 Hi, The BFD charter is in front of the IESG this week to review the addition of point 6 During his review Sean Turner pointed out that we have recently had a problem with over-zealous truncation of HMACs in a routing protocol rendering it potentially unsecured. Therefore, he was nervous about the text in 2c that suggests possible truncation. I have made the following change to fix this. OLD 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value) using the generic keying-based cryptographic authentication mechanism. NEW 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. END Cheers, Adrian From adrian@olddog.co.uk Thu Dec 5 10:19:18 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACDC1AE0E1 for ; Thu, 5 Dec 2013 10:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42vuJ0m_hdsu for ; Thu, 5 Dec 2013 10:19:15 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id EAB071AE107 for ; Thu, 5 Dec 2013 10:19:14 -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 rB5IJ9Js002839 for ; Thu, 5 Dec 2013 18:19:10 GMT Received: from 950129200 (no-dns-yet.demon.co.uk [62.49.66.12] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rB5IJ8cW002827 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 5 Dec 2013 18:19:09 GMT From: "Adrian Farrel" To: Subject: Charter changes approved Date: Thu, 5 Dec 2013 18:19:07 -0000 Message-ID: <007101cef1e6$7d5f1b00$781d5100$@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: Ac7x5nvdiFeRXbMWTI6yCSNHcAJTAw== Content-Language: en-gb X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 18:19:18 -0000 Hi, The IESG just approved the revised charter as shown at https://will datatracker.ietf.org/doc/charter-ietf-bfd/ It will take the Secretariat a couple of days to make the formal announcement, but don't let that stop you working! Adrian From jhaas@slice.pfrc.org Thu Dec 5 10:30:50 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329821AE0C0 for ; Thu, 5 Dec 2013 10:30:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUOm_Zr7oRta for ; Thu, 5 Dec 2013 10:30:49 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB471AE098 for ; Thu, 5 Dec 2013 10:30:49 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id E22AFC206; Thu, 5 Dec 2013 13:30:45 -0500 (EST) Date: Thu, 5 Dec 2013 13:30:45 -0500 From: Jeffrey Haas To: Adrian Farrel Subject: Re: Charter changes approved Message-ID: <20131205183045.GA3176@pfrc> References: <007101cef1e6$7d5f1b00$781d5100$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007101cef1e6$7d5f1b00$781d5100$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 18:30:50 -0000 On Thu, Dec 05, 2013 at 06:19:07PM -0000, Adrian Farrel wrote: > The IESG just approved the revised charter as shown at https://will > datatracker.ietf.org/doc/charter-ietf-bfd/ > > It will take the Secretariat a couple of days to make the formal announcement, > but don't let that stop you working! Thank you, Adrian. BFD Intervals authors, please re-submit your draft after making the changes already discussed (including status) as a draft-ietf-bfd-intervals draft. -- Jeff From iesg-secretary@ietf.org Fri Dec 6 09:27:02 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33C1AD83F; Fri, 6 Dec 2013 09:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-O5BAs4NplZ; Fri, 6 Dec 2013 09:27:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A75011AE0A7; Fri, 6 Dec 2013 09:26:56 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: WG Action: Rechartered Bidirectional Forwarding Detection (bfd) X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206172656.7638.6089.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 09:26:56 -0800 Cc: bfd WG X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:27:03 -0000 The Bidirectional Forwarding Detection (bfd) working group in the Routing Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Bidirectional Forwarding Detection (bfd) ------------------------------------------------ Current Status: Active WG Chairs: Nobo Akiya Jeffrey Haas Technical advisors: Dave Katz David Ward Assigned Area Director: Adrian Farrel Mailing list Address: rtg-bfd@ietf.org To Subscribe: rtg-bfd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/rtg-bfd/ Charter: The BFD Working Group is chartered to standardize and support the bidirectional forwarding detection protocol (BFD) and its extensions. A core goal of the working group is to standardize BFD in the context of IP routing, or protocols such as MPLS that are based on IP routing, in a way that will encourage multiple, inter-operable vendor implementations. The Working Group will also provide advice and guidance on BFD to other working groups or standards bodies as requested. BFD is a protocol intended to detect faults in the bidirectional path between two forwarding engines, including physical interfaces, subinterfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. An additional goal is to provide a single mechanism that can be used for liveness detection over any media, at any protocol layer, with a wide range of detection times and overhead, to avoid a proliferation of different methods. Important characteristics of BFD include: - Simple, fixed-field encoding to facilitate implementations in hardware. - Independence of the data protocol being forwarded between two systems. BFD packets are carried as the payload of whatever encapsulating protocol is appropriate for the medium and network. - Path independence: BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS LSPs, multihop routed paths, and unidirectional links (so long as there is some return path, of course). - Ability to be bootstrapped by any other protocol that automatically forms peer, neighbor or adjacency relationships to seed BFD endpoint discovery. The working group is chartered to complete the following work items: 1. Develop the MIB module for BFD and submit it to the IESG for publication as a Proposed Standard. 2a. Provide a generic keying-based cryptographic authentication mechanism for the BFD protocol in discussion with the KARP working group. This mechanism will support authentication through a key identifier for the BFD session's Security Association rather than specifying new authentication extensions. 2b. Provide extensions to the BFD MIB in support of the generic keying- based cryptographic authentication mechanism. 2c. Specify cryptographic authentication procedures for the BFD protocol using HMAC-SHA-256 (possibly truncated to a smaller integrity check value but not beyond commonly accepted lengths to ensure security) using the generic keying-based cryptographic authentication mechanism. 3. Provide an extension to the BFD core protocol in support of point-to- multipoint links and networks. 4. Assist the MPLS working group in the standardization of the BFD protocol for MPLS-TP. The preferred solution will be interoperable with the current BFD specification. 5. Provide one or more mechanisms to run BFD over Link Aggregation Group Interfaces. 6. Provide an informational document to recommend standardized timers and timer operations for BFD when used in different applications. The working group will maintain a relationship with the KARP and MPLS working groups, and will communicate with the IEEE with respect to BFD over LAGs. Milestones: Done - Submit the base protocol specification to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for single-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for MPLS LSPs to the IESG to be considered as a Proposed Standard Done - Submit BFD encapsulation and usage profile for multi-hop IPv4 and IPv6 adjacencies to the IESG to be considered as a Proposed Standard Nov 2013 - Submit the BFD MIB to the IESG to be considered as a Proposed Standard Nov 2013 - Submit the BFD over LAG mechanism to the IESG to be considered as a Proposed Standard Jun 2014 - Submit the the document on BFD point-to-multipoint support to the IESG to be considered as a Proposed Standard Nov 2014 - Submit the BFD MPLS extension MIB to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the generic keying based cryptographic authentication mechanism to the IESG to be considered as a Proposed Standard Jan 2015 - Submit a BFD MIB extension in support of the generic keying document to the IESG to be considered as a Proposed Standard Jan 2015 - Submit the cryptographic authentication procedures for BFD to the IESG to be considered as a Proposed Standard From internet-drafts@ietf.org Wed Dec 18 16:24:51 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4A1ACCE8; Wed, 18 Dec 2013 16:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6zqQMwO-gED; Wed, 18 Dec 2013 16:24:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4D1AC4AB; Wed, 18 Dec 2013 16:24:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-on-lags-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219002449.28695.68179.idtracker@ietfa.amsl.com> Date: Wed, 18 Dec 2013 16:24:49 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 00:24:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : Bidirectional Forwarding Detection (BFD) on Link Aggrega= tion Group (LAG) Interfaces Author(s) : Manav Bhatia Mach(Guoyi) Chen Sami Boutros Marc Binderberger Jeffrey Haas Filename : draft-ietf-bfd-on-lags-04.txt Pages : 11 Date : 2013-12-18 Abstract: This document defines a mechanism to run BFD on Link Aggregation Group (LAG) interfaces. It does so by running an independent Asynchronous mode BFD session on every LAG member link. This mechanism allows the verification of member link continuity, either in combination with, or in absence of, Link Aggregation Control Protocol (LACP). It provides a shorter detection time than what LACP offers. The continuity check can also cover elements of layer 3 bidirectional forwarding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-on-lags There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-on-lags-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-on-lags-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Dec 26 09:04:10 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770E41AE23B; Thu, 26 Dec 2013 09:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTxIFdpIG0Vx; Thu, 26 Dec 2013 09:04:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A13B1ADF78; Thu, 26 Dec 2013 09:04:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-bfd-mpls-mib-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131226170408.19783.68347.idtracker@ietfa.amsl.com> Date: Thu, 26 Dec 2013 09:04:08 -0800 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 17:04:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Bidirectional Forwarding Detection Workin= g Group of the IETF. Title : BFD Management Information Base (MIB) extensions = for MPLS and MPLS-TP Networks Authors : Sam Aldrin Venkatesan Mahalingam Kannan KV Sampath Thomas D. Nadeau Filename : draft-ietf-bfd-mpls-mib-03.txt Pages : 22 Date : 2013-12-26 Abstract: This draft defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it extends the BFD Management Information Base BFD- STD-MIB and describes the managed objects for modeling Bidirectional Forwarding Detection (BFD) protocol for MPLS and MPLS-TP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-mpls-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfd-mpls-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-bfd-mpls-mib-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adrian@olddog.co.uk Sun Dec 29 11:59:12 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE251AE22B for ; Sun, 29 Dec 2013 11:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv0uommJD1YP for ; Sun, 29 Dec 2013 11:59:11 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 9190F1AE1DC for ; Sun, 29 Dec 2013 11:59:11 -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 rBTJx5gk015057; Sun, 29 Dec 2013 19:59:05 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBTJx2qq015043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Dec 2013 19:59:04 GMT From: "Adrian Farrel" To: Subject: AD review of draft-ietf-bfd-tc-mib Date: Sun, 29 Dec 2013 19:59:09 -0000 Message-ID: <06b701cf04d0$70e331c0$52a99540$@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: Ac8E0GpllEYZRDVjQZitSOPA4qtRtA== Content-Language: en-gb Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 19:59:12 -0000 Hi authors of draft-ietf-bfd-tc-mib, I am doing my AD review of this document having received the publication request. The purpose of my review is to clear up any issues that might otherwise show up during IETF last call or IESG review. During my review I have found a number of minor issues with the MIB module. I don't think any substantially change the definitions, but I do think that some editorial work is needed. I believe there will be knock- on editorial changes to draft-ietf-bfd-mib, but nothing of substance that will impact that document. I will put this document into "Revised I-D State", but I would be happy to discuss any of these points if you think that changes are not needed. Thanks for the work. Adrian === Tom may want to update his coordinates. --- I think the Abstract should note that the TCs defined here are maintained by IANA as this is an important feature. BUT... I don't see why all of these TCs are in an IANA module. It seems that a number of them would not be updated by IANA upon the allocation of new protocol code points. I believe the following should be moved to their own module and out of the IANA module... IANAbfdSessIndexTC IANAbfdIntervalTC IANAbfdMultiplierTC IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit enumerations) IANAbfdCtrlSourcePortNumberTC I am suspicious of some of the other TCs as well. Really, an IANA module should be used for TCs that mirror registries. Do the other TCs actually mirror registries? If so you should say which. If not, then you should probably move them out of the IANA module as well. --- Could you swap Sections 1 and 2 so that the document begins with the Introduction. --- A number of TCs could usefully have Reference clauses so that the meaning of the TC is more clearly understood. From jhaas@slice.pfrc.org Sun Dec 29 13:14:00 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F91F1AE2AD for ; Sun, 29 Dec 2013 13:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xq2diOFjScIX for ; Sun, 29 Dec 2013 13:13:59 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 26D8C1AE28F for ; Sun, 29 Dec 2013 13:13:59 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7B5D5C2C8; Sun, 29 Dec 2013 16:13:53 -0500 (EST) Date: Sun, 29 Dec 2013 16:13:53 -0500 From: Jeffrey Haas To: Adrian Farrel Subject: Re: AD review of draft-ietf-bfd-tc-mib Message-ID: <20131229211353.GA9803@pfrc> References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: rtg-bfd@ietf.org, draft-ietf-bfd-tc-mib.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 21:14:00 -0000 Adrian, A brief followup - I'm sure the authors will have comments of their own: On Sun, Dec 29, 2013 at 07:59:09PM -0000, Adrian Farrel wrote: > I think the Abstract should note that the TCs defined here are maintained > by IANA as this is an important feature. > > BUT... > > I don't see why all of these TCs are in an IANA module. It seems that a > number of them would not be updated by IANA upon the allocation of new > protocol code points. I believe the following should be moved to their > own module and out of the IANA module... > > IANAbfdSessIndexTC > IANAbfdIntervalTC > IANAbfdMultiplierTC > IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit > enumerations) > IANAbfdCtrlSourcePortNumberTC > > I am suspicious of some of the other TCs as well. Really, an IANA > module should be used for TCs that mirror registries. Do the other > TCs actually mirror registries? If so you should say which. If not, > then you should probably move them out of the IANA module as well. Since this happened as part of last minute review, it's no surprise that this wasn't quite done correctly. Is your preference to have a separate draft for this separation or could both TC MIBs occur in the same document? I suspect once this detail is settled, the remainder of your changes should happen in short order. -- Jeff From adrian@olddog.co.uk Mon Dec 30 04:36:22 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC711ACC88 for ; Mon, 30 Dec 2013 04:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-yzhNsLElKF for ; Mon, 30 Dec 2013 04:36:20 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 900401AE006 for ; Mon, 30 Dec 2013 04:36:20 -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 rBUCaDKq014208; Mon, 30 Dec 2013 12:36:13 GMT Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBUCaB5M014177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Dec 2013 12:36:12 GMT From: "Adrian Farrel" To: "'Jeffrey Haas'" References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> <20131229211353.GA9803@pfrc> In-Reply-To: <20131229211353.GA9803@pfrc> Subject: RE: AD review of draft-ietf-bfd-tc-mib Date: Mon, 30 Dec 2013 12:36:16 -0000 Message-ID: <075d01cf055b$bda406c0$38ec1440$@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: AQGlDvm5h+j4+T5nMSyBexsZ2Ebe0gKEXlHQmqx138A= Content-Language: en-gb Cc: rtg-bfd@ietf.org, draft-ietf-bfd-tc-mib.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 12:36:23 -0000 Hi Jeff, > > I am suspicious of some of the other TCs as well. Really, an IANA > > module should be used for TCs that mirror registries. Do the other > > TCs actually mirror registries? If so you should say which. If not, > > then you should probably move them out of the IANA module as well. > > Since this happened as part of last minute review, it's no surprise that > this wasn't quite done correctly. Yeah. No criticism. > Is your preference to have a separate draft for this separation or could > both TC MIBs occur in the same document? It's fine to have one document containing two MIB modules: 1. The generic BFD TC MIB module 2. The IANA BFD TC MIB module I would put the whole of 2 in the IANA Considerations section. > I suspect once this detail is settled, the remainder of your changes should > happen in short order. Excellent. Review of the BFD module is coming soon. Adrian From adrian@olddog.co.uk Mon Dec 30 05:03:02 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37251AE001 for ; Mon, 30 Dec 2013 05:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfjtlYIr40k0 for ; Mon, 30 Dec 2013 05:03:01 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF9A1ADFDD for ; Mon, 30 Dec 2013 05:03:00 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBUD2sZE004068; Mon, 30 Dec 2013 13:02:54 GMT Received: from 950129200 (13.17.90.92.rev.sfr.net [92.90.17.13]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBUD2pHi004062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Dec 2013 13:02:53 GMT From: "Adrian Farrel" To: Subject: AD review of draft-ietf-bfd-mib Date: Mon, 30 Dec 2013 13:02:58 -0000 Message-ID: <075e01cf055f$77a1d400$66e57c00$@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: Ac8FX0xMV0n63iAxRmuydGul4Cdnww== Content-Language: en-gb X-TM-AS-MML: No Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 13:03:02 -0000 Hi authors of draft-ietf-bfd-mib, I have done my usual AD review after receiving a publication request. The purpose of the review is to catch issues that would show up during IETF last call or IESG review and so save the reviewers some time and get the quality up to a level that is acceptable. This document represents a lot of work: thank you. The issues I have found are relatively small. Some of them take the form of questions and you can answer these with email rather than feeling compelled to make documentation changes. Furthermore, all of the issues are open for discussion. I will put the document into "Revised I-D" state and wait to hear back from you. Thanks, Adrian === You'll obviously want to make updates to accommodate changes to draft-ietf-bfd-tc-mib --- Tom may want to change his coordinates. --- Could you swap sections 1 and 2 so that the document starts with the Introduction. --- Section 2 s/an portion/a portion/ --- Section 4.4 I don't think the table maps a discriminator to a TC. Maybe it maps the discriminator to the session or the session index or something. The same thing shows up in some of the Description clauses, for example, bfdSessDiscMapTable --- Similarly 4.5 --- It is nice if you name the RFCs in comments next to the import clauses. --- If I am creating an entry in bfdSessTable (and it seems that I can since most of the objects are read-create) how do I know what value to pick for bfdSessIndex? A way to handle this is through a "next available index" global object. --- bfdAdminStatus is ambiguous! Does setting bfdSessAdminStatus to "start" mean that the session is up or only that the implementation will attempt to bring it up? The normal approach is to have adminStatus described as "the desired operational status" and a separate object reports the actual operStatus. Since you have bfdSessOperMode, I think this is your intention. --- bfdSessState and bfdSessRemoteHeardFlag are read-only. What does it mean to have default values? --- Doesn't bfdSessMultipointFlag need a reference to the document that defines multipoint BFD? If so, doesn't that create a normative reference gate for this MIB module? That means you either take multipoint out or you will have to wait until it completes the process. --- You appear to have two mechanisms to turn off GTSM bfdSessGTSM OBJECT-TYPE SYNTAX TruthValue DESCRIPTION "Setting the value of this object to true(1) will enable GTSM protection of the BFD session. ... So presumably setting it to false will disable GTSM. But... bfdSessGTSMTTL OBJECT-TYPE SYNTAX Unsigned32 (0..255) DESCRIPTION The value of zero(0) indicates that bfdSessGTSM is disabled." --- bfdSessAuthPresFlag has a default of false indicating that no authentication is to be used. And bfdSessAuthenticationType has a default of -1 meaning no authentication is in use. Doesn't that mean that the default for bfdSessGTSM should be true and the default for bfdSessGTSMTTL should be non-zero? --- Why don't objects like bfdSessDesiredMinTxInterval have default values? --- Shouldn't the default for bfdSessAuthenticationType be noAuthentication not -1? --- I am unsure about how the three objects for authentication work. bfdSessAuthenticationType and bfdSessAuthenticationKeyID say that they must be -1 if bfdSessAuthPresFlag is false. Now, suppose I want to turn on authentication. I want to set bfdSessAuthPresFlag to true, but if I do, the settings of bfdSessAuthenticationType and bfdSessAuthenticationKeyID are bogus. But if I want to set bfdSessAuthenticationType and bfdSessAuthenticationKeyID to real values in preparation to setting bfdSessAuthPresFlag to true then I will have broken the rule. The only option appears to set all three objects at once (which is possible only depending on implementation). --- I'm surprised that entries in bfdSessDiscMapTable are writeable. That is to say, that bfdSessDiscMapStorageType and bfdSessDiscMapRowStatus exist and are writeable. Surely this table is automatic and entries an artifice of entries in bfdSessTable. Why would you want an entry in this table to have a different storage type or row status from those in bfdSessTable? What does it mean that those two objects are creatable? Does it mean that you can create an entry in this table without knowing the value of bfdSessDiscMapIndex which is automatic? Same questions about bfdSessIpMapTable --- The Security section says... The bfdSessAuthenticationType, bfdSessAuthenticationKeyID, and bfdSessAuthenticationKey objects hold security methods and associated security keys of BFD sessions. These objects SHOULD be considered highly sensitive objects. In order for these sensitive information from being improperly accessed, implementers MAY wish to disallow read and create access to these objects. You don't want to prevent write access as well? But note that preventing read access is pretty much not having the object. So why *do* you have the objects and then suggest not providing any access to them? From tnadeau@lucidvision.com Mon Dec 30 05:55:03 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305821AE027 for ; Mon, 30 Dec 2013 05:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COci15AcEFmO for ; Mon, 30 Dec 2013 05:55:01 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBC31ADFA6 for ; Mon, 30 Dec 2013 05:55:01 -0800 (PST) Received: from [192.168.1.101] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 7FEDD269BDD9; Mon, 30 Dec 2013 08:54:55 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_7E4FDDAB-3B14-43AD-B372-54C5AFAE5C4E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: AD review of draft-ietf-bfd-tc-mib From: Thomas Nadeau In-Reply-To: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> Date: Mon, 30 Dec 2013 08:54:54 -0500 Message-Id: References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1827) Cc: rtg-bfd@ietf.org, draft-ietf-bfd-tc-mib.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 13:55:03 -0000 --Apple-Mail=_7E4FDDAB-3B14-43AD-B372-54C5AFAE5C4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 29, 2013:2:59 PM, at 2:59 PM, Adrian Farrel = wrote: > Hi authors of draft-ietf-bfd-tc-mib, >=20 > I am doing my AD review of this document having received the = publication > request. The purpose of my review is to clear up any issues that might > otherwise show up during IETF last call or IESG review. >=20 > During my review I have found a number of minor issues with the MIB > module. I don't think any substantially change the definitions, but I = do > think that some editorial work is needed. I believe there will be = knock- > on editorial changes to draft-ietf-bfd-mib, but nothing of substance > that will impact that document. >=20 > I will put this document into "Revised I-D State", but I would be = happy > to discuss any of these points if you think that changes are not = needed. >=20 > Thanks for the work. >=20 > Adrian >=20 > =3D=3D=3D >=20 > Tom may want to update his coordinates. Yes, we will update. > --- >=20 > I think the Abstract should note that the TCs defined here are = maintained > by IANA as this is an important feature. >=20 > BUT... >=20 > I don't see why all of these TCs are in an IANA module. It seems that = a > number of them would not be updated by IANA upon the allocation of new > protocol code points. I believe the following should be moved to their > own module and out of the IANA module... >=20 > IANAbfdSessIndexTC = =20 > IANAbfdIntervalTC > IANAbfdMultiplierTC > IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit > enumerations) > IANAbfdCtrlSourcePortNumberTC >=20 > I am suspicious of some of the other TCs as well. Really, an IANA > module should be used for TCs that mirror registries. Do the other > TCs actually mirror registries? If so you should say which. If not, > then you should probably move them out of the IANA module as well. Yes this is correct. I think we missed this in the last round of = reviews that focused on getting things assembled in the right order/way. = This should be fixed.=20 --Tom >=20 > --- >=20 > Could you swap Sections 1 and 2 so that the document begins with the > Introduction. >=20 > --- >=20 > A number of TCs could usefully have Reference clauses so that the > meaning of the TC is more clearly understood. >=20 >=20 --Apple-Mail=_7E4FDDAB-3B14-43AD-B372-54C5AFAE5C4E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSwXsuAAoJEPcO+I7eiUJZ1KkQAIdVq9wd0eETgsf+Lt3xZpxc 8eg5J/yYcOFjvk+alUpicVaTfvoKS5IM1rAXnQGko+BUYTc01bW7oZ08IETWTvqZ Va50UBLaPE0BjgfxpKg5no3GGg+0wzNaC4sgSj/JeQPjGbKvgAcGllzLCvDUdguP 35vJY7jecWpSkS/TeQfg5lbi2uG6FnnU39o8sYhpA6+yx/0OjDu5ByAAto93+Pbj F7Nd4ZI4wrHzszvRBsRjuqerBk8mIBpC1+Tk0N6ewjKODVpz7HeWVRnG8Nno91QN m3PJ7/10QRnaRKClZJOuC4Zsc11bJ49Kp+cXMG/vbroi4c4gQqGh7Hn5t9Tfx5vV xyc2ti1zERdO+xfPrU+Z8E6nrikFPki30lr7yJjzhAsSyZ3aNEjBefHO3eiIq7s9 M7OcHadZ2SWQGbEnC01Ymci/s0gkiNmts3eDW0jS/L1ulRH/yl/mX8bBvjRt3aWL 5Og+OLShbtmuU3o5laxBgCmU4+qPIfrnxGd9b86SyPWqW14cCeUISOOH/ihYLGle 5keq8JiywCACMgp7HkgbLLVY5u7XeqCfhPFzeMvX78v6g8YJG4l1E0RC8fIsXi0z 16J4qlgdEIc9N1EgJ1gGAcrMTqyaMGkJt1VqCaI96+2XUKrEUiZNROFCHNL5keBU DEfLsu3h+lrIH3qzFiDc =E3KX -----END PGP SIGNATURE----- --Apple-Mail=_7E4FDDAB-3B14-43AD-B372-54C5AFAE5C4E-- From tnadeau@lucidvision.com Mon Dec 30 05:56:49 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5F71AE027 for ; Mon, 30 Dec 2013 05:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWLNvqEFbQ6Q for ; Mon, 30 Dec 2013 05:56:48 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id BB6441ADFA6 for ; Mon, 30 Dec 2013 05:56:47 -0800 (PST) Received: from [192.168.1.101] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C9E64269BE3F; Mon, 30 Dec 2013 08:56:41 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_5A4A30B7-77DA-4A52-AE95-0656B27CB0FF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: AD review of draft-ietf-bfd-tc-mib From: Thomas Nadeau In-Reply-To: <20131229211353.GA9803@pfrc> Date: Mon, 30 Dec 2013 08:56:40 -0500 Message-Id: <31C0A542-DD58-4822-A3F7-21D5D1C8829C@lucidvision.com> References: <06b701cf04d0$70e331c0$52a99540$@olddog.co.uk> <20131229211353.GA9803@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1827) Cc: rtg-bfd@ietf.org, draft-ietf-bfd-tc-mib.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 13:56:49 -0000 --Apple-Mail=_5A4A30B7-77DA-4A52-AE95-0656B27CB0FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 29, 2013:4:13 PM, at 4:13 PM, Jeffrey Haas = wrote: > Adrian, >=20 > A brief followup - I'm sure the authors will have comments of their = own: >=20 > On Sun, Dec 29, 2013 at 07:59:09PM -0000, Adrian Farrel wrote: >> I think the Abstract should note that the TCs defined here are = maintained >> by IANA as this is an important feature. >>=20 >> BUT... >>=20 >> I don't see why all of these TCs are in an IANA module. It seems that = a >> number of them would not be updated by IANA upon the allocation of = new >> protocol code points. I believe the following should be moved to = their >> own module and out of the IANA module... >>=20 >> IANAbfdSessIndexTC = =20 >> IANAbfdIntervalTC >> IANAbfdMultiplierTC >> IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit >> enumerations) >> IANAbfdCtrlSourcePortNumberTC >>=20 >> I am suspicious of some of the other TCs as well. Really, an IANA >> module should be used for TCs that mirror registries. Do the other >> TCs actually mirror registries? If so you should say which. If not, >> then you should probably move them out of the IANA module as well. >=20 > Since this happened as part of last minute review, it's no surprise = that > this wasn't quite done correctly. >=20 > Is your preference to have a separate draft for this separation or = could > both TC MIBs occur in the same document? While its been done both ways, I hope it would be sufficient at = this point to have a separate module within the same draft. The biggest = issue with that approach is making sure the ordering is done such that = automated tools that extract the MIBs from the draft/RFC document have = things ordered properly so as to just work.=20 --Tom >=20 > I suspect once this detail is settled, the remainder of your changes = should > happen in short order. >=20 > -- Jeff >=20 --Apple-Mail=_5A4A30B7-77DA-4A52-AE95-0656B27CB0FF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSwXuZAAoJEPcO+I7eiUJZA7wQALIk42Lb3keSLlrT6sCeKfQj k3xfmmiyZ1/Fxtqn5l8Z/Jnp1OAdE/aNGCiXazQE6iFrGVCF6jTOpOX2uJOPb04y OAzVeZsF5ilvPsaFhWeD+5P+Hv3i9Qfczn3bWo5CexqUoygSEENb1lEnSULtu02m 1iJau1APKt/gwuD4FfHvlqTNmUcakrglqnt/mh9i8C5v7x52HDGQHZZJVR/Y7FqX 8OS3RRbpS4i4s0jqWebACfyvxD/aO34D8863N51Pz+fwN6odlHWI0ultFtN+C7+l cmeeLmLOkhytCCmIS97pGnYKTPLMO5JmVUg5B7Hj/yP9KM+zWDYxaEHm38+z7tWv NlFT+MTBNADyRpmEN8Rh8CwvqC2cNNs99r+jYVXW/22gfvpj2x+ce6a/64muttcC NlOfWqyKV/H29OrW+mmml5KWSyTON/d4PSnWh1YYmH2cF7xluTxo2nmFyGgAQhuw oRY/tTc/dLKST/HrB7BTr8Mk2s2H3+QkatxxtPmu+T5dycSwCXfMxmTeqaGE0Nwr ++M0IIgrLyzme189U1UAqD6gQym9d78o7CXuDS0X6FlP0YR65/hWjZcQQqOxdsE0 vTUGhzQCch5QZ8id4Le1FdtEdbiIFY7490zIM/A7urBSJqQwGKU+DjCUIzHmzA2i yDZl6yJTwJ36/7zg1Lli =bKZ7 -----END PGP SIGNATURE----- --Apple-Mail=_5A4A30B7-77DA-4A52-AE95-0656B27CB0FF-- From adrian@olddog.co.uk Mon Dec 30 06:55:42 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AE11AE0DA for ; Mon, 30 Dec 2013 06:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3iAZFijMWyq for ; Mon, 30 Dec 2013 06:55:41 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 31E6E1ADFA6 for ; Mon, 30 Dec 2013 06:55:41 -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 rBUEtXDv001592; Mon, 30 Dec 2013 14:55:33 GMT Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rBUEtVfP001569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Dec 2013 14:55:32 GMT From: "Adrian Farrel" To: "'Thomas D. Nadeau'" , "Jeff Haas" Subject: RE: AD review of draft-ietf-bfd-tc-mib Date: Mon, 30 Dec 2013 14:55:38 -0000 Message-ID: <077e01cf056f$34bcc950$9e365bf0$@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: Ac8Fby67hwG5nIQmSeqSiHpBfigAnA== Content-Language: en-gb Cc: rtg-bfd@ietf.org, draft-ietf-bfd-tc-mib.all@tools.ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 14:55:42 -0000 Hi Tom, See other email saying put them both in the same document, but note that IANA MIB modules are not extracted from RFCs by tools. The definitive copies of IANA MIB modules live on the IANA web pages (that's the whole point!). A > From: Thomas Nadeau > Sent: 30 December 2013 13:56:40 (UTC) Dublin, Edinburgh, Lisbon, London > To: Jeffrey Haas > Cc: Farrel Adrian; rtg-bfd@ietf.org; draft-ietf-bfd-tc-mib.all@tools.ietf.org > Subject: Re: AD review of draft-ietf-bfd-tc-mib > > On Dec 29, 2013:4:13 PM, at 4:13 PM, Jeffrey Haas wrote: > > > Adrian, > > > > A brief followup - I'm sure the authors will have comments of their own: > > > > On Sun, Dec 29, 2013 at 07:59:09PM -0000, Adrian Farrel wrote: > >> I think the Abstract should note that the TCs defined here are maintained > >> by IANA as this is an important feature. > >> > >> BUT... > >> > >> I don't see why all of these TCs are in an IANA module. It seems that a > >> number of them would not be updated by IANA upon the allocation of new > >> protocol code points. I believe the following should be moved to their > >> own module and out of the IANA module... > >> > >> IANAbfdSessIndexTC > >> IANAbfdIntervalTC > >> IANAbfdMultiplierTC > >> IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit > >> enumerations) > >> IANAbfdCtrlSourcePortNumberTC > >> > >> I am suspicious of some of the other TCs as well. Really, an IANA > >> module should be used for TCs that mirror registries. Do the other > >> TCs actually mirror registries? If so you should say which. If not, > >> then you should probably move them out of the IANA module as well. > > > > Since this happened as part of last minute review, it's no surprise that > > this wasn't quite done correctly. > > > > Is your preference to have a separate draft for this separation or could > > both TC MIBs occur in the same document? > > While its been done both ways, I hope it would be sufficient at this point to > have a separate module within the same draft. The biggest issue with that > approach is making sure the ordering is done such that automated tools that > extract the MIBs from the draft/RFC document have things ordered properly so > as to just work. > > --Tom > > > > > > I suspect once this detail is settled, the remainder of your changes should > > happen in short order. > > > > -- Jeff > > From tnadeau@lucidvision.com Mon Dec 30 09:23:10 2013 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C37E1AE2A1 for ; Mon, 30 Dec 2013 09:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmpJd6NwLdid for ; Mon, 30 Dec 2013 09:23:08 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 925951AE227 for ; Mon, 30 Dec 2013 09:23:08 -0800 (PST) Received: from [10.78.188.188] (mobile-198-228-204-195.mycingular.net [198.228.204.195]) by lucidvision.com (Postfix) with ESMTP id 7D4B7269C322; Mon, 30 Dec 2013 12:23:02 -0500 (EST) References: <077e01cf056f$34bcc950$9e365bf0$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <077e01cf056f$34bcc950$9e365bf0$@olddog.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11B554a) From: "Thomas D. Nadeau" Subject: Re: AD review of draft-ietf-bfd-tc-mib Date: Mon, 30 Dec 2013 12:22:55 -0500 To: "" Cc: "" , "" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 17:23:10 -0000 cool. just working my way down the backlog of emails... thx Tom=20 > On Dec 30, 2013, at 9:55 AM, "Adrian Farrel" wrote: >=20 > Hi Tom, >=20 > See other email saying put them both in the same document, but note that I= ANA > MIB modules are not extracted from RFCs by tools. The definitive copies of= IANA > MIB modules live on the IANA web pages (that's the whole point!). >=20 > A >=20 >> From: Thomas Nadeau >> Sent: 30 December 2013 13:56:40 (UTC) Dublin, Edinburgh, Lisbon, London >> To: Jeffrey Haas >> Cc: Farrel Adrian; rtg-bfd@ietf.org; draft-ietf-bfd-tc-mib.all@tools.ietf= .org >> Subject: Re: AD review of draft-ietf-bfd-tc-mib >>=20 >>> On Dec 29, 2013:4:13 PM, at 4:13 PM, Jeffrey Haas wrote= : >>>=20 >>> Adrian, >>>=20 >>> A brief followup - I'm sure the authors will have comments of their own:= >>>=20 >>> On Sun, Dec 29, 2013 at 07:59:09PM -0000, Adrian Farrel wrote: >>>> I think the Abstract should note that the TCs defined here are maintain= ed >>>> by IANA as this is an important feature. >>>>=20 >>>> BUT... >>>>=20 >>>> I don't see why all of these TCs are in an IANA module. It seems that a= >>>> number of them would not be updated by IANA upon the allocation of new >>>> protocol code points. I believe the following should be moved to their >>>> own module and out of the IANA module... >>>>=20 >>>> IANAbfdSessIndexTC >>>> IANAbfdIntervalTC >>>> IANAbfdMultiplierTC >>>> IANAbfdCtrlDestPortNumberTC (unless you propose to define explicit >>>> enumerations) >>>> IANAbfdCtrlSourcePortNumberTC >>>>=20 >>>> I am suspicious of some of the other TCs as well. Really, an IANA >>>> module should be used for TCs that mirror registries. Do the other >>>> TCs actually mirror registries? If so you should say which. If not, >>>> then you should probably move them out of the IANA module as well. >>>=20 >>> Since this happened as part of last minute review, it's no surprise that= >>> this wasn't quite done correctly. >>>=20 >>> Is your preference to have a separate draft for this separation or could= >>> both TC MIBs occur in the same document? >>=20 >> While its been done both ways, I hope it would be sufficient at th= is > point to >> have a separate module within the same draft. The biggest issue with tha= t >> approach is making sure the ordering is done such that automated tools th= at >> extract the MIBs from the draft/RFC document have things ordered properly= so >> as to just work. >>=20 >> --Tom >>=20 >>=20 >>>=20 >>> I suspect once this detail is settled, the remainder of your changes sho= uld >>> happen in short order. >>>=20 >>> -- Jeff >=20 >=20 >=20