Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 03 October 2016 18:43 UTC
Return-Path: <zzhang@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1645A1294A2; Mon, 3 Oct 2016 11:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 9xmMg_T617cY; Mon, 3 Oct 2016 11:43:12 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783F912949F; Mon, 3 Oct 2016 11:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gzPFtNyrk8DGC61paCikGZ3/rvZsEEgwQw7VZSneQxE=; b=XyB2qQVIo1Cz8iuMNiIRrq2g4tB8R38R84nGMl4PXGAPjAj+9oB7vb715Z3Zyjkw6CepsC3AvFoOyfCmZm6uusYNdTNv9Ah60cS0aifh2OnHzEHzKJ9NtjOOn8Eu4OGqu+wO8gb2owWO8DgcEaBR/BTzYYmp9hx+HzlxElmLiyk=
Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3147.namprd05.prod.outlook.com (10.173.219.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.8; Mon, 3 Oct 2016 18:43:00 +0000
Received: from DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) by DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) with mapi id 15.01.0659.009; Mon, 3 Oct 2016 18:43:00 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Benoit Claise <bclaise@cisco.com>, Glenn Mansfield Keeni <glenn@cysols.com>, "EXT - thomas.morin@orange.com" <thomas.morin@orange.com>
Thread-Topic: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
Thread-Index: AQHRwKCAxDexyEwkMUuqurSvHMHV1KAc8kwAgGqQeYCAECYAgIAAIFEA
Date: Mon, 03 Oct 2016 18:42:59 +0000
Message-ID: <DM5PR05MB3145D1CD26FAFDCB6A66B9FDD4C20@DM5PR05MB3145.namprd05.prod.outlook.com>
References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <BLUPR0501MB17151A695785D4D8DD485633D4690@BLUPR0501MB1715.namprd05.prod.outlook.com> <b4249e61-0a11-2ce1-c846-67096858fa2c@cysols.com> <BLUPR0501MB1715A3B288A27A39E99203B8D4490@BLUPR0501MB1715.namprd05.prod.outlook.com> <c757a323-24a7-2696-657e-88f8e15e8a36@cysols.com> <f2d0c86e-5b2a-dbf9-e3a9-2bf66002f263@cysols.com> <93a5d459-3271-b7ad-fadc-156576c60b65@cysols.com> <37e5086d-ce25-6b14-56d9-b53d46f863e2@cisco.com>
In-Reply-To: <37e5086d-ce25-6b14-56d9-b53d46f863e2@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=zzhang@juniper.net;
x-originating-ip: [66.129.241.13]
x-ms-office365-filtering-correlation-id: 79d02c43-6ace-4ff6-21fc-08d3ebbd19a4
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3147; 6:nZKqYMHWUr7/GZjGCjVWiOC/tVQawm10ZWrsXKj5Xp0AieaoF/66CQtNvLQzYbwjoriiF+rhw9U/yGU2NX6HAcfdGFxd6iJjSVdsx8P84N+lhxjrzYcOnKe+1/aDOzZYfDa0MfsQc+YlmRVWs4DNBf4WTaZssoeOVzT/qn7UlTrOqIwAshALWMc2WE9tBG4jBYruUlFfAKX8aYj/v1t8sYKuuw8ovs5e7aTbIXdH2k2xG8ZKx0IufAbdBTIB7LfqAN7mxVpBR2sCxcWB3p6510jYJmxiYsoDF/3avzhz00lY7bMcZ62VDDiQSGa2KAfeDYAgNFXieKniOGJ8OXf8Ih6WQbjRmLhE3X78qGjjU88=; 5:0pd4n/9IGobzZ5Msq1UbymkuimniIW+rlC/8QIRrb/xFkB62t10Ju5NtpMAR+ZZRV/MQPr8a46gxkk6+IpIaB3tUFGxAvFcrXirbvceXj/spLI+wK/Dl5sEgQyQSF4Llw4tll0KEjBTcwJgApdMyIQ==; 24:ELJce4K7v1ly2o9gaJlykNxqGQplNaQcelZURun0RJ49UGBF48UOTHGQKaY+XT0tHA/PGguPHH55sULbx8/wW+/4u2EQlE3RiiRQaBoe4xM=; 7:oxLQASULZ8cRaHSf1WkmVDGSs25+BSc3JUnD2kKwloGmEbX98qgzuyXnUP1zooxtfedSGgGdxnkX/VvWUTeZaEHFWR/QXUzm4vy+rNiVpyAphXLpIENfCIGUTq9/23P2ABdQK3mvnbAefwKj0v3j1I1I9AwNlTkPxxZvXuJN0772JmMkxvhts34SPkedEWixHKtT3Z0foXXVFO0d7D5js0D/pNYTH6YL4GSEPfnHw/wYIb2lTXMCJpnzBgRHJHr0ojeGAUQnNCru3LQVU3t8H6v1NjTOo6kxH0SJiDKOEizYKUBiivzcaPrhqx69p/Xj
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR05MB3147;
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <DM5PR05MB314781B238870F5AAB369E1BD4C20@DM5PR05MB3147.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(120809045254105)(192374486261705)(138986009662008)(82608151540597)(788757137089)(95692535739014)(18271650672692)(50582790962513);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM5PR05MB3147; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3147;
x-forefront-prvs: 008421A8FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(51914003)(13464003)(129404003)(24454002)(230783001)(68736007)(74316002)(4326007)(122556002)(10400500002)(102836003)(5890100001)(77096005)(76576001)(33656002)(1720100001)(5660300001)(7736002)(7696004)(305945005)(2900100001)(3846002)(92566002)(6116002)(87936001)(586003)(2950100002)(7846002)(93886004)(15975445007)(81166006)(81156014)(11100500001)(8936002)(101416001)(97736004)(8676002)(5001770100001)(50986999)(76176999)(54356999)(19580405001)(19580395003)(86362001)(5002640100001)(2906002)(3660700001)(189998001)(99286002)(106116001)(106356001)(105586002)(66066001)(3280700002)(9686002)(21314002)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3147; H:DM5PR05MB3145.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2016 18:42:59.8613 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3147
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/RsIFeoPy7TkP566xeXR4TcSyunI>
Cc: Mach Chen <mach.chen@huawei.com>, "mib-doctors@ietf.org" <mib-doctors@ietf.org>, "draft-ietf-bess-l2l3-vpn-mcast-mib.all@ietf.org" <draft-ietf-bess-l2l3-vpn-mcast-mib.all@ietf.org>, "ops-ads@ietf.org" <ops-ads@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2016 18:43:19 -0000
Gelnn, Benoit, Sorry for the late action and response after the initial round of review and revision - I have been side tracked by many other things. I will try to get this done within next two weeks. Thanks. Jeffrey > -----Original Message----- > From: Benoit Claise [mailto:bclaise@cisco.com] > Sent: Monday, October 03, 2016 12:42 PM > To: Glenn Mansfield Keeni; Jeffrey (Zhaohui) Zhang; EXT - > thomas.morin@orange.com > Cc: mib-doctors@ietf.org; ops-ads@ietf.org; Mach Chen; Martin Vigoureux; > bess@ietf.org; draft-ietf-bess-l2l3-vpn-mcast-mib.all@ietf.org > Subject: Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib- > 04.txt > > Authors, > > Can you please finalize this draft. > Glenn provided the first MIB doctor review in April! > > Regards, Benoit > > Hi, > > Any update on the MIB drafts? > > Glenn > > > > On 2016/07/17 23:44, Glenn Mansfield Keeni wrote: > >> Jeffrey and team, > >> Any progress on the MIB matters > >> (draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt, > >> draft-ietf-bess-mvpn-mib-03.txt )? > >> > >> Glenn > >> On 2016/06/07 18:39, Glenn Mansfield Keeni wrote: > >>> Hi Jeffrey, > >>> Thanks for the good work on draft-ietf-bess-l2l3-vpn-mcast-mib > >>> document. It took me some time to do this review. But now here it > >>> is. A (near complete) review of > >>> draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt is attached. Hope this helps. > >>> I understand that the Security Considerations section is TBD. > >>> > >>> Glenn > >>> > >>> On 2016/05/19 4:48, Jeffrey (Zhaohui) Zhang wrote: > >>>> Hi Glenn, > >>>> > >>>>> -----Original Message----- > >>>>> From: Glenn Mansfield Keeni [mailto:glenn@cysols.com] > >>>>> Sent: Sunday, May 08, 2016 11:02 AM > >>>>> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Benoit Claise > >>>>> <bclaise@cisco.com>; EXT - thomas.morin@orange.com > >>>>> <thomas.morin@orange.com> > >>>>> Cc: Mach Chen <mach.chen@huawei.com>; ops-ads@ietf.org; Martin > >>>>> Vigoureux > >>>>> <martin.vigoureux@nokia.com>; bess@ietf.org; mib-doctors@ietf.org > >>>>> Subject: Re: [bess] MIBDoc review of > >>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- > >>>>> 02.txt > >>>>> > >>>>> Jeffrey, > >>>>> > Thanks for your comments. I've addressed most of your comments > >>>>> > in the new revision: > >>>>> Thanks for your cooperation. I will need at least one more revision > >>>>> with the following comments/recommendations addressed before I will > >>>>> be able to complete the detailed review. In the following the > numbers > >>>>> refer to the issue numbers in the initial review. The issues that > are > >>>>> addressed and closed are not listed. For brevity, the issue > >>>>> descriptions have been trimmed. In case of doubts please look at the > >>>>> response mail appended below. > >>>>> Hope this helps. > >>>> > >>>> Thanks for your detailed comments/suggestions. I posted a new > revision > >>>> with the following issues addressed. > >>>> > >>>> URL: > >>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast- > mib-04.txt > >>>> > >>>> > >>>> > >>>> Status: > >>>> https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3-vpn-mcast-mib/ > >>>> Htmlized: > >>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-04 > >>>> Diff: > >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib- > 04 > >>>> > >>>> > >>>> Please see some notes below. > >>>> > >>>>> > >>>>> Glenn > >>>>> > >>>>> ------------------------------------------------------------------- > >>>>> > >>>>> Comments: > >>>>> > >>>>> 1.1 > >>>>> > I had thought this would be standard/obvious for all MIB > >>>>> objects - > >>>>> We will comeback to this time and again, whereever possible make > >>>>> matters explicit and clear. That will help. > >>>>> > Is it enough to say something similar? For example: > >>>>> > In particular, it describes common managed objects used > >>>>> > to configure and/or monitor both L2 and L3 VPN Multicast. > >>>>> That is better. > >>>> > >>>> I take it that this is already closed in -03 revision. > >>>> > >>>>> > >>>>> 2.2 > >>>>> > Having said that, I'll explain PMSI a bit further. > >>>>> PMSI explanation is good. > >>>>> Please use the same style/format for I-PMSI and S-PMSI. > >>>> > >>>> I think -03 revision already use the same style/format for I-PMSI and > >>>> S-PMSI? > >>>> > >>>>> > >>>>> 2.3 > >>>>> > No difference. I was using "Layer 3" or "L3" but it was > >>>>> pointed out > >>>>> > that the layer 3 VPN is often referred to IP VPN in other RFCs > >>>>> and I > >>>>> > was advised to change it accordingly. Looks like I did not change > >>>>> all > >>>>> > the cases. > >>>>> > On the other hand, I noticed that RFC 4382 does use "Layer 3 > >>>>> VPN" so > >>>>> > I'll change it back. > >>>>> No problems. just make sure that the same expression/notation is > used > >>>>> uniformly. > >>>> > >>>> I take it that this is also addressed in -03 already. > >>>> > >>>>> 3. > >>>>> > > > 3. Summary of MIB Module. > >>>>> > > > An overview of the L2L3-VPN-MCAST-MIB will be good- the > >>>>> > > > structure of the MIB, short descriptions of the table(s) > >>>>> > > > including usage of the table(s) for management and/or by > >>>>> > > > other MIB(s). > >>>>> > > >>>>> > I had that, but have added one sentence about the only table. > >>>>> A sentence or two about the textual convention will be good. > >>>> > >>>> Added in -04. > >>>> > >>>>> > > > 4. MIB syntax checking: > >>>>> > > > smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB > >>>>> 2>L2L3-VPN-MCAST-MIB.txt > >>>>> > > >>>>> > I used simpleweb's validation tool but looks like I did not > >>>>> use the > >>>>> > strictest level of validation. I've now fixed the following > issues > >>>>> and > >>>>> > verified. > >>>>> Good. > >>>>> 5. > >>>>> > > > > >>>>> > > > 5. REFERENCE clauses: Please use REFERENCE clauses liberally. > >>>>> > > > Wherever possible, provide references for objects used in > >>>>> > > > the MIB. The references will point to specific sections/ > >>>>> > > > sub-sections of the RFCs defining the protocol for > >>>>> which the > >>>>> > > > MIB is being designed. It will greatly improve the > >>>>> readability > >>>>> > > > of the document. > >>>>> > > >>>>> > Added. > >>>>> I would recommend using the REFERENCE clause as in rfs4382 and > >>>>> improve on it. > >>>>> Specifically, instead of keeping the reference in the DESCRIPTION > >>>>> clause move it to a separate REFERENCE clause. The addition of the > >>>>> section number is an improvement. It is friendlier to the reader. > >>>>> Note. Same comment for other OBJECTs too. > >>>> > >>>> Oh I missed that. All fixed. > >>>> > >>>>> 7.1 > >>>>> > > > 7.1 CONTACT-INFO > >>>>> > > > Following the conventions (including indentation style) > >>>>> will > >>>>> > > > improve the readability. (e.g. RFC4382, RFC5132). > >>>>> > > > Will be good if it does not overflow into the next page. > >>>>> > > >>>>> > Fixed. > >>>>> The format is OK. The Postal address etc., need not have been > >>>>> deleted. Please put the complete contact information as in the > >>>>> Author's Address. (RFC 2578 section 5.7 gives a usage example). > >>>> > >>>> Fixed. > >>>> > >>>>> 7.3 > >>>>> > I kept "experimental 99" so that I could continue to use mib > >>>>> tools > >>>>> > to validate; but I added notes for the editor to replace them > >>>>> as you > >>>>> > indicated. > >>>>> Use of "experimental 99" is not recommended. > >>>> > >>>> Do you mean 99 is not a good number? What about 9999? As I explained, > >>>> I kept it so that we can use mib tools to validate, and I've added > >>>> detailed notes for the editor. > >>>> > >>>>> 8 > >>>>> > > > 8. Specific MO and TC related comments. > >>>>> > Are spaces allowed? I don't know so I used hyphen. For now I > >>>>> replace > >>>>> > with things like rsvpP2mp. > >>>>> Yes. Camelcase is an allowed practice. SMI does not mind it. > >>>> > >>>> Ok this is closed already then. > >>>> > >>>>> 8.2 > >>>>> > > > 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE > >>>>> > The intent is to simply return the octet value of the flags > >>>>> > field, w/o listing individual bits like "Leaf Information > >>>>> Required". > >>>>> > More bits could be defined in the future but the MIB would not > >>>>> change. > >>>>> > > >>>>> > Is that OK? > >>>>> As far as possible, the meaning of the objects must be made clear. > >>>>> That will help implementors and operators- users of the MIB. > >>>> > >>>> I added the definition for one existing bit and reference to the IANA > >>>> registry being created for this flag field. > >>>> > >>>>> > >>>>> 8.3 > >>>>> > > > 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE > >>>>> > Depending on the tunnel type, there could be different sizes. > >>>>> > Future tunnel types could have other sizes that not specified > >>>>> > today. I was thinking to just give a size > >>>>> > tPmsiTunnelAttributeId OBJECT-TYPE range so that it is flexible. > >>>>> > Is that ok? > >>>>> I see that you have changed the size upper limit to 50. > >>>>> If the size varies continuously from 0 to 50 the above description > >>>>> is correct. > >>>>> Please confirm, explain and cite appropriate reference. If the size > >>>>> may change in the future that must be stated too. > >>>> > >>>> I changed to discrete sizes for currently defined tunnel types. > >>>> > >>>>> > >>>>> 8.4 > >>>>> > > > 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE > >>>>> > > > SYNTAX RowPointer > >>>>> > > > MAX-ACCESS read-only > >>>>> > > > STATUS current > >>>>> > > > DESCRIPTION > >>>>> > > > "If the tunnel has a corresponding interface, > >>>>> > > > this is the row pointer to the ifName table." > >>>>> > > > o DESCRIPTION looks incorrect. Please fix it. Do you > >>>>> > > > want to say this object points to the corresponding > >>>>> > > > row in the ifTable? > >>>>> > > >>>>> > Yes. Fixed. > >>>>> Not quite. > >>>>> What is ifName table ? ifName is a columnar object in the > >>>>> ifXTable. > >>>>> Is l2L3VpnMcastPmsiTunnelIf a pointer to the corresponding row > in > >>>>> the > >>>>> ifXTable table ? Please fix accordingly. > >>>> > >>>> You're right. Fixed. > >>>> > >>>>> > >>>>> 9. > >>>>> > > > 9. The Security Considerations section does not follow > >>>>> > > > the Security Guidelines for IETF MIB Modules > >>>>> > > > http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. > >>>>> > > > Please fix. > >>>>> > > >>>>> > I was really hoping that it would not have to be that > >>>>> > tedious. SNMP/MIB secur > >>>>> ity should be no different from the > >>>>> > CLI security - once you secure the infrastructure > >>>>> > then what's more to do? > >>>>> > > >>>>> > I'll need more time to work on this. Let me try to address > >>>>> > the issues in the other mib first and come back to this. > >>>>> > >>>>> Please take your time. Looking at examples will help. And let me > >>>>> know where I can help. > >>>> > >>>> I will need to work on that later. > >>>> > >>>>> > >>>>> 10.1 > >>>>> > > > 10.1 Checking nits according to > >>>>> > > > http://www.ietf.org/id-info/checklist : > >>>>> > Should I break them into different lines or just keep them > >>>>> > as is? Any example of expected indentation if I break the > >>>>> > lines? > >>>>> No problems at all to break lines. > >>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER > >>>>> ::= {l2L3VpnMcastConformance 1} > >>>>> Should do. > >>>> > >>>> Done. > >>>> > >>>>> > >>>>> 10.2 > >>>>> > > > 10.2 Checking references for intended status: Proposed > >>>>> Standard > >>>>> > > > == Missing Reference: 'RFC 7117' is mentioned on line > >>>>> 76, > >>>>> > > > but not defined > >>>>> > > > 'described in [RFC6513, RFC6514, RFC 7117] and other > >>>>> > I hope I understood and fixed it (removing the space in "RFC > >>>>> 7117"). > >>>>> I would recommend that you put it as [RFC6513], [RFC6514], [RFC7117] > >>>>> That is simpler to parse. > >>>> > >>>> I see some other documents do not have comma between multiple > >>>> references so I followed that. > >>>> > >>>>> > >>>>> > > > 11. There is another WIP MVPN-MIB in > >>>>> > > > draft-ietf-bess-mvpn-mib-02.txt > >>>>> > > > MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. > >>>>> > > > Is there a good reason for not merging the 2 documents? > >>>>> > > > I have not seen any discussion or explanation on this. > >>>>> > > > I may have missed it. > >>>>> > > > Please clarify or, give some pointers. > >>>>> > > >>>>> > As mentioned in the introduction: > >>>>> > > >>>>> > this memo describes managed objects common to both VPLS > >>>>> > Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. > >>>>> > MVPN-MIB is for MVPN. There was another VPLS Multicast MIB > >>>>> > in the work and both would reference common > >>>>> > >>>>> > objects defined in this MIB. > >>>>> > >>>>> OK. So you are saying that this MIB contains core objects that > >>>>> will be used to manage implementations of various multicast VPN > >>>>> protocols e.g. [RFC7117], [RFC6513],[RFC6514] ? It will help if > >>>>> you spell it out at the beginning. > >>>> > >>>> Yes. I thought I did it already: > >>>> > >>>> 1. Introduction > >>>> > >>>> ... and this memo describes managed objects common to both VPLS > >>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. > >>>> > >>>> Thanks! > >>>> Jeffrey > >>>> > >>>>> > >>>>> -------------------------------------------------------------------- > -- > >>>>> > >>>>> On 2016/04/16 21:47, Jeffrey (Zhaohui) Zhang wrote: > >>>>>> Glenn, > >>>>>> > >>>>>> Thanks for your comments. I've addressed most of your comments in > >>>>>> the > >>>>> new revision: > >>>>>> > >>>>>> URL: https://www.ietf.org/internet-drafts/draft-ietf-bess- > >>>>> l2l3-vpn-mcast-mib-03.txt > >>>>>> Status: https://datatracker.ietf.org/doc/draft-ietf-bess-l2l3- > >>>>> vpn-mcast-mib/ > >>>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn- > >>>>> mcast-mib-03 > >>>>>> Diff: > >>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3- > >>>>> vpn-mcast-mib-03 > >>>>>> > >>>>>> Please see below. > >>>>>> > >>>>>>> 1. Abstract: > >>>>>>> 1.1 A sentence on how the managed objects will be used by > >>>>>>> applications for operations, monitoring and management > >>>>>>> would be good. > >>>>>> > >>>>>> I had thought this would be standard/obvious for all MIB objects > >>>>>> - the > >>>>> read-write ones are used to control how a device works, and the > >>>>> read-only > >>>>> ones are used for monitoring. Do I really need to say it explicitly? > >>>>>> > >>>>>> I see RFC 4382 has the following: > >>>>>> > >>>>>> This memo defines a portion of the Management Information Base > >>>>>> (MIB) > >>>>>> for use with network management protocols in the Internet > >>>>>> community. > >>>>>> In particular, it describes managed objects to configure and/or > >>>>>> monitor Multiprotocol Label Switching Layer-3 Virtual Private > >>>>>> Networks on a Multiprotocol Label Switching (MPLS) Label > >>>>>> Switching > >>>>>> Router (LSR) supporting this feature. > >>>>>> > >>>>>> Is it enough to say something similar? For example: > >>>>>> > >>>>>> In particular, it describes common managed objects used to > >>>>> configure > >>>>>> and/or monitor both L2 and L3 VPN Multicast. > >>>>>> > >>>>>>> > >>>>>>> 2. Introduction > >>>>>>> 2.1 Please give the full expansion of the abbreviations > >>>>>>> appearing for the first time. (PE, VPLS,..) > >>>>>> > >>>>>> Fixed. > >>>>>> > >>>>>>> > >>>>>>> 2.2 The terminology section is a bit terse. Explaining the > >>>>>>> terms that are used, nicely with reference to the protocol > >>>>>>> documents will improve readability. > >>>>>>> e.g. > >>>>>>> - PMSI, I-PMSI, S-PMSI, provider tunnels > >>>>>> > >>>>>> As the paragraph alluded to, this MIB needs to be understood in the > >>>>> general context of L2/L3 multicast VPN and providing good > >>>>> explanation of > >>>>> the terms is not attempted. The references for the terms are the the > >>>>> RFCs > >>>>> for the relevant technologies. > >>>>>> > >>>>>> Having said that, I'll explain PMSI a bit further. > >>>>>> > >>>>>>> 2.3 Is there a difference between > >>>>>>> "multicast in Layer 2 and Layer 3 VPNs , defined by > >>>>>>> RFC 7117 and RFC 6513/6514" > >>>>>>> used in the DESCRIPTION in the MODULE-IDENTITY > >>>>>>> and > >>>>>>> "multicast in BGP/MPLS L2 or IP VPN" > >>>>>>> used in the DESCRIPTION of L2L3VpnMcastProviderTunnelType ? > >>>>>>> If these are the same, it will be helpful to stick to the > >>>>>>> same expression. If these are not the same, the dictinction > >>>>>>> should be clarified. > >>>>>> > >>>>>> No difference. I was using "Layer 3" or "L3" but it was pointed out > >>>>>> that > >>>>> the layer 3 VPN is often referred to IP VPN in other RFCs and I was > >>>>> advised to change it accordingly. Looks like I did not change all > the > >>>>> cases. > >>>>>> > >>>>>> On the other hand, I noticed that RFC 4382 does use "Layer 3 VPN" > so > >>>>> I'll change it back. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 3. Summary of MIB Module. > >>>>>>> An overview of the L2L3-VPN-MCAST-MIB will be good- the > >>>>>>> structure of the MIB, short descriptions of the table(s) > >>>>>>> including usage of the table(s) for management and/or by > >>>>>>> other MIB(s). > >>>>>> > >>>>>> I had that, but have added one sentence about the only table. > >>>>>> > >>>>>>> > >>>>>>> MIB definitions: > >>>>>>> 4. MIB syntax checking: > >>>>>>> smilint -s -e -l 5 mibs/L2L3-VPN-MCAST-MIB > >>>>>>> 2>L2L3-VPN-MCAST-MIB.txt > >>>>>> > >>>>>> I used simpleweb's validation tool but looks like I did not use the > >>>>> strictest level of validation. I've now fixed the following issues > >>>>> and > >>>>> verified. > >>>>>> > >>>>>>> > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:63: [4] {hyphen-in-label} warning: > named > >>>>> number `rsvp-p2mp' must not include a hyphen in SMIv2 > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:64: [4] {hyphen-in-label} warning: > named > >>>>> number `ldp-p2mp' must not include a hyphen in SMIv2 > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:65: [4] {hyphen-in-label} warning: > named > >>>>> number `pim-asm' must not include a hyphen in SMIv2 > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:66: [4] {hyphen-in-label} warning: > named > >>>>> number `pim-ssm' must not include a hyphen in SMIv2 > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:67: [4] {hyphen-in-label} warning: > named > >>>>> number `pim-bidir' must not include a hyphen in SMIv2 > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:68: [4] {hyphen-in-label} warning: > named > >>>>> number `ingress-replication' must not include a hyphen in SMIv2 > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:69: [4] {hyphen-in-label} warning: > named > >>>>> number `ldp-mp2mp' must not include a hyphen in SMIv2 > >>>>>> > >>>>>> See later question/comments below. > >>>>>> > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:215: [5] {group-unref} warning: current > >>>>> group `l2L3VpnMcastOptionalGroup' is not referenced in this module > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:4: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:5: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `Unsigned32' imported from module `SNMPv2-SMI' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:8: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never > used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `TruthValue' imported from module `SNMPv2-TC' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:11: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `RowStatus' imported from module `SNMPv2-TC' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `TimeStamp' imported from module `SNMPv2-TC' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:12: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `TimeInterval' imported from module `SNMPv2-TC' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:15: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `SnmpAdminString' imported from module `SNMP-FRAMEWORK-MIB' is never > >>>>> used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `InetAddress' imported from module `INET-ADDRESS-MIB' is never used > >>>>>>> mibs/L2L3-VPN-MCAST-MIB:18: [5] {import-unused} warning: > >>>>>>> identifier > >>>>> `InetAddressType' imported from module `INET-ADDRESS-MIB' is never > >>>>> used > >>>>>> > >>>>>> Removed the above unused imports. > >>>>>> > >>>>>>> > >>>>>>> 5. REFERENCE clauses: Please use REFERENCE clauses liberally. > >>>>>>> Wherever possible, provide references for objects used in > >>>>>>> the MIB. The references will point to specific sections/ > >>>>>>> sub-sections of the RFCs defining the protocol for which the > >>>>>>> MIB is being designed. It will greatly improve the readability > >>>>>>> of the document. > >>>>>> > >>>>>> Added. > >>>>>> > >>>>>>> > >>>>>>> 6. IMPORTS clause > >>>>>>> MIB modules from which items are imported must be cited and > >>>>>>> included in the normative references. > >>>>>>> The conventional style is > >>>>>>> mplsStdMIB > >>>>>>> FROM MPLS-TC-STD-MIB -- [RFC3811] > >>>>>> > >>>>>> Added. > >>>>>> > >>>>>>> > >>>>>>> 7. Please update the MODULE-IDENTITY. (There are no syntantic > >>>>>>> errors.) > >>>>>>> 7.1 CONTACT-INFO > >>>>>>> Following the conventions (including indentation style) will > >>>>>>> improve the readability. (e.g. RFC4382, RFC5132). > >>>>>>> Will be good if it does not overflow into the next page. > >>>>>> > >>>>>> Fixed. > >>>>>> > >>>>>>> > >>>>>>> 7.2 REVISION clause: follow the convention recommended in RFC4181 > >>>>>>> sec 4.5 > >>>>>>> REVISION "200212132358Z" -- December 13, 2002 > >>>>>>> DESCRIPTION "Initial version, published as RFC yyyy." > >>>>>>> -- RFC Ed.: replace yyyy with actual RFC number & remove this > >>>>>>> note: > >>>>>> > >>>>>> Fixed. > >>>>>> > >>>>>>> 7.3 OID assignment: follow the convention recommended in RFC4181 > >>>>>>> sec 4.5 i > >>>>>>> replace > >>>>>>> ::= { experimental 99 } -- number to be assigned > >>>>>>> by > >>>>>>> ::= { <subtree> XXX } > >>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this > >>>>>>> note > >>>>>>> <subtree> will be the subtree under which the module will be > >>>>>>> registered. > >>>>>>> > >>>>>> > >>>>>> I kept "experimental 99" so that I could continue to use mib > >>>>>> tools to > >>>>> validate; but I added notes for the editor to replace them as you > >>>>> indicated. > >>>>>> > >>>>>>> > >>>>>>> 8. Specific MO and TC related comments. > >>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION > >>>>>>> STATUS current > >>>>>>> DESCRIPTION > >>>>>>> "Types of provider tunnels used for multicast in > >>>>>>> BGP/MPLS L2 or IP VPN." > >>>>>>> SYNTAX INTEGER { unconfigured (0), > >>>>>>> rsvp-p2mp (1), > >>>>>>> ldp-p2mp (2), > >>>>>>> pim-asm (3), > >>>>>>> pim-ssm (4), > >>>>>>> pim-bidir (5), > >>>>>>> ingress-replication (6), > >>>>>>> ldp-mp2mp (7) > >>>>>>> > >>>>>>> o Would be nice to align the enumeration labels with the > >>>>>>> labels in the protocol document RFC 6514 unless there is > >>>>>>> a good reason for not doing so. (You will have to take > >>>>>>> care of the smi compilation errors too; '-' is not allowed ). > >>>>>> > >>>>>> Are spaces allowed? I don't know so I used hyphen. For now I > replace > >>>>> with things like rsvpP2mp. > >>>>>> Or could/should I just remove the definitions, so that if a new > >>>>>> type is > >>>>> defined in the future there is no need to update the MIB? > >>>>>> > >>>>>>> > >>>>>>> 8.1 l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE > >>>>>>> SYNTAX L2L3VpnMcastPmsiTunnelAttributeEntry > >>>>>>> MAX-ACCESS not-accessible > >>>>>>> STATUS current > >>>>>>> DESCRIPTION > >>>>>>> "An entry in this table corresponds to an PMSI > >>>>>>> attribute > >>>>>>> that is advertised/received on this router. > >>>>>>> For BGP-based signaling (for I-PMSI via > >>>>>>> auto-discovery > >>>>>>> procedure, or for S-PMSI via S-PMSI A-D routes), > >>>>>>> they are just as signaled by BGP (RFC 6514 section 5, > >>>>>>> 'PMSI Tunnel attribute'). > >>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, > >>>>>>> they're derived from S-PMSI Join Message > >>>>>>> (RFC 6513 section 7.4.2, 'UDP-based Protocol').. > >>>>>>> > >>>>>>> Note that BGP-based signaling may be used for > >>>>>>> PIM-MVPN as well." > >>>>>>> o Fix the ".." in "'UDP-based Protocol').." above. > >>>>>>> o Please give the reference for this Table. > >>>>>>> Is it- "PMSI Tunnel attribute" in RFC 6513 Sec.4 ? > >>>>>>> "PMSI Tunnel attribute" in RFC 6514 Sec.5 ? > >>>>>>> both? > >>>>>>> Any other pointers? > >>>>>> > >>>>>> Fixed. > >>>>>> > >>>>>>> > >>>>>>> 8.2 l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE > >>>>>>> SYNTAX OCTET STRING (SIZE (1)) > >>>>>>> MAX-ACCESS not-accessible > >>>>>>> STATUS current > >>>>>>> DESCRIPTION > >>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this > >>>>>>> is 0. > >>>>>>> For BGP-based I/S-PMSI signaling, this is the Flags > >>>>>>> field in PMSI Tunnel Attribute of the corresponding > >>>>>>> I/S-PMSI A-D route." > >>>>>>> ::= { l2L3VpnMcastPmsiTunnelAttributeEntry 1 } > >>>>>>> o Please confirm that the above is a complete enumeration > >>>>>>> of the > >>>>>>> types of signalling. > >>>>>>> o RFC 6514 Sec.5 says that the Flags field indicates > >>>>>>> "Leaf Information Required". That is useful information. > >>>>>>> Please include in the description. > >>>>>> > >>>>>> The intent is to simply return the octet value of the flags > >>>>>> field, w/o > >>>>> listing individual bits like "Leaf Information Required". More bits > >>>>> could > >>>>> be defined in the future but the MIB would not change. > >>>>>> > >>>>>> Is that OK? > >>>>>> > >>>>>>> > >>>>>>> 8.3 l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE > >>>>>>> SYNTAX OCTET STRING ( SIZE (0..37) ) > >>>>>>> MAX-ACCESS not-accessible > >>>>>>> STATUS current > >>>>>>> DESCRIPTION > >>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, the > >>>>>>> first > >>>>>>> four or sixteen octets of this attribute are filled > >>>>>>> with > >>>>>>> the provider tunnel group address (IPv4 or IPv6).. > >>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel > >>>>> Identifier > >>>>>>> Field in PMSI Tunnel Attribute of the corresponding > >>>>>>> I/S- > >>>>> PMSI > >>>>>>> A-D route." > >>>>>>> o Check the size specifications. The specs above say it can be > >>>>>>> all sizes 0..37. That is not clear from the DESCRIPTION > >>>>>>> clause. > >>>>>>> o Fix the ".." in "(IPv4 or IPv6).." above. > >>>>>>> o RFC 6514 Sec 5. PMSI Tunnel Attribute gives the Tunnel > >>>>> Identifiers > >>>>>>> for mLDP, PIM-SM, PIM-SSM, BIDIR-PIM,Ingress > >>>>>>> Replication,MP2MP. > >>>>>>> It appears that the sizes (range) for each case will be > >>>>>>> different. > >>>>>>> Please clarify that, and if there are discrete sizes, > specify > >>>>>>> accordingly. > >>>>>> > >>>>>> Depending on the tunnel type, there could be different sizes. > Future > >>>>> tunnel types could have other sizes that not specified today. I was > >>>>> thinking to just give a size range so that it is flexible. Is that > >>>>> ok? > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 8.3 l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE > >>>>>>> SYNTAX RowPointer > >>>>>>> MAX-ACCESS read-only > >>>>>>> STATUS current > >>>>>>> DESCRIPTION > >>>>>>> "If the tunnel exists in some MIB table, this is the > >>>>>>> row pointer to it." > >>>>>>> o "some MIB table" : specify which MIB table. > >>>>>> > >>>>>> I can give an example, like mplsTunnelTable [RFC 3812]. It could be > >>>>> whatever table that a tunnel may be put into. > >>>>>> > >>>>>>> o In what case will the tunnel exist and in what case will it > >>>>>>> not? > >>>>>> > >>>>>> If a device supports mplsTunnelTable and the tunnel is represented > >>>>>> there, > >>>>> then it exists. > >>>>>> > >>>>>>> o What will be the behaviour if the above condition is not > >>>>> satisfied? > >>>>>> > >>>>>> A null pointer should be given. > >>>>>> > >>>>>>> > >>>>>>> 8.4 l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE > >>>>>>> SYNTAX RowPointer > >>>>>>> MAX-ACCESS read-only > >>>>>>> STATUS current > >>>>>>> DESCRIPTION > >>>>>>> "If the tunnel has a corresponding interface, this > >>>>>>> is the > >>>>>>> row pointer to the ifName table." > >>>>>>> o DESCRIPTION looks incorrect. Please fix it. Do you want > >>>>>>> to say > >>>>>>> this object points to the corresponding row in the ifTable? > >>>>>> > >>>>>> Yes. Fixed. > >>>>>> > >>>>>>> o In what case does the TunnelIf exist and in what case > >>>>>>> will it > >>>>> not? > >>>>>> > >>>>>> Some tunnels may not have a corresponding interface. > >>>>>> > >>>>>>> o What will be expected if the tunnel does not have a > >>>>> corresponding > >>>>>>> interface? > >>>>>> > >>>>>> Null row pointer. > >>>>>> > >>>>>>> > >>>>>>> 9. The Security Considerations section does not follow the > Security > >>>>>>> Guidelines for IETF MIB Modules > >>>>>>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security. > >>>>>>> Please fix. > >>>>>> > >>>>>> I was really hoping that it would not have to be that tedious. > >>>>>> SNMP/MIB > >>>>> security should be no different from the CLI security - once you > >>>>> secure > >>>>> the infrastructure then what's more to do? > >>>>>> > >>>>>> I'll need more time to work on this. Let me try to address the > >>>>>> issues in > >>>>> the other mib first and come back to this. > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 10.ID-nits > >>>>>>> 10.1 Checking nits according to > >>>>>>> http://www.ietf.org/id-info/checklist : > >>>>>>> > >>>>>>> ------------------------------------------------------------------ > >>>>> --------- > >>>>>>> > >>>>>>> ** There are 4 instances of too long lines in the document, > >>>>>>> the > >>>>> longest one > >>>>>>> being 3 characters in excess of 72. > >>>>>> > >>>>>> I fixed some but there still three too long lines: > >>>>>> > >>>>>> l2L3VpnMcastPmsiTunnelAttributeType > >>>>>> L2L3VpnMcastProviderTunnelType, > >>>>>> > >>>>>> l2L3VpnMcastGroups OBJECT IDENTIFIER ::= > >>>>>> {l2L3VpnMcastConformance > >>>>> 1} > >>>>>> l2L3VpnMcastCompliances OBJECT IDENTIFIER ::= > >>>>>> {l2L3VpnMcastConformance > >>>>> 2} > >>>>>> > >>>>>> Should I break them into different lines or just keep them as is? > >>>>>> Any > >>>>> example of expected indentation if I break the lines? > >>>>>> > >>>>>>> > >>>>>>> 10.2 Checking references for intended status: Proposed Standard > >>>>>>> > >>>>>>> ------------------------------------------------------------------ > >>>>> --------- > >>>>>>> > >>>>>>> == Missing Reference: 'RFC 7117' is mentioned on line 76, but > >>>>>>> not > >>>>>>> defined > >>>>>>> 'described in [RFC6513, RFC6514, RFC 7117] and other > >>>>>>> documents > >>>>> tha...' > >>>>>> > >>>>>> I hope I understood and fixed it (removing the space in "RFC 7117"). > >>>>>> > >>>>>>> > >>>>>>> 11. There is another WIP MVPN-MIB in > >>>>>>> draft-ietf-bess-mvpn-mib-02.txt > >>>>>>> MVPN-MIB has objects that refer to L2L3-VPN-MCAST-MIB. > >>>>>>> Is there a good reason for not merging the 2 documents? I > have > >>>>>>> not > >>>>> seen > >>>>>>> any discussion or explanation on this. I may have missed it. > >>>>> Please > >>>>>>> clarify or, give some pointers. > >>>>>> > >>>>>> As mentioned in the introduction: > >>>>>> > >>>>>> this memo describes managed objects common to both VPLS > >>>>>> Multicast [RFC7117] and MVPN [RFC6513, RFC6514]. > >>>>>> > >>>>>> MVPN-MIB is for MVPN. There was another VPLS Multicast MIB in the > >>>>>> work > >>>>> and both would reference common objects defined in this MIB. > >>>>>> > >>>>>> Thanks! > >>>>>> Jeffrey > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Glenn > >>>>>>> Mansfield > >>>>>>> Keeni > >>>>>>> Sent: Tuesday, April 12, 2016 2:28 AM > >>>>>>> To: Benoit Claise <bclaise@cisco.com>; EXT - > >>>>>>> thomas.morin@orange.com > >>>>>>> <thomas.morin@orange.com> > >>>>>>> Cc: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; ops-ads@ietf.org; > >>>>> Martin > >>>>>>> Vigoureux <martin.vigoureux@nokia.com>; bess@ietf.org; Mach Chen > >>>>>>> <mach.chen@huawei.com> > >>>>>>> Subject: [bess] MIBDoc review of > >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib- > >>>>> 02.txt > >>>>>>> > >>>>>>> Hi, > >>>>>>> I have been asked to do a MIB Doctors review of > >>>>>>> draft-ietf-bess-l2l3-vpn-mcast-mib-02.txt. > >>>>>>> My knowledge of L2L3VPN Multicast is limited to the reading > >>>>>>> of this document and browsing through the documents referred > >>>>>>> to in the draft and bess-wg mailing list archives.( read > >>>>>>> "shallow"). > >>>>>>> So some of the doubts and questions may sound trivial or > >>>>>>> strange. Please bear with me and help me help you make > >>>>>>> this into a better document :-) > >>>>>>> > >>>>>>> The comments are attached. > >>>>>>> > >>>>>>> Glenn > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> BESS mailing list > >>>>>> BESS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/bess > >>>>>> > >>>> > >>>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> MIB-DOCTORS mailing list > >>> MIB-DOCTORS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mib-doctors > >>> > >> > >> _______________________________________________ > >> MIB-DOCTORS mailing list > >> MIB-DOCTORS@ietf.org > >> https://www.ietf.org/mailman/listinfo/mib-doctors > > > > . > >
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-… Glenn Mansfield Keeni
- [bess] MIBDoc review of draft-ietf-bess-mvpn-mib-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Jeffrey (Zhaohui) Zhang
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Jeffrey (Zhaohui) Zhang
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Mach Chen
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Jeffrey (Zhaohui) Zhang
- [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Benoit Claise
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Jeffrey (Zhaohui) Zhang
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… thomas.morin
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… thomas.morin
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Glenn Mansfield Keeni
- Re: [bess] MIBDoc review of draft-ietf-bess-mvpn-… Hiroshi Tsunoda
- Re: [bess] MIBDoc review of draft-ietf-bess-l2l3-… Glenn Mansfield Keeni