Re: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib
Dave Thaler <dthaler@microsoft.com> Tue, 01 December 2015 20:02 UTC
Return-Path: <dthaler@microsoft.com>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7EC1B2B53 for <mib-doctors@ietfa.amsl.com>; Tue, 1 Dec 2015 12:02:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.001
X-Spam-Level:
X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA3s46vt7YHZ for <mib-doctors@ietfa.amsl.com>; Tue, 1 Dec 2015 12:02:37 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310511B32CD for <mib-doctors@ietf.org>; Tue, 1 Dec 2015 12:02:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OcjBuBxAVerPjA1/NTgVc/WBF5n7b/U1qFmmJfUvnjU=; b=PZuVphFP73q2+6+2UPaM50zm9bOqYN3q+zhIRMTLhfHXMd9XleF9Yxd/Hw9RmVw2vhluKuUKeTxQzpH5trEto5Kcp2D06WyYF4gFN8bxeYg0WuwFOMxFOxWD2JDqRp1g2gkuS2rXNPKvxHTVqukNYRiPbZLUB/+kSzmMBmjPpDQ=
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.331.20; Tue, 1 Dec 2015 20:02:25 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0331.023; Tue, 1 Dec 2015 20:02:25 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Benoit Claise <bclaise@cisco.com>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Thread-Topic: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib
Thread-Index: AQHQCVF/0R4lMfEAdkKiNlaiobW0g5629rmAgAADHgCAAIz+AIAArPcAgACedEA=
Date: Tue, 01 Dec 2015 20:02:25 +0000
Message-ID: <BY2PR03MB41208817843908D1229D3C9A30F0@BY2PR03MB412.namprd03.prod.outlook.com>
References: <ade96465bb8f4eaf8474dbabc07a76e7@BY2PR03MB269.namprd03.prod.outlook.com> <54758CB5.6030506@cisco.com> <565C6CA7.9040408@cisco.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEAA057@AZ-FFEXMB04.global.avaya.com> <BY2PR03MB412480FE5FB1152629DDCD7A30F0@BY2PR03MB412.namprd03.prod.outlook.com> <565D76A2.3090908@cisco.com>
In-Reply-To: <565D76A2.3090908@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com;
x-originating-ip: [2001:4898:80e8::437]
x-microsoft-exchange-diagnostics: 1; BY2PR03MB412; 5:LEPM8SEMIFoGBHENg1Z0O/Cj/K1CM8I9wlv7CNzLknfrs722nX6T9rM5tLUUKpaeH4/61jnVTSMILAywjLdkFskX+xTFv7M/KRBHdOkVa5U1v7ZowzWCKxfJlPOQZ+cb4Ti9QrpymQ29C7k/SzcfXw==; 24:c5m/rDwGyLmjRT8BO5BMPGjzHl8n3uykpw8K/J22fivMZZIiACmhZhlvCRayXi8BPk0lpcJHX/tOKW5MdkMLaE716t7tbrIC2BgEfs2hofo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-microsoft-antispam-prvs: <BY2PR03MB412A327AAE62B15F4148F7EA30F0@BY2PR03MB412.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014)(189930954265078)(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412;
x-forefront-prvs: 07778E4001
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(243025005)(17383004)(16813002)(377454003)(189002)(3905003)(199003)(2950100001)(10400500002)(76576001)(790700001)(5005710100001)(93886004)(5002640100001)(106116001)(97736004)(86612001)(10290500002)(2900100001)(1096002)(5004730100002)(33656002)(77096005)(86362001)(5003600100002)(10090500001)(87936001)(105586002)(19617315012)(99286002)(15975445007)(19300405004)(8990500004)(74316001)(16236675004)(122556002)(40100003)(106356001)(19580395003)(19580405001)(586003)(6116002)(92566002)(54356999)(50986999)(189998001)(19625215002)(5008740100001)(76176999)(102836003)(81156007)(5001960100002)(11100500001)(5001770100001)(230783001)(1220700001)(101416001)(7059030)(21314002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB41208817843908D1229D3C9A30F0BY2PR03MB412namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2015 20:02:25.4428 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: <http://mailarchive.ietf.org/arch/msg/mib-doctors/VwzJf4DYn0_LNxPVOIWwU2Ok_yo>
Cc: "MIB Doctors (E-mail)" <mib-doctors@ietf.org>, Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Subject: Re: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2015 20:02:42 -0000
Another possibility is that we could define a subtree transmission.131.xxx to hold tunnel subtype values. E.g., if we define (say) xxx is 3, and a given tunnel subtype is yyy, then the subtree could be transmission.131.3.yyy. That might be a good way to organize tunneling protocol MIB modules and avoid having this discussion each time there’s a new tunnel subtype. Dave From: Benoit Claise [mailto:bclaise@cisco.com] Sent: Tuesday, December 1, 2015 2:30 AM To: Dave Thaler <dthaler@microsoft.com>; Romascanu, Dan (Dan) <dromasca@avaya.com> Cc: MIB Doctors (E-mail) <mib-doctors@ietf.org>; Spencer Dawkins <spencerdawkins.ietf@gmail.com> Subject: Re: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib Thanks Dave. Dan, do you agree? Shall we ask draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib to be moved under mib-2? Regards, Benoit Good point, and indeed in my MIB doctor review of -04, I see that I had annotated that proposed assignment with a “TODO: check this” I believe it was intended to be the case (per the original ifmib WG) that “transmission xxx” means “xxx” is an ifType value. Keith McCloghrie would be able to say for sure, but that’s my recollection. For tunnels (of which this is one), RFC 4087 uses “transmission 131” because the ifType is 131. It then defines tunnel subtypes as a separate numbering space, and does not specify where in the OID hierarchy tunnel subtype MIBs should go. From http://www.iana.org/assignments/ianaiftype-mib/ianaiftype-mib<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.iana.org%2fassignments%2fianaiftype-mib%2fianaiftype-mib&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Q9ajUpNPgbOhs8DkSlx3bUBv2ySL%2f3WlRSh7ndycN2k%3d> the current set of subtype values is: SYNTAX INTEGER { other(1), -- none of the following direct(2), -- no intermediate header gre(3), -- GRE encapsulation minimal(4), -- Minimal encapsulation l2tp(5), -- L2TP encapsulation pptp(6), -- PPTP encapsulation l2f(7), -- L2F encapsulation udp(8), -- UDP encapsulation atmp(9), -- ATMP encapsulation msdp(10), -- MSDP encapsulation sixToFour(11), -- 6to4 encapsulation sixOverFour(12), -- 6over4 encapsulation isatap(13), -- ISATAP encapsulation teredo(14), -- Teredo encapsulation ipHttps(15) -- IPHTTPS } Checking some other docs, since each subtype need not have its own MIB, only a few do: Protocol Subtype MIB OID MIB Reference L2TP l2tp(5) ::= { transmission 95 } [RFC3371] MSDP msdp(10) ::= { experimental 92 } [RFC4624] Note that IANA ifType for 95 is radsl(95), -- Rate-Adapt. Digital Subscriber Loop which is NOT L2TP, so the L2TP assignment is an anomaly. So I would say it should probably not go under transmission, since it is not asking for an ifType value. What RFC 4181 actually says is: - The value assigned to the MODULE-IDENTITY descriptor MUST be unique and (for IETF standards-track MIB modules) SHOULD reside under the mgmt subtree [RFC2578<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2578&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gUgpJhJ2NP5p8cvZcB7yOBT1ar6%2bdKtupKa1lbItCQA%3d>]. Most often it will be an IANA-assigned value directly under mib-2 [RFC2578<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2578&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gUgpJhJ2NP5p8cvZcB7yOBT1ar6%2bdKtupKa1lbItCQA%3d>], although for media-specific MIB modules that extend the IF-MIB [RFC2863<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2863&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZveZj0pM3fX7i5RJh0umoLyLn7rFVVIjWirotRe9%2fkA%3d>] it is customary to use an IANA-assigned value under transmission [RFC2578<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftools.ietf.org%2fhtml%2frfc2578&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=gUgpJhJ2NP5p8cvZcB7yOBT1ar6%2bdKtupKa1lbItCQA%3d>]. In the past, some IETF working groups have made their own assignments from subtrees delegated to them by IANA, but that practice has proven problematic and is NOT RECOMMENDED. The key phrase is “that extend the IF-MIB”. This MIB does not, it extends the IP Tunnel MIB. (The IP Tunnel MIB extends the IF-MIB and so the IF Tunnel MIB does use transmission.) So it would not be illegal to use transmission, since it is about transmission and does indirectly (via IP Tunnel MIB) extend IF-MIB, but not directly and does not need an ifType value. Dave From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Monday, November 30, 2015 7:46 AM To: Benoit Claise <bclaise@cisco.com><mailto:bclaise@cisco.com>; Dave Thaler <dthaler@microsoft.com><mailto:dthaler@microsoft.com> Cc: MIB Doctors (E-mail) <mib-doctors@ietf.org><mailto:mib-doctors@ietf.org>; Spencer Dawkins <spencerdawkins.ietf@gmail.com><mailto:spencerdawkins.ietf@gmail.com> Subject: RE: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib These two documents also came on my plate at the request of IANA. The reason for locating these under the transmission subtree is not clear. RFC 4181 requires to do this for media-specific MIB modules – is softwire considered ‘media-specific’ work? Regards, Dan From: MIB-DOCTORS [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Benoit Claise Sent: Monday, November 30, 2015 5:35 PM To: Dave Thaler Cc: MIB Doctors (E-mail); Spencer Dawkins Subject: [MIB-DOCTORS] On this week IESG telechat. : Early MIB doctor review of draft-ietf-softwire-mesh-mib-04 and draft-ietf-softwire-dslite-mib Hi Dave, Those two MIB modules are on the telechat this week, and I would like to get your green light. Please let us know. Regards, Benoit Hi Dave, We are now at version 7 and 6, respectively. Are you happy with the MIB modules now? And may I flag this one as done at http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-history<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftrac.tools.ietf.org%2farea%2fops%2ftrac%2fwiki%2fmib-doctors-review-history&data=01%7c01%7cdthaler%40microsoft.com%7c8c90b6eddef0413f302908d2fa3a5e1f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ZNY6Ix2dgaZpkb%2b4bZgaO6ED2nHF7baVEM%2byxwKa1fg%3d> Regards, Benoit Benoit asked me to do an early MIB doctor review of this document. My full comments are in the marked up copy at http://research.microsoft.com/~dthaler/draft-ietf-softwire-mesh-mib-04.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttp-3A__research.microsoft.com_-257Edthaler_draft-2Dietf-2Dsoftwire-2Dmesh-2Dmib-2D04.pdf%26d%3dBQMDaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3dEmyVUD_iyiDij_d-DdLNVFK2XWSeKZ1aF6FTt-D5224%26s%3dHo63Okm-fo9bjIZHdCzzwvZRa87Ac4z9r3_vn7Sy8-s%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c5c2e1408e814474cd23e08d2f99d7591%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6ttADpfOT8BqneSYvSroaDY4faoSF7SiQjpdX6aB2mE%3d> (there’s also a .docx version if you replace the .pdf extension with .docx) The doc is in a much better state than draft-ietf-softwire-dslite-mib is, and so this was fairly easy to review (and my thanks to the authors for that). Nevertheless, I did find a few issues, a short summary of which is: 1) It does not yet meet all the requirements for MIBs in RFC 4181, mostly around missing boilerplate 2) The security considerations section needs (per RFC 4181) a brief discussion of what objects, if any, might be considered sensitive. For example, one might argue the swmEncapsTable might reveal things about the internal network topology. 3) the smilint MIB checker reports several errors. I’ve noted in my comments how to fix them. (I used http://www.ibr.cs.tu-bs.de/bin/smitools.cgi<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttp-3A__www.ibr.cs.tu-2Dbs.de_bin_smitools.cgi%26d%3dBQMDaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA%26m%3dEmyVUD_iyiDij_d-DdLNVFK2XWSeKZ1aF6FTt-D5224%26s%3dvSO3FAc4-xOytETyJWMkVWpuGL92s1VT1LJllaK0tf0%26e%3d&data=01%7c01%7cdthaler%40microsoft.com%7c5c2e1408e814474cd23e08d2f99d7591%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=qixmtt%2bKMxCYecCaCiJDHq4ol2aivAxnInq%2fELTxuUk%3d>) -Dave
- [MIB-DOCTORS] FW: Early MIB doctor review of draf… Dave Thaler
- [MIB-DOCTORS] Fwd: Early MIB doctor review of dra… Benoit Claise
- [MIB-DOCTORS] On this week IESG telechat. : Early… Benoit Claise
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Romascanu, Dan (Dan)
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Dave Thaler
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Benoit Claise
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Romascanu, Dan (Dan)
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Dave Thaler
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Romascanu, Dan (Dan)
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Benoit Claise
- Re: [MIB-DOCTORS] On this week IESG telechat. : E… Dave Thaler