From nobody Fri Feb 10 18:20:38 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7512129529; Fri, 10 Feb 2017 18:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GvBHUvaqe9ck; Fri, 10 Feb 2017 18:20:29 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0C9128DF6; Fri, 10 Feb 2017 18:20:29 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id 65so41420117otq.2; Fri, 10 Feb 2017 18:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hRNIa6XNtozn8PM6+Xp9a+XjeT811/grI3f+QMf5lpw=; b=em8LiCz4/VfslLucRTDZdQXLURXN7qQXUK12BO/qhs99mGZUIFVbd61iIlarIQEexO W0kJETY+jiKIwTcz8XBpuMfTJoCXRUoRAsB6UMWq5/vE44b0HWRFq/d6n1GyCNmzSBr8 Ec06DwKAC6TU/q4R14WjMxWEs0/JgWF2ndtTZkMNHx+PRtvgPL8poyjtoeVa2aS4m7q3 tFWmh/TuDSUF6Zg3XCZbbIcklJkMmeoa6RWc4jlLdGGvoFFSMqENavlQ9MFYzH0ee8mI VYy4T3Omvn3Gx3NC+VHKpUSNiFBHU3Sqw8mLU30GwKRAM+EC07CXE2jHD0d7haGtoJke zAjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hRNIa6XNtozn8PM6+Xp9a+XjeT811/grI3f+QMf5lpw=; b=S4GWNNMt4Hnum1/Wg4ISf/3tDLQKJHetMFEBlp6gY188bRARu1iZDFd3s3IlONJWSp ymVaCEdtYNJeBm71hOsk8/VQ1W0OxsLYW4gpwPd3MMlYOEaQ/4zxzsq1wvNxSkdzd9CS x5ZSYZrKokhyFxeQDG+2+ycpdU/06lnZre4gcPET7vbKr3E8UOFKj59s4Gx+sHqhn3qE SbswBqvCnUZTU+n2otS3A+f5sOhb/HfZtTHguYJq9s0bykW7cOJ5RL3Do4OmiYOcROf+ u3uI/F9FCY4VC+zXPmYNhGIApfzIamqFKdBgGcCwAgnKTA1S7C7ulkLzFSi+pBbyw5k/ lF2Q== X-Gm-Message-State: AMke39nbaB8yRoa8WTWXHDJb8n5KoT5k5VUaEZbZPDxe9PUhyC/0tgu4cs9xW5ujNLmhu3dyNOzQYi2X66FRug== X-Received: by 10.157.52.33 with SMTP id v30mr6332284otb.156.1486779628817; Fri, 10 Feb 2017 18:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.28.16 with HTTP; Fri, 10 Feb 2017 18:20:28 -0800 (PST) From: Joan Cucchiara Date: Fri, 10 Feb 2017 21:20:28 -0500 Message-ID: To: Loa Andersson , mpls@ietf.org, mib-doctors@ietf.org, draft-ietf-mpls-mldp-mib@ietf.org Content-Type: multipart/alternative; boundary=001a114147c8a29544054837dbe0 Archived-At: Subject: [MIB-DOCTORS] MIB Dr. review of draft-ietf-mpls-mldp-mib-01 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2017 02:20:32 -0000 --001a114147c8a29544054837dbe0 Content-Type: text/plain; charset=UTF-8 Hello Authors, This draft has come a long way since the previous version. Thanks for that. Please make sure the MIB compiles with smilint prior to MIB review as it is difficult to review a MIB Module that doesn't compile. Also, please add compliance statements and conformance groups. Comments below. Thanks, -Joan output from smilint compiler: ------------------------------ While processing your request the following errors and/or warnings have been found: mibs/MPLS-MLDP-STD-MIB:76: [5] {date-year-2digits} warning: date specification `2016092600Z' contains a two-digit year representing `1920' mibs/MPLS-MLDP-STD-MIB:76: [2] {date-month} date specification `2016092600Z' contains an illegal month mibs/MPLS-MLDP-STD-MIB:76: [2] {date-hour} date specification `2016092600Z' contains an illegal hour mibs/MPLS-MLDP-STD-MIB:76: [4] {date-in-past} warning: date specification `2016092600Z' predates the SMI standard Then after that was fixed, more errors: mibs/MPLS-MLDP-STD-MIB:268: [2] {identifier-redefined} redefinition of identifier `mplsLdpPeerCapabilityEntry' mibs/MPLS-MLDP-STD-MIB:254: [6] {previous-definition} info: previous definition of `mplsLdpPeerCapabilityEntry' mibs/MPLS-MLDP-STD-MIB:268: [1] {internal-other} syntax error, unexpected COLON_COLON_EQUAL, expecting OBJECT mibs/MPLS-MLDP-STD-MIB:271: [5] {internal-flushing} warning: flushing recent incorrect declaration, see previous error(s) mibs/MPLS-MLDP-STD-MIB:279: [4] {hyphen-in-label} warning: named bit `upstream-label-assignment' must not include a hyphen in SMIv2 mibs/MPLS-MLDP-STD-MIB:283: [4] {hyphen-in-label} warning: named bit `prot-lsr' must not include a hyphen in SMIv2 mibs/MPLS-MLDP-STD-MIB:286: [4] {hyphen-in-label} warning: named bit `node-prot' must not include a hyphen in SMIv2 mibs/MPLS-MLDP-STD-MIB:386: [1] {internal-other} syntax error, unexpected UPPERCASE_IDENTIFIER, expecting COLON_COLON_EQUAL mibs/MPLS-MLDP-STD-MIB:417: [5] {internal-flushing} warning: flushing recent incorrect declaration, see previous error(s) mibs/MPLS-MLDP-STD-MIB:482: [2] {description-missing} description missing in object definition mibs/MPLS-MLDP-STD-MIB:482: [1] {internal-other} syntax error, unexpected MAX_ACCESS, expecting COLON_COLON_EQUAL mibs/MPLS-MLDP-STD-MIB:493: [5] {internal-flushing} warning: flushing recent incorrect declaration, see previous error(s) mibs/MPLS-MLDP-STD-MIB:1060: [1] {internal-other} syntax error, unexpected '}', expecting UPPERCASE_IDENTIFIER or LOWERCASE_IDENTIFIER or NUMBER mibs/MPLS-MLDP-STD-MIB:1060: [5] {internal-flushing} warning: flushing recent incorrect declaration, see previous error(s) mibs/MPLS-MLDP-STD-MIB:1061: [1] {internal-other} syntax error, unexpected STATUS General Comments (please check throughout document) --------------------------------------------------------------------------------- *) Need to get this to compile using smilint. *) When other documents (RFCs or drafts) are mentioned, there should be a reference notation given. Please fix this throughout the draft. *) Naming Conventions: Please refer to RFC4181 (MIB guidelines). Basically, the naming conventions used in this MIB Module do not follow the recommended naming conventions (Appendix C). Prefix should be used throughout for all objects/tables/entries etc. So "mplsMldp" needs to be used consistently. *) Think there are more AUGMENTS relationships between RFC3815 Tables and Tables in this MIB Module but they are not defined as AUGMENTS within the MIB Module but are described as such within the document sections. Please make sure that the relationships between these tables are clarified. e.g. mplsMldpPeerCapabilityTable and mplsLdpPeerTable Section 2. Remove the first paragraph. Think this is understood. [[CREF1: The title and text for this section has been copied from the official boilerplate, and should not be modified unless the official boilerplate text from the OPS Area web site has changed. See RFC4818 section 3.1 for a discussion of the boilerplate section.]] Section 4. Overview *) Make sure the RFCs/drafts listed are referenced as being in the References Section (probably the Normative References section). Some of them are, some of the are not. Be consistent. *) Not very helpful to list a bunch of documents and not specify which features (i.e. specify the sections/sub-sections) appear in which documents. We already can see the list of documents in the References section so unless features/sections/subsections from these docs are specified per document, then don't see this as adding information. *) Also, some out of date listings, so need to update these. ietf-rtgwg-mofrr is an RFC as of 8/2015 ietf-mpls-mldp-node-protection is an RFC as of 1/2016 *) typo: ...stats per per Interface Section 6.2 mplsMldpSessionStatsTable : This table contains the number of mLDP FECs received and advertised to particular LDP session. s/to particular LDP session/ to a particular LDP session/ Section 7. There are ten scalars, listed below are defined for this MIB module. *) above sentence is awkward. Maybe something like: The following scalars are defined in this MIB Module: Section 8.1 *) s/from LDP peer/from an LDP peer/ Section 8.5 typo in section's title s/Upstreaam/Upstream/ Section 8.6 s/gives the information/gives information/ s/about number/about the number of/ (2 occurrences) s/received on particualr/received on a particular/ Please note: will review the other sections once the MIB compiles and compliance statements are added. References Section: *) Some references (drafts) out of date and RFCs are out of order References. Please update. Other *) Please remove Appendix A and Appendix B (and regenerate the Table of Contents.) --001a114147c8a29544054837dbe0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Authors,

This draft has come a long way since= the previous version.=C2=A0 Thanks for that.

Please make sure the M= IB compiles with smilint prior to MIB review as it is difficult to review a=
MIB Module that doesn't compile.

Also, please add complianc= e statements and conformance groups.

Comments below.
Thanks,
-= Joan


output from smilint compiler:
--------------------------= ----
While processing your request the following errors and/or warnings = have been found:

mibs/MPLS-MLDP-STD-MIB:76: [5] {date-year-2digits} = warning: date specification `2016092600Z' contains a two-digit year rep= resenting `1920'
mibs/MPLS-MLDP-STD-MIB:76: [2] {date-month} date sp= ecification `2016092600Z' contains an illegal month
mibs/MPLS-MLDP-S= TD-MIB:76: [2] {date-hour} date specification `2016092600Z' contains an= illegal hour
mibs/MPLS-MLDP-STD-MIB:76: [4] {date-in-past} warning: dat= e specification `2016092600Z' predates the SMI standard

Then aft= er that was fixed, more errors:

mibs/MPLS-MLDP-STD-MIB:268: [2] {ide= ntifier-redefined} redefinition of identifier `mplsLdpPeerCapabilityEntry&#= 39;
mibs/MPLS-MLDP-STD-MIB:254: [6] {previous-definition} info: previous= definition of `mplsLdpPeerCapabilityEntry'
mibs/MPLS-MLDP-STD-MIB:2= 68: [1] {internal-other} syntax error, unexpected COLON_COLON_EQUAL, expect= ing OBJECT
mibs/MPLS-MLDP-STD-MIB:271: [5] {internal-flushing} warning: = flushing recent incorrect declaration, see previous error(s)
mibs/MPLS-M= LDP-STD-MIB:279: [4] {hyphen-in-label} warning: named bit `upstream-label-a= ssignment' must not include a hyphen in SMIv2
mibs/MPLS-MLDP-STD-MIB= :283: [4] {hyphen-in-label} warning: named bit `prot-lsr' must not incl= ude a hyphen in SMIv2
mibs/MPLS-MLDP-STD-MIB:286: [4] {hyphen-in-label} = warning: named bit `node-prot' must not include a hyphen in SMIv2
mi= bs/MPLS-MLDP-STD-MIB:386: [1] {internal-other} syntax error, unexpected UPP= ERCASE_IDENTIFIER, expecting COLON_COLON_EQUAL
mibs/MPLS-MLDP-STD-MIB:41= 7: [5] {internal-flushing} warning: flushing recent incorrect declaration, = see previous error(s)
mibs/MPLS-MLDP-STD-MIB:482: [2] {description-missi= ng} description missing in object definition
mibs/MPLS-MLDP-STD-MIB:482:= [1] {internal-other} syntax error, unexpected MAX_ACCESS, expecting COLON_= COLON_EQUAL
mibs/MPLS-MLDP-STD-MIB:493: [5] {internal-flushing} warning:= flushing recent incorrect declaration, see previous error(s)
mibs/MPLS-= MLDP-STD-MIB:1060: [1] {internal-other} syntax error, unexpected '}'= ;, expecting UPPERCASE_IDENTIFIER or LOWERCASE_IDENTIFIER or NUMBER
mibs= /MPLS-MLDP-STD-MIB:1060: [5] {internal-flushing} warning: flushing recent i= ncorrect declaration, see previous error(s)
mibs/MPLS-MLDP-STD-MIB:1061:= [1] {internal-other} syntax error, unexpected STATUS



Genera= l Comments (please check throughout document)
--------------------------= -------------------------------------------------------
*) Need to get t= his to compile using smilint.


*) When other documents (RFCs or d= rafts) are mentioned, there should be a reference notation given.=C2=A0 Ple= ase fix this throughout the draft.

*) Naming Conventions:=C2=A0 Plea= se refer to RFC4181 (MIB guidelines).
Basically, the naming conventions = used in this MIB Module do not follow
the recommended naming conventions= (Appendix C).=C2=A0

Prefix should be used throughout for all objec= ts/tables/entries etc.=C2=A0=C2=A0
So "mplsMldp" needs to be = used consistently.


*) Think there are more AUGMENTS relationship= s between RFC3815 Tables and Tables in this MIB Module
but they are not = defined as AUGMENTS within the MIB Module but are described as such within = the
document sections.=C2=A0=C2=A0 Please make sure that the relationshi= ps between these tables are clarified.
e.g.=C2=A0 mplsMldpPeerCapability= Table and mplsLdpPeerTable


Section 2.

Remove the first pa= ragraph.=C2=A0 Think this is understood.

=C2=A0=C2=A0 [[CREF1: The t= itle and text for this section has been copied from the
=C2=A0=C2=A0 off= icial boilerplate, and should not be modified unless the official
=C2=A0= =C2=A0 boilerplate text from the OPS Area web site has changed.=C2=A0 See R= FC4818
=C2=A0=C2=A0 section 3.1 for a discussion of the boilerplate sect= ion.]]


Section 4. Overview

*) Make sure the RFCs/drafts l= isted are referenced as being in the References Section (probably the Norma= tive References section).=C2=A0 Some of them are, some of the are not.=C2= =A0 Be consistent.

*) Not very helpful to list a bunch of documents = and not specify which features (i.e. specify the sections/sub-sections) app= ear in which documents.
We already can see the list of documents in the= References section so unless features/sections/subsections from these docs= are specified per document, then don't see this as adding information.=

*) Also, some out of date listings, so need to update these.
iet= f-rtgwg-mofrr is an RFC as of 8/2015
ietf-mpls-mldp-node-protection is a= n RFC as of 1/2016

*) typo:=C2=A0 ...stats per per Interface

=
Section 6.2

=C2=A0=C2=A0 mplsMldpSessionStatsTable : This table = contains the number of mLDP
=C2=A0=C2=A0 FECs received and advertised to= particular LDP session.

s/to particular LDP session/ to a particula= r LDP session/


Section 7.

=C2=A0=C2=A0 There are ten scal= ars, listed below are defined for this MIB module.

*) above sentence= is awkward.=C2=A0 Maybe something like:

The following scalars are d= efined in this MIB Module:


Section 8.1

*) s/from LDP peer= /from an LDP peer/


Section 8.5

typo in section's titl= e
s/Upstreaam/Upstream/


Section 8.6

s/gives the inform= ation/gives information/
s/about number/about the number of/=C2=A0 (2 oc= currences)

s/received on particualr/received on a particular/
Please note:=C2=A0 will review the other sections once the MIB compiles a= nd compliance statements are added.


References Section:
*) So= me references (drafts) out of date and RFCs are out of order References.=C2= =A0 Please update.

Other
*) Please remove Appendix A and Appendix= B (and regenerate the Table of Contents.)


--001a114147c8a29544054837dbe0-- From nobody Fri Feb 17 23:31:24 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71941293FC for ; Fri, 17 Feb 2017 23:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.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 5mHDouC4Twig for ; Fri, 17 Feb 2017 23:31:14 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B6A1293F8 for ; Fri, 17 Feb 2017 23:31:13 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u25so62067643qki.2 for ; Fri, 17 Feb 2017 23:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UiHWESVuO1tG80jUZN5XastfdZssi9PCB7nlUsCb7wo=; b=HGDmJ5QECRwg44PPbMiQdAAVM06OOBRhz9aeO93ULNBRpxPRgT88fp6TGWK3TqCcfQ Mch/YRge8mUVq1wfX8Pz2y58ZJoe0QTu8HqRH5AHyOi3dqaB227tpV5dToFkb5qqSQ+r w2i2dmnfeuIpiza11uUKWtUsreaU+FyKFrskV8UcZyIf+nBnXiB0QYm3ZexYS/3pCki0 4rPxsaWnAEB1U0YZjSWkEFD4ZKcLbrybI2V7W5WRqPa//iQ5PJp3PH0ECzC3pCFa31qh 2Cvpaxeu365os46VuWbUKGynmA2aVlaKcjAzzwexshDce6HXitoL05zKVfrBJT382dK0 bKzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UiHWESVuO1tG80jUZN5XastfdZssi9PCB7nlUsCb7wo=; b=d/T25ZMsAWYqc+AlFCMkr7jn/GRIH4TVJ0YIqWmOnLJRWTggurVHDevnmiAEfPNZsm 7PPZZszPGimzKE9VA+R3GuUL5UlOj6TWupj4RSinrVnTenNZlxun1B80GHtcOLzdRVsq 8rcpCxm7OKiZP8W8C1tWNJ8ubPi9XiBjqIWwSZY6XpX/TPvqEdEDh/CyRtVABg4yG2Ey 4//mbRHHUr8nv2SIv5K8NCi0Qu2oNpyZ0HVX6B/CCED1RLpLepLPJDSY5+FPSJuu+kxY 7IKYHx7eKKYKNrWEZH7j1P6LvdJxRNO/Jcj63vOMtDBycSsNU4gZsRgfnsEvMuRn0MbT mxfw== X-Gm-Message-State: AMke39l+f5/X93ls/5Oy3jf/3nwboMKe70E0J/ULqddMzur9xKIjrpOhJ+bwX13WYqlqxmMHguTZ4yJhDcVUEEYl X-Received: by 10.55.8.20 with SMTP id 20mr10780449qki.49.1487403072419; Fri, 17 Feb 2017 23:31:12 -0800 (PST) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.95.99 with HTTP; Fri, 17 Feb 2017 23:30:31 -0800 (PST) In-Reply-To: <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.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> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> From: Hiroshi Tsunoda Date: Sat, 18 Feb 2017 16:30:31 +0900 X-Google-Sender-Auth: 2DGEifnjt3B2KHKbfyfL742LJtk Message-ID: To: Glenn Mansfield Keeni Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 07:31:19 -0000 Dear Glenn, I am sorry I kept you waiting so long for the revised version, I have been side tracked by other things. I will submit the next version within three days. The next version will address all of remained your comments. The summary of remained TODOs is shown below. Please wait a little more time. ------------- 1. Add general explanation about MVPN, multicast in VPLS Define and explain some technical terms, such as PIM-MVPN, UDP-based S-PMSI etc. 2. Revise summary of the MIB module 3. Revise MIB definition a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to cover all cases. c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId d. Fix the description of l2L3VpnMcastPmsiTunnelPointer 4. Split the MIB module into two separate modules. 5. Revise security considertations ------------- P.S. Update of mvpn-mib-02 will be submitted by the end of this month. Best regards, -- tsuno 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : > Hi Tsunoda, >> I have started to volunteer to help to move this document forward. > Great! >> I posted a new revision and addressed all editorial things in >> that revision. > Got this. Looks good. >> Please give me some more time for revising other parts, > No problems. Will be looking forward to the revised document. > > Glenn > > > On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >> >> Dear Glenn, >> >> Thanks for your careful review and detailed comments/suggestions. >> I have started to volunteer to help to move this document forward. >> I posted a new revision and addressed all editorial things in that >> revision. >> Please give me some more time for revising other parts, >> in order to be familiar with the context of the original and related >> documents. >> >> URL: >> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.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-05 >> Diff: >> >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >> >> Please see some notes below. >> >>> 0. Abstract. >>> 0.1. >>>> >>>> it describes common managed objects used to configure >>> >>> and/or monitor both L2 and L3 VPN Multicast. >>> >>> There are no writable MOs in this MIB. So it does not look >>> as though this MIB will be used for configuration directly. >>> The use case scenario for monitoring is not clear, either. >>> It appears that the MIB module(s) in this document will be >>> used by other modules which are designed for monitoring and/ >>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>> wording. >> >> >> Fixed. >> >>> 1. Introduction >>> >>> 1.1 >>> Would be very nice if a short explanations of MVPN and >>> L2 VPN Multicast were given. With emphasis on the operational >>> aspects. >> >> >> TBD. Please give me some more time to revise. >> >>> 1.2 >>> s/referred to MVPN and L2 VPN Multicast respectively/ >>> referred to as MVPN and L2 VPN Multicast,respectively/ >> >> >> Fixed. >> >>> 1.3 >>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >> >> >> Fixed. >> >>> 1.4 .... there are 2 types of PMSIs .. >>> >>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>> >>> >>> please make these explanations more gentle(complete) to the reader. >>> Also, give the references where these terms are defined. >> >> >> TBD. Please give me some more time to revise. >> >>> 3. Summary of MIB Module >>> 3.1 >>>> >>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>> >>> Typo: I/S-PMSI, (see 3.3 below). >> >> >> Fixed. >> >>> 3.2 some more text like the following will be good. >>> L2L3-VPN-MCAST-MIB contains >>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>> an enumeration of the provider tunnel types and, >>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>> composed of multiple attributes that depend on the tunnel type and >>> uniquely identify a tunnel. This table will be used to ... monitor >>> the tunnels supported by the system at a given point of time (?) >>> It may also be used in conjunction with XXXX-mib to obtain the >>> other details of a tunnel by following the row pointer of the >>> corresponding tunnel's row in this table. >>> [ Please treat the above as a template and modify the text as >>> appropriate ..] >> >> >> TBD. Please give me some more time to revise this point. >> >>> 3.3 Since this will become a standard document, please take care of >>> definitions and notations used in the document. >>> The notation I/S-PMSI is not defined. If you must use a new >>> term/notation, define it before use. >> >> >> TBD. Please give me some more time to revise this point. >> >>> 4. Definitions >>> >>>> IMPORTS >>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>> >>> 4.1 Since this is not a Experimental MIB do not import use experimental. >>> It is good practice to keep the draft in the as "close to final form" >>> as possible. (See below) >> >> >> Fixed. >> >>> 4.2 >>>> >>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>> >>> Please update this date. >> >> >> Updated. >> >>> 4.3 >>>> >>>> DESCRIPTION >>>> "This MIB contains common managed object definitions for >>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>> >>> Would be good if you could rearrange the text. Something like >>> "This MIB module will be used for managing multicast in Layer 2 >>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>> Or, even better >>> "This MIB module will be used by other MIB modules designed for >>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>> [RFC6513], [RFC6514] >>> Or, a combination of both, depending on the envisaged use case >>> scenarios. >> >> >> Rearranged the text along with your comment. >> >>> 4.4 >>>> >>>> ::= { experimental 999 } >>> >>> Please >>> o Replace "experimental" by the branch where this mib module will >>> be anchored; that is a decision that the WG will take, probably. >>> o Import the branch in the IMPORTS statement >>> [ In the IANA Considerations section a branch in the mib-2 subtree >>> is requested. In that case this must be >>> ::= { mib-2 XXX } >>> ] >> >> >> Fixed. >> >>> 4.5 >>>> >>>> -- Please also remove the ", experimental" text from earlier >>>> -- IMPORTS section. >>> >>> Remove these instructions. >> >> >> Removed. >> >>> 4.5.2 >>>> >>>> -- Texual convention >>> >>> Typo: -- Textual convention >> >> >> Fixed. >> >>> 4.6 >>>> >>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>> DESCRIPTION >>>> "Types of provider tunnels used for multicast in >>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>> in future RFCs, and those will be allowed as >>>> valid types for L2L3VpnMcastProviderTunnelType." >>> >>> The part >>>> >>>> Additional types may be defined >>>> in future RFCs, and those will be allowed as >>>> valid types for L2L3VpnMcastProviderTunnelType." >>> >>> may be deleted. >> >> >> Deleted. >> >>> 4.7 >>>> >>>> -- Top level components of this MIB. >>>> -- tables, scalars, conformance information >>>> >>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>> >>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>> >>>> >>>> -- Table of PMSI Tunnel Attributes >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>> >>> >>> should be >>> >>> -- Top level components of this MIB. >>> >>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>> >>> -- tables, scalars, conformance information >>> -- Table of PMSI Tunnel Attributes >>> >>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >> >> >> Fixed. >> >>> 4.8 >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>> MAX-ACCESS not-accessible >>>> STATUS current >>>> DESCRIPTION >>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>> The entries may be referred to by I-PMSI or S-PMSI table >>>> entries defined in other MIBs, e.g. mvpnMIB in >>>> [I-D.ietf-bess-mvpn-mib]." >>> >>> >>> It would seem that each row in this table is an index for a PTA >>> and may contain pointers to rows in tables of other MIB modules >>> which may contain more details for the PTA. Is that correct? >>> Please reword the DESCRIPTION acordingly. >>> Also see comments in 4.15 >> >> >> TBD. I need some more time to understand the original context. >> >>> 4.9 >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>> "An entry in this table corresponds to a PTA >>>> that is advertised/received on this router. >>> >>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>> so "entry in this table" does not fit in well. >>> A rewording like >>> "A conceptual row corresponding to a PTA >>> that is advertised/received on this router. >>> .... >>> would be better. >> >> >> Fixed. >> >>> 4.10 >>>> >>>> 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. >>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>> they're derived from the S-PMSI Join Message. >>> >>> >>>> Note that BGP-based signaling may be used for >>>> PIM-MVPN as well." >>> >>> Is the signaling mechanism important here? If it isn't then the >>> above part of the description is redundant. >> >> >> Removed the above part. >> >>> 4.10-2 >>> PIM-MVPN appears for the first time. >> >> >> Defined the notation of PIM-MVPM as follows >> Protocol Independent Multicast - MVPN (PIM-MVPN) >> However, I think that some descriptions may be required for this >> somewhere in this document. That is TBD. >> >>> 4.10-3 >>> the phrase UDP-based S-PMSI appears here for the first time. >>> Somewhere earlier it should be made clear that UDP too may be used >>> in signaling. >> >> >> TBD. >> >>> 4.11 >>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>> >>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>> >>> "this" is unclear. >>> Something like "the value of this object is 0" will be better. >> >> >> Fixed. >> >>>> More bits may be defined in the future and >>>> they will be registered in IANA Registry xxxx." >>> >>> This part is probably redundant. >> >> >> Removed. >> >>> 4.12 >>>> >>>> -- RFC Ed. replace xxxx with the actual registry name >>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>> -- and remove this note. >>> >>> >>> Look at the comments in 6.0 >> >> >> The above description ("IANA Registry xxxx.") was removed, >> thus this part was also removed. >> >>> 4.13 >>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>> >>>> DESCRIPTION >>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>> field in PMSI Tunnel Attribute of the corresponding >>>> I/S-PMSI A-D or Leaf A-D route." >>> >>> o Does this description cover all the types? If not, then cover all the >>> types unless there is a good reason to focus only on the above types. >>> o I/S-PMSI: unexplained notation. >> >> >> TBD. Please give me some more time to address this point. >> >>> 4.14 >>> >>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>> >>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>> >>> It appears that you also allow sizes "16" and "32"; these must be >>> included. >> >> >> Fixed. >> >>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>> >>> Please indicate that the first column gives the size >> >> >> I made a change as follows. >> >> Size l2L3VpnMcastPmsiTunnelAttributeType >> (IPv4/IPv6) >> -------------------------------------------------- >> (snip) >> 8/32 pimAsm >> (snip) >> >> Is this OK? >> >>>> 8/32 pimAsm >>>> 8/32 pimSsm >>>> 8/32 pimBidir >>>> 4/16 ingressReplication >>> >>> >>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>> 8 or 32 octets of this attribute are filled with >>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>> 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." >>> >>> >>> A more generous description of the AttributeID would be good. All the >>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>> summary would be very nice. >> >> >> TBD. Please give me some more time to revise this point. >> >>> 4.15 >>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>> >>>> SYNTAX RowPointer >>>> DESCRIPTION >>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>> pointer is null." >>> >>> I am having problems understanding this. Will help if you can give >>> a use case of how this will be used. As of now the intent is unclear. >>> A RowPointer cannot be pointing to "some MIB table". It must be >>> pointer to a specific row in a specific table. If this is a pointer to >>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >> >> >> TBD. I will need some more time to understand the original context. >> >>> 4.16 >>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>> DESCRIPTION >>>> >>>> "If the tunnel has a corresponding interface, this is the >>>> row pointer to ifXTable. Otherwise, the pointer is null." >>> >>> This description is better. Would be even better with >>> "If the tunnel has a corresponding entry in the ifXTable, >>> this object will point to the row pertaining to the entry ..... >> >> >> Fixed. >> >>> 4.17 >>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>> >>>> DESCRIPTION >>>> "Support of these object is not required." >>> >>> Support of these objects is not required. >> >> >> Fixed. >> >>> 5.0 >>>> >>>> 5. Security Considerations >>> >>> TBD >> >> >> Still TBD. >> >>> 6.0 >>>> >>>> 6. IANA Considerations >>> >>> >>>> IANA is requested to root MIB objects in the MIB module contained in >>>> this document under the mib-2 subtree. >>> >>> >>> Please Note: >>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >>> put the definitions in a separate MIB module. That would mean a >>> separate branch in the mib-2 subtree. Then the maintenance of the >>> TC can be carried out by some entity ( IANA or, some WG or, whoever is >>> responsible for maintaining the TC) independent of other MIB objects. >>> If that is the intent you will need to define 2 mib modules and you >>> will >>> need to request 2 branches in the mib-2 subtree- one for the module >>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >> >> >> TBD. I will address this point in the next revision. >> >> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>> >>> 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 ; Benoit Claise >>>>> ; EXT - thomas.morin@orange.com >>>>> >>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>> Vigoureux >>>>> ; 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 >>>>>>> ::= { XXX } >>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>>>> note >>>>>>> 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 ; EXT - thomas.morin@orange.com >>>>>>> >>>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>>> >>>>> >>>>> Martin >>>>>>> >>>>>>> >>>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>>> >>>>>>> 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 >>>>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> > From nobody Sat Feb 18 17:30:51 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E301296AC; Sat, 18 Feb 2017 17:30:45 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fIaxoej_iOP9; Sat, 18 Feb 2017 17:30:40 -0800 (PST) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF2E124281; Sat, 18 Feb 2017 17:30:40 -0800 (PST) Received: from [192.168.0.94] (cysvpn07.priv.cysol.co.jp [192.168.0.94]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v1J1UTsS043791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 19 Feb 2017 10:30:30 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda 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> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> From: Glenn Mansfield Keeni Message-ID: <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> Date: Sun, 19 Feb 2017 10:30:24 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2017 01:30:45 -0000 Dear Tsunoda, > I will submit the next version within three days. > The next versionbwill address all of remained your > comments. Great! Looking forward to the revised draft. Glenn On 2017/02/18 16:30, Hiroshi Tsunoda wrote: > Dear Glenn, > > I am sorry I kept you waiting so long for the revised version, I have > been side tracked by other things. > I will submit the next version within three days. The next version > will address all of remained your comments. > The summary of remained TODOs is shown below. Please wait a little more time. > ------------- > 1. Add general explanation about MVPN, multicast in VPLS > Define and explain some technical terms, such as PIM-MVPN, > UDP-based S-PMSI etc. > > 2. Revise summary of the MIB module > > 3. Revise MIB definition > a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable > b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to > cover all cases. > c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId > d. Fix the description of l2L3VpnMcastPmsiTunnelPointer > > 4. Split the MIB module into two separate modules. > > 5. Revise security considertations > ------------- > > P.S. Update of mvpn-mib-02 will be submitted by the end of this month. > > Best regards, > > -- tsuno > > 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >> Hi Tsunoda, >>> I have started to volunteer to help to move this document forward. >> Great! >>> I posted a new revision and addressed all editorial things in >>> that revision. >> Got this. Looks good. >>> Please give me some more time for revising other parts, >> No problems. Will be looking forward to the revised document. >> >> Glenn >> >> >> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>> >>> Dear Glenn, >>> >>> Thanks for your careful review and detailed comments/suggestions. >>> I have started to volunteer to help to move this document forward. >>> I posted a new revision and addressed all editorial things in that >>> revision. >>> Please give me some more time for revising other parts, >>> in order to be familiar with the context of the original and related >>> documents. >>> >>> URL: >>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.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-05 >>> Diff: >>> >>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>> >>> Please see some notes below. >>> >>>> 0. Abstract. >>>> 0.1. >>>>> >>>>> it describes common managed objects used to configure >>>> >>>> and/or monitor both L2 and L3 VPN Multicast. >>>> >>>> There are no writable MOs in this MIB. So it does not look >>>> as though this MIB will be used for configuration directly. >>>> The use case scenario for monitoring is not clear, either. >>>> It appears that the MIB module(s) in this document will be >>>> used by other modules which are designed for monitoring and/ >>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>> wording. >>> >>> >>> Fixed. >>> >>>> 1. Introduction >>>> >>>> 1.1 >>>> Would be very nice if a short explanations of MVPN and >>>> L2 VPN Multicast were given. With emphasis on the operational >>>> aspects. >>> >>> >>> TBD. Please give me some more time to revise. >>> >>>> 1.2 >>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>> >>> >>> Fixed. >>> >>>> 1.3 >>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>> >>> >>> Fixed. >>> >>>> 1.4 .... there are 2 types of PMSIs .. >>>> >>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>> >>>> >>>> please make these explanations more gentle(complete) to the reader. >>>> Also, give the references where these terms are defined. >>> >>> >>> TBD. Please give me some more time to revise. >>> >>>> 3. Summary of MIB Module >>>> 3.1 >>>>> >>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>> >>>> Typo: I/S-PMSI, (see 3.3 below). >>> >>> >>> Fixed. >>> >>>> 3.2 some more text like the following will be good. >>>> L2L3-VPN-MCAST-MIB contains >>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>>> an enumeration of the provider tunnel types and, >>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>>> composed of multiple attributes that depend on the tunnel type and >>>> uniquely identify a tunnel. This table will be used to ... monitor >>>> the tunnels supported by the system at a given point of time (?) >>>> It may also be used in conjunction with XXXX-mib to obtain the >>>> other details of a tunnel by following the row pointer of the >>>> corresponding tunnel's row in this table. >>>> [ Please treat the above as a template and modify the text as >>>> appropriate ..] >>> >>> >>> TBD. Please give me some more time to revise this point. >>> >>>> 3.3 Since this will become a standard document, please take care of >>>> definitions and notations used in the document. >>>> The notation I/S-PMSI is not defined. If you must use a new >>>> term/notation, define it before use. >>> >>> >>> TBD. Please give me some more time to revise this point. >>> >>>> 4. Definitions >>>> >>>>> IMPORTS >>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>> >>>> 4.1 Since this is not a Experimental MIB do not import use experimental. >>>> It is good practice to keep the draft in the as "close to final form" >>>> as possible. (See below) >>> >>> >>> Fixed. >>> >>>> 4.2 >>>>> >>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>> >>>> Please update this date. >>> >>> >>> Updated. >>> >>>> 4.3 >>>>> >>>>> DESCRIPTION >>>>> "This MIB contains common managed object definitions for >>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>> >>>> Would be good if you could rearrange the text. Something like >>>> "This MIB module will be used for managing multicast in Layer 2 >>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>> Or, even better >>>> "This MIB module will be used by other MIB modules designed for >>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>> [RFC6513], [RFC6514] >>>> Or, a combination of both, depending on the envisaged use case >>>> scenarios. >>> >>> >>> Rearranged the text along with your comment. >>> >>>> 4.4 >>>>> >>>>> ::= { experimental 999 } >>>> >>>> Please >>>> o Replace "experimental" by the branch where this mib module will >>>> be anchored; that is a decision that the WG will take, probably. >>>> o Import the branch in the IMPORTS statement >>>> [ In the IANA Considerations section a branch in the mib-2 subtree >>>> is requested. In that case this must be >>>> ::= { mib-2 XXX } >>>> ] >>> >>> >>> Fixed. >>> >>>> 4.5 >>>>> >>>>> -- Please also remove the ", experimental" text from earlier >>>>> -- IMPORTS section. >>>> >>>> Remove these instructions. >>> >>> >>> Removed. >>> >>>> 4.5.2 >>>>> >>>>> -- Texual convention >>>> >>>> Typo: -- Textual convention >>> >>> >>> Fixed. >>> >>>> 4.6 >>>>> >>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>> DESCRIPTION >>>>> "Types of provider tunnels used for multicast in >>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>> in future RFCs, and those will be allowed as >>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>> >>>> The part >>>>> >>>>> Additional types may be defined >>>>> in future RFCs, and those will be allowed as >>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>> >>>> may be deleted. >>> >>> >>> Deleted. >>> >>>> 4.7 >>>>> >>>>> -- Top level components of this MIB. >>>>> -- tables, scalars, conformance information >>>>> >>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>> >>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>>> >>>>> >>>>> -- Table of PMSI Tunnel Attributes >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>> >>>> >>>> should be >>>> >>>> -- Top level components of this MIB. >>>> >>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>> >>>> -- tables, scalars, conformance information >>>> -- Table of PMSI Tunnel Attributes >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>> >>> >>> Fixed. >>> >>>> 4.8 >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>> [I-D.ietf-bess-mvpn-mib]." >>>> >>>> >>>> It would seem that each row in this table is an index for a PTA >>>> and may contain pointers to rows in tables of other MIB modules >>>> which may contain more details for the PTA. Is that correct? >>>> Please reword the DESCRIPTION acordingly. >>>> Also see comments in 4.15 >>> >>> >>> TBD. I need some more time to understand the original context. >>> >>>> 4.9 >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>> "An entry in this table corresponds to a PTA >>>>> that is advertised/received on this router. >>>> >>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>>> so "entry in this table" does not fit in well. >>>> A rewording like >>>> "A conceptual row corresponding to a PTA >>>> that is advertised/received on this router. >>>> .... >>>> would be better. >>> >>> >>> Fixed. >>> >>>> 4.10 >>>>> >>>>> 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. >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>> they're derived from the S-PMSI Join Message. >>>> >>>> >>>>> Note that BGP-based signaling may be used for >>>>> PIM-MVPN as well." >>>> >>>> Is the signaling mechanism important here? If it isn't then the >>>> above part of the description is redundant. >>> >>> >>> Removed the above part. >>> >>>> 4.10-2 >>>> PIM-MVPN appears for the first time. >>> >>> >>> Defined the notation of PIM-MVPM as follows >>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>> However, I think that some descriptions may be required for this >>> somewhere in this document. That is TBD. >>> >>>> 4.10-3 >>>> the phrase UDP-based S-PMSI appears here for the first time. >>>> Somewhere earlier it should be made clear that UDP too may be used >>>> in signaling. >>> >>> >>> TBD. >>> >>>> 4.11 >>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>> >>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>> >>>> "this" is unclear. >>>> Something like "the value of this object is 0" will be better. >>> >>> >>> Fixed. >>> >>>>> More bits may be defined in the future and >>>>> they will be registered in IANA Registry xxxx." >>>> >>>> This part is probably redundant. >>> >>> >>> Removed. >>> >>>> 4.12 >>>>> >>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>> -- and remove this note. >>>> >>>> >>>> Look at the comments in 6.0 >>> >>> >>> The above description ("IANA Registry xxxx.") was removed, >>> thus this part was also removed. >>> >>>> 4.13 >>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>> >>>>> DESCRIPTION >>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>> field in PMSI Tunnel Attribute of the corresponding >>>>> I/S-PMSI A-D or Leaf A-D route." >>>> >>>> o Does this description cover all the types? If not, then cover all the >>>> types unless there is a good reason to focus only on the above types. >>>> o I/S-PMSI: unexplained notation. >>> >>> >>> TBD. Please give me some more time to address this point. >>> >>>> 4.14 >>>> >>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>> >>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>> >>>> It appears that you also allow sizes "16" and "32"; these must be >>>> included. >>> >>> >>> Fixed. >>> >>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>> >>>> Please indicate that the first column gives the size >>> >>> >>> I made a change as follows. >>> >>> Size l2L3VpnMcastPmsiTunnelAttributeType >>> (IPv4/IPv6) >>> -------------------------------------------------- >>> (snip) >>> 8/32 pimAsm >>> (snip) >>> >>> Is this OK? >>> >>>>> 8/32 pimAsm >>>>> 8/32 pimSsm >>>>> 8/32 pimBidir >>>>> 4/16 ingressReplication >>>> >>>> >>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>> 8 or 32 octets of this attribute are filled with >>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>> 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." >>>> >>>> >>>> A more generous description of the AttributeID would be good. All the >>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>>> summary would be very nice. >>> >>> >>> TBD. Please give me some more time to revise this point. >>> >>>> 4.15 >>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>> >>>>> SYNTAX RowPointer >>>>> DESCRIPTION >>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>> pointer is null." >>>> >>>> I am having problems understanding this. Will help if you can give >>>> a use case of how this will be used. As of now the intent is unclear. >>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>> pointer to a specific row in a specific table. If this is a pointer to >>>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >>> >>> >>> TBD. I will need some more time to understand the original context. >>> >>>> 4.16 >>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>> DESCRIPTION >>>>> >>>>> "If the tunnel has a corresponding interface, this is the >>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>> >>>> This description is better. Would be even better with >>>> "If the tunnel has a corresponding entry in the ifXTable, >>>> this object will point to the row pertaining to the entry ..... >>> >>> >>> Fixed. >>> >>>> 4.17 >>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>> >>>>> DESCRIPTION >>>>> "Support of these object is not required." >>>> >>>> Support of these objects is not required. >>> >>> >>> Fixed. >>> >>>> 5.0 >>>>> >>>>> 5. Security Considerations >>>> >>>> TBD >>> >>> >>> Still TBD. >>> >>>> 6.0 >>>>> >>>>> 6. IANA Considerations >>>> >>>> >>>>> IANA is requested to root MIB objects in the MIB module contained in >>>>> this document under the mib-2 subtree. >>>> >>>> >>>> Please Note: >>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >>>> put the definitions in a separate MIB module. That would mean a >>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>> TC can be carried out by some entity ( IANA or, some WG or, whoever is >>>> responsible for maintaining the TC) independent of other MIB objects. >>>> If that is the intent you will need to define 2 mib modules and you >>>> will >>>> need to request 2 branches in the mib-2 subtree- one for the module >>>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>> >>> >>> TBD. I will address this point in the next revision. >>> >>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>> >>>> 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 ; Benoit Claise >>>>>> ; EXT - thomas.morin@orange.com >>>>>> >>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>> Vigoureux >>>>>> ; 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 >>>>>>>> ::= { XXX } >>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>>>>> note >>>>>>>> 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 ; EXT - thomas.morin@orange.com >>>>>>>> >>>>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>>>> >>>>>> >>>>>> Martin >>>>>>>> >>>>>>>> >>>>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>>>> >>>>>>>> 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 >>>>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> BESS mailing list >>>> BESS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bess >>>> >> > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > From nobody Mon Feb 20 23:51:26 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21CB129874 for ; Mon, 20 Feb 2017 23:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.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 jEC9uGW6viEx for ; Mon, 20 Feb 2017 23:51:20 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E42129861 for ; Mon, 20 Feb 2017 23:51:19 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u188so39386031qkc.2 for ; Mon, 20 Feb 2017 23:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=7QPIHDMskjMoSoGd/ce0MI1lh+1+DfmyiQ6QdJ+zO8M=; b=bZJwvRk9JHaINA5snQBgpcJ0+EhzKceM1I0En0jXzPTcydn5gYKU+oXALHKkLpk1af 429fe69A1K+2pok9PODKnNBoWjE2VQtzOW6+cHRVSLXXU3BVR/9RSsrpEtHGUi+A9mSs QY6rIG0eDWHv2SfB5hEoFqOC++wpJ9QH4q85QVkyHkD/iUuza+SKULeq/GQlncHUnWVs VqMsMbaSlpbDo7py/wjVA4Hn2pOwizpAIbgoEqqQR7DSronan7bBWpPxhvh60YLrFkRV 3wVdj/UIvy3iw1ARAfLwVIdVwUj0qkFQtZt7NCnTJKbLDg+s3wNT6h05D8aY94NJQzzY u2SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=7QPIHDMskjMoSoGd/ce0MI1lh+1+DfmyiQ6QdJ+zO8M=; b=Mv0KoAUWoViErtr+C5nL2FHEHbQKpy1adILAHKRvyPNGFigClrP1Zyb8l9j0TdByhV o8eFC+Xr3m8GXQId4Rq71Fenfce+uVTBTbSgS/IiWwwD8+v0HeM+dMXhv6pRt4w7PU2F vuK+tgfZf2U/ZSNxMMNe8ircdI0UOAoTqO9Z0k4AzbnrlJa6WcxyulzXTtJxTIja7AOt ZdD6ebMR5q4AGWmd1wgtnVoISdPmhIn5WxNmZT27RQ0+oQSJdEzO9L1WABKyO1iE6kXG pBUJvSJD4GVebuAYXfizMaZnFemChsrX83HJyQe2eTm3/viYxwwVOpsqnGXHRjT+r5yT rthA== X-Gm-Message-State: AMke39mdcPpG4jxpNNRvoJqxREAeIaEvCZ+vK8bnDARdw0CVc33T17TrinWINarrYFhq2CUf3U2It7F4kIAt9QP3 X-Received: by 10.55.17.206 with SMTP id 75mr22409211qkr.34.1487663477728; Mon, 20 Feb 2017 23:51:17 -0800 (PST) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.95.99 with HTTP; Mon, 20 Feb 2017 23:50:37 -0800 (PST) In-Reply-To: <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.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> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> From: Hiroshi Tsunoda Date: Tue, 21 Feb 2017 16:50:37 +0900 X-Google-Sender-Auth: uxsJ6-OWp2J1ZzM0Sn6sKCmZAyI Message-ID: To: Glenn Mansfield Keeni Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 07:51:25 -0000 Dear Glenn and BESS WG, I posted a new revision as follows. I think that I have addressed all of Glenn's comments in this revision. In this revision, I have tried to add more detailed explanation throughout the document. Please review and let me know if there are any misunderstanding from technical view points. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-06.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-06 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-06 Please see some notes below. > 1. Introduction > > 1.1 > Would be very nice if a short explanations of MVPN and > L2 VPN Multicast were given. With emphasis on the operational > aspects. I have updated Introduction. I hope this update fulfills your requirements. > 1.4 .... there are 2 types of PMSIs .. > > > o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. > > o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. > > please make these explanations more gentle(complete) to the reader. > Also, give the references where these terms are defined. More gentle explanation and references were added in Terminology section (Sec.1.1). > 3.2 some more text like the following will be good. > L2L3-VPN-MCAST-MIB contains > o a Textual Convention L2L3VpnMcastProviderTunnelType that provides > an enumeration of the provider tunnel types and, > o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is > composed of multiple attributes that depend on the tunnel type and > uniquely identify a tunnel. This table will be used to ... monitor > the tunnels supported by the system at a given point of time (?) > It may also be used in conjunction with XXXX-mib to obtain the > other details of a tunnel by following the row pointer of the > corresponding tunnel's row in this table. > [ Please treat the above as a template and modify the text as > appropriate ..] Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. > 3.3 Since this will become a standard document, please take care of > definitions and notations used in the document. > The notation I/S-PMSI is not defined. If you must use a new > term/notation, define it before use. The notation I/S-PMSI is defined in Sec.1.1 now. > 4.8 > > l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE > > SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry > > MAX-ACCESS not-accessible > > STATUS current > > DESCRIPTION > > "This table is for PMSI Tunnel Attributes (PTAs) > > advertised/received in I/S-PSMI Auto-Discovery routes. > > The entries may be referred to by I-PMSI or S-PMSI table > > entries defined in other MIBs, e.g. mvpnMIB in > > [I-D.ietf-bess-mvpn-mib]." > > It would seem that each row in this table is an index for a PTA > and may contain pointers to rows in tables of other MIB modules > which may contain more details for the PTA. Is that correct? > Please reword the DESCRIPTION acordingly. > Also see comments in 4.15 I have changed DESCRIPTION as follows. "An entry of this table corresponds with a PMSI Tunnel attribute and is created by a PE router that advertises and receives the attribute. The entry in the table will be referred by other MIB modules which are designed for monitoring and/or configuring both L2 and L3 VPN that support multicast." > 4.10-3 > the phrase UDP-based S-PMSI appears here for the first time. > Somewhere earlier it should be made clear that UDP too may be used > in signaling. In Introduction, I have explained that BGP and UDP are used in signaling. > 4.13 > l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE > > DESCRIPTION > > "As defined for L2L3VpnMcastProviderTunnelType. > > For UDP-based S-PMSI signaling for PIM-MVPN, > > this is pim-asm (3), pim-ssm (4), or pim-bidir (5). > > For BGP-based I/S-PMSI signaling, this is the Tunnel Type > > field in PMSI Tunnel Attribute of the corresponding > > I/S-PMSI A-D or Leaf A-D route." > o Does this description cover all the types? If not, then cover all the > types unless there is a good reason to focus only on the above types. > o I/S-PMSI: unexplained notation. Fixed. > > IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType > Please indicate that the first column gives the size I have updated the table as follows. Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType IPv4 IPv6 (tunneling technology) -------------------------------------------------- 0 0 noTunnelId (No tunnel information present) 12 24 rsvpP2mp (RSVP-TE P2MP LSP) 17 29 ldpP2mp (mLDP P2MP LSP) 8 32 pimSsm (PIM-SSM Tree) > > 8/32 pimAsm > > 8/32 pimSsm > > 8/32 pimBidir > > 4/16 ingressReplication > > > For UDP-based S-PMSI signaling for PIM-MVPN, the first > > 8 or 32 octets of this attribute are filled with > > the provider tunnel (source, group) IPv4/IPv6 addresses. > > 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." > > A more generous description of the AttributeID would be good. All the > cases must be covered. Section 5 of RFC 6514 does it nicely. A simple > summary would be very nice. Fixed. I have summarized Section 5 of RFC 6514 here. > 4.15 > l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE > > SYNTAX RowPointer > > DESCRIPTION > > "If the tunnel exists in some MIB table, e.g. mplsTunnelTable > > [RFC3812], this is the row pointer to it. Otherwise, the > > pointer is null." > I am having problems understanding this. Will help if you can give > a use case of how this will be used. As of now the intent is unclear. > A RowPointer cannot be pointing to "some MIB table". It must be > pointer to a specific row in a specific table. If this is a pointer to > a row in the mplsTunnelTable spell it out clearly and unambiguously. I have changed DESCRIPTION as follows. "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId may be represented as an entry in other table, e.g, mplsTunnelTable [RFC3812]. If there is such entry, this object will point to the row pertaining to the entry. Otherwise, the pointer is null." > 5.0 > >5. Security Considerations > TBD I have rewritten this part according to the guideline described in RFC4181 Sec.3.4. > 6.0 > >6. IANA Considerations > > > IANA is requested to root MIB objects in the MIB module contained in > > this document under the mib-2 subtree. > > Please Note: > To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to > put the definitions in a separate MIB module. That would mean a > separate branch in the mib-2 subtree. Then the maintenance of the > TC can be carried out by some entity ( IANA or, some WG or, whoever is > responsible for maintaining the TC) independent of other MIB objects. > If that is the intent you will need to define 2 mib modules and you will > need to request 2 branches in the mib-2 subtree- one for the module > containing the L2L3VpnMcastProviderTunnelType TC and another for the > module containing the l2L3VpnMcastPmsiTunnelAttributeTable. Now, this document defines following two MIB modules: - the module containing the L2L3VpnMcastProviderTunnelType TC - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. -- tsuno 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni : > Dear Tsunoda, >> I will submit the next version within three days. >> The next versionbwill address all of remained your >> comments. > Great! Looking forward to the revised draft. > > Glenn > > On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >> >> Dear Glenn, >> >> I am sorry I kept you waiting so long for the revised version, I have >> been side tracked by other things. >> I will submit the next version within three days. The next version >> will address all of remained your comments. >> The summary of remained TODOs is shown below. Please wait a little more >> time. >> ------------- >> 1. Add general explanation about MVPN, multicast in VPLS >> Define and explain some technical terms, such as PIM-MVPN, >> UDP-based S-PMSI etc. >> >> 2. Revise summary of the MIB module >> >> 3. Revise MIB definition >> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >> cover all cases. >> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >> >> 4. Split the MIB module into two separate modules. >> >> 5. Revise security considertations >> ------------- >> >> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >> >> Best regards, >> >> -- tsuno >> >> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >>> >>> Hi Tsunoda, >>>> >>>> I have started to volunteer to help to move this document forward. >>> >>> Great! >>>> >>>> I posted a new revision and addressed all editorial things in >>>> that revision. >>> >>> Got this. Looks good. >>>> >>>> Please give me some more time for revising other parts, >>> >>> No problems. Will be looking forward to the revised document. >>> >>> Glenn >>> >>> >>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>> >>>> >>>> Dear Glenn, >>>> >>>> Thanks for your careful review and detailed comments/suggestions. >>>> I have started to volunteer to help to move this document forward. >>>> I posted a new revision and addressed all editorial things in that >>>> revision. >>>> Please give me some more time for revising other parts, >>>> in order to be familiar with the context of the original and related >>>> documents. >>>> >>>> URL: >>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.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-05 >>>> Diff: >>>> >>>> >>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>> >>>> Please see some notes below. >>>> >>>>> 0. Abstract. >>>>> 0.1. >>>>>> >>>>>> >>>>>> it describes common managed objects used to configure >>>>> >>>>> >>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>> >>>>> There are no writable MOs in this MIB. So it does not look >>>>> as though this MIB will be used for configuration directly. >>>>> The use case scenario for monitoring is not clear, either. >>>>> It appears that the MIB module(s) in this document will be >>>>> used by other modules which are designed for monitoring and/ >>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>> wording. >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 1. Introduction >>>>> >>>>> 1.1 >>>>> Would be very nice if a short explanations of MVPN and >>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>> aspects. >>>> >>>> >>>> >>>> TBD. Please give me some more time to revise. >>>> >>>>> 1.2 >>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 1.3 >>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 1.4 .... there are 2 types of PMSIs .. >>>>> >>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>> >>>>> >>>>> >>>>> please make these explanations more gentle(complete) to the reader. >>>>> Also, give the references where these terms are defined. >>>> >>>> >>>> >>>> TBD. Please give me some more time to revise. >>>> >>>>> 3. Summary of MIB Module >>>>> 3.1 >>>>>> >>>>>> >>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>> >>>>> >>>>> Typo: I/S-PMSI, (see 3.3 below). >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 3.2 some more text like the following will be good. >>>>> L2L3-VPN-MCAST-MIB contains >>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>>>> an enumeration of the provider tunnel types and, >>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>>>> composed of multiple attributes that depend on the tunnel type >>>>> and >>>>> uniquely identify a tunnel. This table will be used to ... >>>>> monitor >>>>> the tunnels supported by the system at a given point of time (?) >>>>> It may also be used in conjunction with XXXX-mib to obtain the >>>>> other details of a tunnel by following the row pointer of the >>>>> corresponding tunnel's row in this table. >>>>> [ Please treat the above as a template and modify the text as >>>>> appropriate ..] >>>> >>>> >>>> >>>> TBD. Please give me some more time to revise this point. >>>> >>>>> 3.3 Since this will become a standard document, please take care of >>>>> definitions and notations used in the document. >>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>> term/notation, define it before use. >>>> >>>> >>>> >>>> TBD. Please give me some more time to revise this point. >>>> >>>>> 4. Definitions >>>>> >>>>>> IMPORTS >>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>> >>>>> >>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>> experimental. >>>>> It is good practice to keep the draft in the as "close to final >>>>> form" >>>>> as possible. (See below) >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 4.2 >>>>>> >>>>>> >>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>> >>>>> >>>>> Please update this date. >>>> >>>> >>>> >>>> Updated. >>>> >>>>> 4.3 >>>>>> >>>>>> >>>>>> DESCRIPTION >>>>>> "This MIB contains common managed object definitions for >>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>> >>>>> >>>>> Would be good if you could rearrange the text. Something like >>>>> "This MIB module will be used for managing multicast in Layer 2 >>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>> Or, even better >>>>> "This MIB module will be used by other MIB modules designed for >>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>> [RFC6513], [RFC6514] >>>>> Or, a combination of both, depending on the envisaged use case >>>>> scenarios. >>>> >>>> >>>> >>>> Rearranged the text along with your comment. >>>> >>>>> 4.4 >>>>>> >>>>>> >>>>>> ::= { experimental 999 } >>>>> >>>>> >>>>> Please >>>>> o Replace "experimental" by the branch where this mib module will >>>>> be anchored; that is a decision that the WG will take, >>>>> probably. >>>>> o Import the branch in the IMPORTS statement >>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>> subtree >>>>> is requested. In that case this must be >>>>> ::= { mib-2 XXX } >>>>> ] >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 4.5 >>>>>> >>>>>> >>>>>> -- Please also remove the ", experimental" text from earlier >>>>>> -- IMPORTS section. >>>>> >>>>> >>>>> Remove these instructions. >>>> >>>> >>>> >>>> Removed. >>>> >>>>> 4.5.2 >>>>>> >>>>>> >>>>>> -- Texual convention >>>>> >>>>> >>>>> Typo: -- Textual convention >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 4.6 >>>>>> >>>>>> >>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>> DESCRIPTION >>>>>> "Types of provider tunnels used for multicast in >>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>> in future RFCs, and those will be allowed as >>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>> >>>>> >>>>> The part >>>>>> >>>>>> >>>>>> Additional types may be defined >>>>>> in future RFCs, and those will be allowed as >>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>> >>>>> >>>>> may be deleted. >>>> >>>> >>>> >>>> Deleted. >>>> >>>>> 4.7 >>>>>> >>>>>> >>>>>> -- Top level components of this MIB. >>>>>> -- tables, scalars, conformance information >>>>>> >>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>> >>>>> >>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>>>> >>>>>> >>>>>> >>>>>> -- Table of PMSI Tunnel Attributes >>>>>> >>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>> >>>>> >>>>> >>>>> should be >>>>> >>>>> -- Top level components of this MIB. >>>>> >>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 >>>>> } >>>>> >>>>> -- tables, scalars, conformance information >>>>> -- Table of PMSI Tunnel Attributes >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 4.8 >>>>>> >>>>>> >>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>> MAX-ACCESS not-accessible >>>>>> STATUS current >>>>>> DESCRIPTION >>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>> >>>>> >>>>> >>>>> It would seem that each row in this table is an index for a PTA >>>>> and may contain pointers to rows in tables of other MIB modules >>>>> which may contain more details for the PTA. Is that correct? >>>>> Please reword the DESCRIPTION acordingly. >>>>> Also see comments in 4.15 >>>> >>>> >>>> >>>> TBD. I need some more time to understand the original context. >>>> >>>>> 4.9 >>>>>> >>>>>> >>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>> "An entry in this table corresponds to a PTA >>>>>> that is advertised/received on this router. >>>>> >>>>> >>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>>>> so "entry in this table" does not fit in well. >>>>> A rewording like >>>>> "A conceptual row corresponding to a PTA >>>>> that is advertised/received on this router. >>>>> .... >>>>> would be better. >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 4.10 >>>>>> >>>>>> >>>>>> 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. >>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>> they're derived from the S-PMSI Join Message. >>>>> >>>>> >>>>> >>>>>> Note that BGP-based signaling may be used for >>>>>> PIM-MVPN as well." >>>>> >>>>> >>>>> Is the signaling mechanism important here? If it isn't then the >>>>> above part of the description is redundant. >>>> >>>> >>>> >>>> Removed the above part. >>>> >>>>> 4.10-2 >>>>> PIM-MVPN appears for the first time. >>>> >>>> >>>> >>>> Defined the notation of PIM-MVPM as follows >>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>> However, I think that some descriptions may be required for this >>>> somewhere in this document. That is TBD. >>>> >>>>> 4.10-3 >>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>> Somewhere earlier it should be made clear that UDP too may be used >>>>> in signaling. >>>> >>>> >>>> >>>> TBD. >>>> >>>>> 4.11 >>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>> >>>>>> >>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>> >>>>> >>>>> "this" is unclear. >>>>> Something like "the value of this object is 0" will be better. >>>> >>>> >>>> >>>> Fixed. >>>> >>>>>> More bits may be defined in the future and >>>>>> they will be registered in IANA Registry xxxx." >>>>> >>>>> >>>>> This part is probably redundant. >>>> >>>> >>>> >>>> Removed. >>>> >>>>> 4.12 >>>>>> >>>>>> >>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>> -- and remove this note. >>>>> >>>>> >>>>> >>>>> Look at the comments in 6.0 >>>> >>>> >>>> >>>> The above description ("IANA Registry xxxx.") was removed, >>>> thus this part was also removed. >>>> >>>>> 4.13 >>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>> >>>>>> >>>>>> DESCRIPTION >>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>> >>>>> >>>>> o Does this description cover all the types? If not, then cover all >>>>> the >>>>> types unless there is a good reason to focus only on the above >>>>> types. >>>>> o I/S-PMSI: unexplained notation. >>>> >>>> >>>> >>>> TBD. Please give me some more time to address this point. >>>> >>>>> 4.14 >>>>> >>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>> >>>>>> >>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>> >>>>> >>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>> included. >>>> >>>> >>>> >>>> Fixed. >>>> >>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>> >>>>> >>>>> Please indicate that the first column gives the size >>>> >>>> >>>> >>>> I made a change as follows. >>>> >>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>> (IPv4/IPv6) >>>> -------------------------------------------------- >>>> (snip) >>>> 8/32 pimAsm >>>> (snip) >>>> >>>> Is this OK? >>>> >>>>>> 8/32 pimAsm >>>>>> 8/32 pimSsm >>>>>> 8/32 pimBidir >>>>>> 4/16 ingressReplication >>>>> >>>>> >>>>> >>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>> 8 or 32 octets of this attribute are filled with >>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>> 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." >>>>> >>>>> >>>>> >>>>> A more generous description of the AttributeID would be good. All the >>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>>>> summary would be very nice. >>>> >>>> >>>> >>>> TBD. Please give me some more time to revise this point. >>>> >>>>> 4.15 >>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>> >>>>>> >>>>>> SYNTAX RowPointer >>>>>> DESCRIPTION >>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>> pointer is null." >>>>> >>>>> >>>>> I am having problems understanding this. Will help if you can give >>>>> a use case of how this will be used. As of now the intent is unclear. >>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>> pointer to a specific row in a specific table. If this is a pointer >>>>> to >>>>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >>>> >>>> >>>> >>>> TBD. I will need some more time to understand the original context. >>>> >>>>> 4.16 >>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>> DESCRIPTION >>>>>> >>>>>> >>>>>> "If the tunnel has a corresponding interface, this is the >>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>> >>>>> >>>>> This description is better. Would be even better with >>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>> this object will point to the row pertaining to the entry >>>>> ..... >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 4.17 >>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>> >>>>>> >>>>>> DESCRIPTION >>>>>> "Support of these object is not required." >>>>> >>>>> >>>>> Support of these objects is not required. >>>> >>>> >>>> >>>> Fixed. >>>> >>>>> 5.0 >>>>>> >>>>>> >>>>>> 5. Security Considerations >>>>> >>>>> >>>>> TBD >>>> >>>> >>>> >>>> Still TBD. >>>> >>>>> 6.0 >>>>>> >>>>>> >>>>>> 6. IANA Considerations >>>>> >>>>> >>>>> >>>>>> IANA is requested to root MIB objects in the MIB module contained in >>>>>> this document under the mib-2 subtree. >>>>> >>>>> >>>>> >>>>> Please Note: >>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need >>>>> to >>>>> put the definitions in a separate MIB module. That would mean a >>>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>>> TC can be carried out by some entity ( IANA or, some WG or, whoever >>>>> is >>>>> responsible for maintaining the TC) independent of other MIB >>>>> objects. >>>>> If that is the intent you will need to define 2 mib modules and you >>>>> will >>>>> need to request 2 branches in the mib-2 subtree- one for the module >>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>> >>>> >>>> >>>> TBD. I will address this point in the next revision. >>>> >>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>>> >>>>> >>>>> 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 ; Benoit Claise >>>>>>> ; EXT - thomas.morin@orange.com >>>>>>> >>>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>>> Vigoureux >>>>>>> ; 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 >>>>>>>>> ::= { XXX } >>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>>>>>> note >>>>>>>>> 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 ; EXT - >>>>>>>>> thomas.morin@orange.com >>>>>>>>> >>>>>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>>>>> >>>>>>> >>>>>>> >>>>>>> Martin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>>>>> >>>>>>>>> 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 >>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> BESS mailing list >>>>> BESS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bess >>>>> >>> >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > From nobody Wed Feb 22 05:02:11 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EB0129854; Wed, 22 Feb 2017 05:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 29_ODcmT0AtI; Wed, 22 Feb 2017 05:02:06 -0800 (PST) Received: from niseko.cysol.co.jp (niseko.cysol.co.jp [210.233.3.236]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D48D129853; Wed, 22 Feb 2017 05:02:06 -0800 (PST) Received: from [192.168.0.94] (cysvpn07.priv.cysol.co.jp [192.168.0.94]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v1MD1ukZ073825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Feb 2017 22:01:56 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda 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> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> From: Glenn Mansfield Keeni Message-ID: <958e2f1b-e66e-f376-9a13-035f85af4b27@cysols.com> Date: Wed, 22 Feb 2017 22:01:51 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey \(Zhaohui\) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Subject: Re: [MIB-DOCTORS] [bess] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-04.txt X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 13:02:11 -0000 Dear Tsunoda, Got this. It is looking good. I will do a complete review and hope to get back on this by the end of next week. Glenn On 2017/02/21 16:50, Hiroshi Tsunoda wrote: > Dear Glenn and BESS WG, > > I posted a new revision as follows. > I think that I have addressed all of Glenn's comments in this revision. > > In this revision, I have tried to add more detailed explanation > throughout the document. > Please review and let me know if there are any misunderstanding from > technical view points. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-06.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-06 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-06 > > Please see some notes below. > >> 1. Introduction >> >> 1.1 >> Would be very nice if a short explanations of MVPN and >> L2 VPN Multicast were given. With emphasis on the operational >> aspects. > > I have updated Introduction. I hope this update fulfills your requirements. > >> 1.4 .... there are 2 types of PMSIs .. >> >>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >> >> please make these explanations more gentle(complete) to the reader. >> Also, give the references where these terms are defined. > > More gentle explanation and references were added in Terminology > section (Sec.1.1). > >> 3.2 some more text like the following will be good. >> L2L3-VPN-MCAST-MIB contains >> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >> an enumeration of the provider tunnel types and, >> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >> composed of multiple attributes that depend on the tunnel type and >> uniquely identify a tunnel. This table will be used to ... monitor >> the tunnels supported by the system at a given point of time (?) >> It may also be used in conjunction with XXXX-mib to obtain the >> other details of a tunnel by following the row pointer of the >> corresponding tunnel's row in this table. >> [ Please treat the above as a template and modify the text as >> appropriate ..] > > Fixed in this revision. Please look at Sec. 3 Summary of MIB Module. > >> 3.3 Since this will become a standard document, please take care of >> definitions and notations used in the document. >> The notation I/S-PMSI is not defined. If you must use a new >> term/notation, define it before use. > > The notation I/S-PMSI is defined in Sec.1.1 now. > >> 4.8 >>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "This table is for PMSI Tunnel Attributes (PTAs) >>> advertised/received in I/S-PSMI Auto-Discovery routes. >>> The entries may be referred to by I-PMSI or S-PMSI table >>> entries defined in other MIBs, e.g. mvpnMIB in >>> [I-D.ietf-bess-mvpn-mib]." >> >> It would seem that each row in this table is an index for a PTA >> and may contain pointers to rows in tables of other MIB modules >> which may contain more details for the PTA. Is that correct? >> Please reword the DESCRIPTION acordingly. >> Also see comments in 4.15 > > I have changed DESCRIPTION as follows. > > "An entry of this table corresponds with a > PMSI Tunnel attribute and is created by a PE router > that advertises and receives the attribute. > The entry in the table will be referred by other MIB modules > which are designed for monitoring and/or configuring > both L2 and L3 VPN that support multicast." > > >> 4.10-3 >> the phrase UDP-based S-PMSI appears here for the first time. >> Somewhere earlier it should be made clear that UDP too may be used >> in signaling. > > In Introduction, I have explained that BGP and UDP are used in signaling. > >> 4.13 >> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>> DESCRIPTION >>> "As defined for L2L3VpnMcastProviderTunnelType. >>> For UDP-based S-PMSI signaling for PIM-MVPN, >>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>> field in PMSI Tunnel Attribute of the corresponding >>> I/S-PMSI A-D or Leaf A-D route." >> o Does this description cover all the types? If not, then cover all the >> types unless there is a good reason to focus only on the above types. >> o I/S-PMSI: unexplained notation. > > Fixed. > >>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >> Please indicate that the first column gives the size > > I have updated the table as follows. > > Size (in octets) l2L3VpnMcastPmsiTunnelAttributeType > IPv4 IPv6 (tunneling technology) > -------------------------------------------------- > 0 0 noTunnelId (No tunnel information present) > 12 24 rsvpP2mp (RSVP-TE P2MP LSP) > 17 29 ldpP2mp (mLDP P2MP LSP) > 8 32 pimSsm (PIM-SSM Tree) > >>> 8/32 pimAsm >>> 8/32 pimSsm >>> 8/32 pimBidir >>> 4/16 ingressReplication >> >>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>> 8 or 32 octets of this attribute are filled with >>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>> 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." >> >> A more generous description of the AttributeID would be good. All the >> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >> summary would be very nice. > > Fixed. I have summarized Section 5 of RFC 6514 here. > >> 4.15 >> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>> SYNTAX RowPointer >>> DESCRIPTION >>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>> [RFC3812], this is the row pointer to it. Otherwise, the >>> pointer is null." >> I am having problems understanding this. Will help if you can give >> a use case of how this will be used. As of now the intent is unclear. >> A RowPointer cannot be pointing to "some MIB table". It must be >> pointer to a specific row in a specific table. If this is a pointer to >> a row in the mplsTunnelTable spell it out clearly and unambiguously. > > I have changed DESCRIPTION as follows. > > "The tunnel identified by l2L3VpnMcastPmsiTunnelAttributeId > may be represented as an entry in other table, e.g, > mplsTunnelTable [RFC3812]. If there is such entry, > this object will point to the row pertaining to the entry. > Otherwise, the pointer is null." > >> 5.0 >>> 5. Security Considerations >> TBD > > I have rewritten this part according to the guideline described in > RFC4181 Sec.3.4. > >> 6.0 >>> 6. IANA Considerations >> >>> IANA is requested to root MIB objects in the MIB module contained in >>> this document under the mib-2 subtree. >> >> Please Note: >> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need to >> put the definitions in a separate MIB module. That would mean a >> separate branch in the mib-2 subtree. Then the maintenance of the >> TC can be carried out by some entity ( IANA or, some WG or, whoever is >> responsible for maintaining the TC) independent of other MIB objects. >> If that is the intent you will need to define 2 mib modules and you will >> need to request 2 branches in the mib-2 subtree- one for the module >> containing the L2L3VpnMcastProviderTunnelType TC and another for the >> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. > > Now, this document defines following two MIB modules: > - the module containing the L2L3VpnMcastProviderTunnelType TC > - the module containing the l2L3VpnMcastPmsiTunnelAttributeTable. > > -- tsuno > > 2017-02-19 10:30 GMT+09:00 Glenn Mansfield Keeni : >> Dear Tsunoda, >>> I will submit the next version within three days. >>> The next versionbwill address all of remained your >>> comments. >> Great! Looking forward to the revised draft. >> >> Glenn >> >> On 2017/02/18 16:30, Hiroshi Tsunoda wrote: >>> >>> Dear Glenn, >>> >>> I am sorry I kept you waiting so long for the revised version, I have >>> been side tracked by other things. >>> I will submit the next version within three days. The next version >>> will address all of remained your comments. >>> The summary of remained TODOs is shown below. Please wait a little more >>> time. >>> ------------- >>> 1. Add general explanation about MVPN, multicast in VPLS >>> Define and explain some technical terms, such as PIM-MVPN, >>> UDP-based S-PMSI etc. >>> >>> 2. Revise summary of the MIB module >>> >>> 3. Revise MIB definition >>> a. Fix the description of l2L3VpnMcastPmsiTunnelAttributeTable >>> b. Fix the description of l2L3VpnMcastPmsiTunnelAttributeType to >>> cover all cases. >>> c. Fix the description of l2L3VpnMcastPmsiTunnelAttributeId >>> d. Fix the description of l2L3VpnMcastPmsiTunnelPointer >>> >>> 4. Split the MIB module into two separate modules. >>> >>> 5. Revise security considertations >>> ------------- >>> >>> P.S. Update of mvpn-mib-02 will be submitted by the end of this month. >>> >>> Best regards, >>> >>> -- tsuno >>> >>> 2016-12-03 21:19 GMT+09:00 Glenn Mansfield Keeni : >>>> >>>> Hi Tsunoda, >>>>> >>>>> I have started to volunteer to help to move this document forward. >>>> >>>> Great! >>>>> >>>>> I posted a new revision and addressed all editorial things in >>>>> that revision. >>>> >>>> Got this. Looks good. >>>>> >>>>> Please give me some more time for revising other parts, >>>> >>>> No problems. Will be looking forward to the revised document. >>>> >>>> Glenn >>>> >>>> >>>> On 2016/12/02 12:12, Hiroshi Tsunoda wrote: >>>>> >>>>> >>>>> Dear Glenn, >>>>> >>>>> Thanks for your careful review and detailed comments/suggestions. >>>>> I have started to volunteer to help to move this document forward. >>>>> I posted a new revision and addressed all editorial things in that >>>>> revision. >>>>> Please give me some more time for revising other parts, >>>>> in order to be familiar with the context of the original and related >>>>> documents. >>>>> >>>>> URL: >>>>> https://www.ietf.org/id/draft-ietf-bess-l2l3-vpn-mcast-mib-05.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-05 >>>>> Diff: >>>>> >>>>> >>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt >>>>> >>>>> Please see some notes below. >>>>> >>>>>> 0. Abstract. >>>>>> 0.1. >>>>>>> >>>>>>> >>>>>>> it describes common managed objects used to configure >>>>>> >>>>>> >>>>>> and/or monitor both L2 and L3 VPN Multicast. >>>>>> >>>>>> There are no writable MOs in this MIB. So it does not look >>>>>> as though this MIB will be used for configuration directly. >>>>>> The use case scenario for monitoring is not clear, either. >>>>>> It appears that the MIB module(s) in this document will be >>>>>> used by other modules which are designed for monitoring and/ >>>>>> or configuring L2 and L3 VPN Multicast. Please re-examine the >>>>>> wording. >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 1. Introduction >>>>>> >>>>>> 1.1 >>>>>> Would be very nice if a short explanations of MVPN and >>>>>> L2 VPN Multicast were given. With emphasis on the operational >>>>>> aspects. >>>>> >>>>> >>>>> >>>>> TBD. Please give me some more time to revise. >>>>> >>>>>> 1.2 >>>>>> s/referred to MVPN and L2 VPN Multicast respectively/ >>>>>> referred to as MVPN and L2 VPN Multicast,respectively/ >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 1.3 >>>>>> s/MVPN [RFC6513] [RFC6514]/MVPN [RFC6513],[RFC6514]/. >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 1.4 .... there are 2 types of PMSIs .. >>>>>> >>>>>>> o I-PMSI: Inclusive PMSI - to all PEs in the same VPN. >>>>>>> o S-PMSI: Selective PMSI - to some of the PEs in the same VPN. >>>>>> >>>>>> >>>>>> >>>>>> please make these explanations more gentle(complete) to the reader. >>>>>> Also, give the references where these terms are defined. >>>>> >>>>> >>>>> >>>>> TBD. Please give me some more time to revise. >>>>> >>>>>> 3. Summary of MIB Module >>>>>> 3.1 >>>>>>> >>>>>>> >>>>>>> Attributes (PTAs) advertised/received in I/S-PSMI Auto-Discovery >>>>>> >>>>>> >>>>>> Typo: I/S-PMSI, (see 3.3 below). >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 3.2 some more text like the following will be good. >>>>>> L2L3-VPN-MCAST-MIB contains >>>>>> o a Textual Convention L2L3VpnMcastProviderTunnelType that provides >>>>>> an enumeration of the provider tunnel types and, >>>>>> o a table l2L3VpnMcastPmsiTunnelAttributeTable. The table index is >>>>>> composed of multiple attributes that depend on the tunnel type >>>>>> and >>>>>> uniquely identify a tunnel. This table will be used to ... >>>>>> monitor >>>>>> the tunnels supported by the system at a given point of time (?) >>>>>> It may also be used in conjunction with XXXX-mib to obtain the >>>>>> other details of a tunnel by following the row pointer of the >>>>>> corresponding tunnel's row in this table. >>>>>> [ Please treat the above as a template and modify the text as >>>>>> appropriate ..] >>>>> >>>>> >>>>> >>>>> TBD. Please give me some more time to revise this point. >>>>> >>>>>> 3.3 Since this will become a standard document, please take care of >>>>>> definitions and notations used in the document. >>>>>> The notation I/S-PMSI is not defined. If you must use a new >>>>>> term/notation, define it before use. >>>>> >>>>> >>>>> >>>>> TBD. Please give me some more time to revise this point. >>>>> >>>>>> 4. Definitions >>>>>> >>>>>>> IMPORTS >>>>>>> MODULE-IDENTITY, OBJECT-TYPE, experimental >>>>>> >>>>>> >>>>>> 4.1 Since this is not a Experimental MIB do not import use >>>>>> experimental. >>>>>> It is good practice to keep the draft in the as "close to final >>>>>> form" >>>>>> as possible. (See below) >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 4.2 >>>>>>> >>>>>>> >>>>>>> LAST-UPDATED "201310141200Z" -- October 14, 2013 >>>>>> >>>>>> >>>>>> Please update this date. >>>>> >>>>> >>>>> >>>>> Updated. >>>>> >>>>>> 4.3 >>>>>>> >>>>>>> >>>>>>> DESCRIPTION >>>>>>> "This MIB contains common managed object definitions for >>>>>>> multicast in Layer 2 and Layer 3 VPNs, defined by >>>>>>> [RFC7117] and [RFC6513] [RFC6514] respectively. >>>>>> >>>>>> >>>>>> Would be good if you could rearrange the text. Something like >>>>>> "This MIB module will be used for managing multicast in Layer 2 >>>>>> VPNs [RFC7117] and Layer 3 VPNs [RFC6513], [RFC6514]. >>>>>> Or, even better >>>>>> "This MIB module will be used by other MIB modules designed for >>>>>> managing multicast in Layer 2 VPNs [RFC7117] and Layer 3 VPNs >>>>>> [RFC6513], [RFC6514] >>>>>> Or, a combination of both, depending on the envisaged use case >>>>>> scenarios. >>>>> >>>>> >>>>> >>>>> Rearranged the text along with your comment. >>>>> >>>>>> 4.4 >>>>>>> >>>>>>> >>>>>>> ::= { experimental 999 } >>>>>> >>>>>> >>>>>> Please >>>>>> o Replace "experimental" by the branch where this mib module will >>>>>> be anchored; that is a decision that the WG will take, >>>>>> probably. >>>>>> o Import the branch in the IMPORTS statement >>>>>> [ In the IANA Considerations section a branch in the mib-2 >>>>>> subtree >>>>>> is requested. In that case this must be >>>>>> ::= { mib-2 XXX } >>>>>> ] >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 4.5 >>>>>>> >>>>>>> >>>>>>> -- Please also remove the ", experimental" text from earlier >>>>>>> -- IMPORTS section. >>>>>> >>>>>> >>>>>> Remove these instructions. >>>>> >>>>> >>>>> >>>>> Removed. >>>>> >>>>>> 4.5.2 >>>>>>> >>>>>>> >>>>>>> -- Texual convention >>>>>> >>>>>> >>>>>> Typo: -- Textual convention >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 4.6 >>>>>>> >>>>>>> >>>>>>> L2L3VpnMcastProviderTunnelType ::= TEXTUAL-CONVENTION >>>>>>> DESCRIPTION >>>>>>> "Types of provider tunnels used for multicast in >>>>>>> BGP/MPLS L2 or L3 VPN. Additional types may be defined >>>>>>> in future RFCs, and those will be allowed as >>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>> >>>>>> >>>>>> The part >>>>>>> >>>>>>> >>>>>>> Additional types may be defined >>>>>>> in future RFCs, and those will be allowed as >>>>>>> valid types for L2L3VpnMcastProviderTunnelType." >>>>>> >>>>>> >>>>>> may be deleted. >>>>> >>>>> >>>>> >>>>> Deleted. >>>>> >>>>>> 4.7 >>>>>>> >>>>>>> >>>>>>> -- Top level components of this MIB. >>>>>>> -- tables, scalars, conformance information >>>>>>> >>>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>> >>>>>> >>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 } >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- Table of PMSI Tunnel Attributes >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>> >>>>>> >>>>>> >>>>>> should be >>>>>> >>>>>> -- Top level components of this MIB. >>>>>> >>>>>> l2L3VpnMcastObjects OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 1 } >>>>>> l2L3VpnMcastConformance OBJECT IDENTIFIER ::= { l2L3VpnMcastMIB 2 } >>>>>> l2L3VpnMcastStates OBJECT IDENTIFIER ::= { l2L3VpnMcastObjects 1 >>>>>> } >>>>>> >>>>>> -- tables, scalars, conformance information >>>>>> -- Table of PMSI Tunnel Attributes >>>>>> >>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 4.8 >>>>>>> >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeTable OBJECT-TYPE >>>>>>> SYNTAX SEQUENCE OF L2L3VpnMcastPmsiTunnelAttributeEntry >>>>>>> MAX-ACCESS not-accessible >>>>>>> STATUS current >>>>>>> DESCRIPTION >>>>>>> "This table is for PMSI Tunnel Attributes (PTAs) >>>>>>> advertised/received in I/S-PSMI Auto-Discovery routes. >>>>>>> The entries may be referred to by I-PMSI or S-PMSI table >>>>>>> entries defined in other MIBs, e.g. mvpnMIB in >>>>>>> [I-D.ietf-bess-mvpn-mib]." >>>>>> >>>>>> >>>>>> >>>>>> It would seem that each row in this table is an index for a PTA >>>>>> and may contain pointers to rows in tables of other MIB modules >>>>>> which may contain more details for the PTA. Is that correct? >>>>>> Please reword the DESCRIPTION acordingly. >>>>>> Also see comments in 4.15 >>>>> >>>>> >>>>> >>>>> TBD. I need some more time to understand the original context. >>>>> >>>>>> 4.9 >>>>>>> >>>>>>> >>>>>>> l2L3VpnMcastPmsiTunnelAttributeEntry OBJECT-TYPE >>>>>>> "An entry in this table corresponds to a PTA >>>>>>> that is advertised/received on this router. >>>>>> >>>>>> >>>>>> We are in the description of "l2L3VpnMcastPmsiTunnelAttributeEntry" >>>>>> so "entry in this table" does not fit in well. >>>>>> A rewording like >>>>>> "A conceptual row corresponding to a PTA >>>>>> that is advertised/received on this router. >>>>>> .... >>>>>> would be better. >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 4.10 >>>>>>> >>>>>>> >>>>>>> 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. >>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>> they're derived from the S-PMSI Join Message. >>>>>> >>>>>> >>>>>> >>>>>>> Note that BGP-based signaling may be used for >>>>>>> PIM-MVPN as well." >>>>>> >>>>>> >>>>>> Is the signaling mechanism important here? If it isn't then the >>>>>> above part of the description is redundant. >>>>> >>>>> >>>>> >>>>> Removed the above part. >>>>> >>>>>> 4.10-2 >>>>>> PIM-MVPN appears for the first time. >>>>> >>>>> >>>>> >>>>> Defined the notation of PIM-MVPM as follows >>>>> Protocol Independent Multicast - MVPN (PIM-MVPN) >>>>> However, I think that some descriptions may be required for this >>>>> somewhere in this document. That is TBD. >>>>> >>>>>> 4.10-3 >>>>>> the phrase UDP-based S-PMSI appears here for the first time. >>>>>> Somewhere earlier it should be made clear that UDP too may be used >>>>>> in signaling. >>>>> >>>>> >>>>> >>>>> TBD. >>>>> >>>>>> 4.11 >>>>>> l2L3VpnMcastPmsiTunnelAttributeFlags OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> "For UDP-based S-PMSI signaling for PIM-MVPN, this is 0. >>>>>> >>>>>> >>>>>> "this" is unclear. >>>>>> Something like "the value of this object is 0" will be better. >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>>> More bits may be defined in the future and >>>>>>> they will be registered in IANA Registry xxxx." >>>>>> >>>>>> >>>>>> This part is probably redundant. >>>>> >>>>> >>>>> >>>>> Removed. >>>>> >>>>>> 4.12 >>>>>>> >>>>>>> >>>>>>> -- RFC Ed. replace xxxx with the actual registry name >>>>>>> -- that is being created via [I-D.ietf-bess-mvpn-mib] >>>>>>> -- and remove this note. >>>>>> >>>>>> >>>>>> >>>>>> Look at the comments in 6.0 >>>>> >>>>> >>>>> >>>>> The above description ("IANA Registry xxxx.") was removed, >>>>> thus this part was also removed. >>>>> >>>>>> 4.13 >>>>>> l2L3VpnMcastPmsiTunnelAttributeType OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> DESCRIPTION >>>>>>> "As defined for L2L3VpnMcastProviderTunnelType. >>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, >>>>>>> this is pim-asm (3), pim-ssm (4), or pim-bidir (5). >>>>>>> For BGP-based I/S-PMSI signaling, this is the Tunnel Type >>>>>>> field in PMSI Tunnel Attribute of the corresponding >>>>>>> I/S-PMSI A-D or Leaf A-D route." >>>>>> >>>>>> >>>>>> o Does this description cover all the types? If not, then cover all >>>>>> the >>>>>> types unless there is a good reason to focus only on the above >>>>>> types. >>>>>> o I/S-PMSI: unexplained notation. >>>>> >>>>> >>>>> >>>>> TBD. Please give me some more time to address this point. >>>>> >>>>>> 4.14 >>>>>> >>>>>> l2L3VpnMcastPmsiTunnelAttributeId OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> SYNTAX OCTET STRING ( SIZE (0|4|8|12|17|24|29) ) >>>>>> >>>>>> >>>>>> It appears that you also allow sizes "16" and "32"; these must be >>>>>> included. >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>>> IPv4/IPv6 l2L3VpnMcastPmsiTunnelAttributeType >>>>>> >>>>>> >>>>>> Please indicate that the first column gives the size >>>>> >>>>> >>>>> >>>>> I made a change as follows. >>>>> >>>>> Size l2L3VpnMcastPmsiTunnelAttributeType >>>>> (IPv4/IPv6) >>>>> -------------------------------------------------- >>>>> (snip) >>>>> 8/32 pimAsm >>>>> (snip) >>>>> >>>>> Is this OK? >>>>> >>>>>>> 8/32 pimAsm >>>>>>> 8/32 pimSsm >>>>>>> 8/32 pimBidir >>>>>>> 4/16 ingressReplication >>>>>> >>>>>> >>>>>> >>>>>>> For UDP-based S-PMSI signaling for PIM-MVPN, the first >>>>>>> 8 or 32 octets of this attribute are filled with >>>>>>> the provider tunnel (source, group) IPv4/IPv6 addresses. >>>>>>> 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." >>>>>> >>>>>> >>>>>> >>>>>> A more generous description of the AttributeID would be good. All the >>>>>> cases must be covered. Section 5 of RFC 6514 does it nicely. A simple >>>>>> summary would be very nice. >>>>> >>>>> >>>>> >>>>> TBD. Please give me some more time to revise this point. >>>>> >>>>>> 4.15 >>>>>> l2L3VpnMcastPmsiTunnelPointer OBJECT-TYPE >>>>>>> >>>>>>> >>>>>>> SYNTAX RowPointer >>>>>>> DESCRIPTION >>>>>>> "If the tunnel exists in some MIB table, e.g. mplsTunnelTable >>>>>>> [RFC3812], this is the row pointer to it. Otherwise, the >>>>>>> pointer is null." >>>>>> >>>>>> >>>>>> I am having problems understanding this. Will help if you can give >>>>>> a use case of how this will be used. As of now the intent is unclear. >>>>>> A RowPointer cannot be pointing to "some MIB table". It must be >>>>>> pointer to a specific row in a specific table. If this is a pointer >>>>>> to >>>>>> a row in the mplsTunnelTable spell it out clearly and unambiguously. >>>>> >>>>> >>>>> >>>>> TBD. I will need some more time to understand the original context. >>>>> >>>>>> 4.16 >>>>>> l2L3VpnMcastPmsiTunnelIf OBJECT-TYPE >>>>>> DESCRIPTION >>>>>>> >>>>>>> >>>>>>> "If the tunnel has a corresponding interface, this is the >>>>>>> row pointer to ifXTable. Otherwise, the pointer is null." >>>>>> >>>>>> >>>>>> This description is better. Would be even better with >>>>>> "If the tunnel has a corresponding entry in the ifXTable, >>>>>> this object will point to the row pertaining to the entry >>>>>> ..... >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 4.17 >>>>>> l2L3VpnMcastOptionalGroup OBJECT-GROUP >>>>>>> >>>>>>> >>>>>>> DESCRIPTION >>>>>>> "Support of these object is not required." >>>>>> >>>>>> >>>>>> Support of these objects is not required. >>>>> >>>>> >>>>> >>>>> Fixed. >>>>> >>>>>> 5.0 >>>>>>> >>>>>>> >>>>>>> 5. Security Considerations >>>>>> >>>>>> >>>>>> TBD >>>>> >>>>> >>>>> >>>>> Still TBD. >>>>> >>>>>> 6.0 >>>>>>> >>>>>>> >>>>>>> 6. IANA Considerations >>>>>> >>>>>> >>>>>> >>>>>>> IANA is requested to root MIB objects in the MIB module contained in >>>>>>> this document under the mib-2 subtree. >>>>>> >>>>>> >>>>>> >>>>>> Please Note: >>>>>> To make the L2L3VpnMcastProviderTunnelType TC maintainable you need >>>>>> to >>>>>> put the definitions in a separate MIB module. That would mean a >>>>>> separate branch in the mib-2 subtree. Then the maintenance of the >>>>>> TC can be carried out by some entity ( IANA or, some WG or, whoever >>>>>> is >>>>>> responsible for maintaining the TC) independent of other MIB >>>>>> objects. >>>>>> If that is the intent you will need to define 2 mib modules and you >>>>>> will >>>>>> need to request 2 branches in the mib-2 subtree- one for the module >>>>>> containing the L2L3VpnMcastProviderTunnelType TC and another for the >>>>>> module containing the l2L3VpnMcastPmsiTunnelAttributeTable. >>>>> >>>>> >>>>> >>>>> TBD. I will address this point in the next revision. >>>>> >>>>> 2016-06-07 18:39 GMT+09:00 Glenn Mansfield Keeni : >>>>>> >>>>>> >>>>>> 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 ; Benoit Claise >>>>>>>> ; EXT - thomas.morin@orange.com >>>>>>>> >>>>>>>> Cc: Mach Chen ; ops-ads@ietf.org; Martin >>>>>>>> Vigoureux >>>>>>>> ; 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 >>>>>>>>>> ::= { XXX } >>>>>>>>>> -- RFC Ed.: replace XXX with IANA-assigned number & remove this >>>>>>>>>> note >>>>>>>>>> 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 ; EXT - >>>>>>>>>> thomas.morin@orange.com >>>>>>>>>> >>>>>>>>>> Cc: Jeffrey (Zhaohui) Zhang ; ops-ads@ietf.org; >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Vigoureux ; bess@ietf.org; Mach Chen >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> BESS mailing list >>>>>> BESS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/bess >>>>>> >>>> >>> >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> >>