From nobody Thu Nov 2 01:54:06 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 B77FB13836B for ; Thu, 2 Nov 2017 01:54:04 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=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 1Qd0p8Qs6iBi for ; Thu, 2 Nov 2017 01:54:01 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 0EB9113F47C for ; Thu, 2 Nov 2017 01:54:01 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 1so5582180qtn.3 for ; Thu, 02 Nov 2017 01:54:01 -0700 (PDT) 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=dn/vmIORy9P3PGm97KXzW184IChfgip+XE+qUfM536w=; b=o/gZ2urBscwMOwZ0ITgKLsYDB35fQY216gr++KzZO1TNkTC3R2IASgvaaJaPU4bRpy Hdw4I5wih2enfmNNPToTv3vcGG48iGrzskMPM33CORXN8LkB4csLy5fMd7Bq46j76uoc eHUiCU/71O1t2z+eCpjHn9mhsRwaAVsLrocG2VaDB7dX4eHEZSOG4Fga62WVp6DHQAoA jdE4hM6a3DXV/elC1fciMgamxPbsSEBevPEyh210JE2KupN1H/0iwaHjDRX9WFEepdR9 UuHtDTruvxAFd2FOOoclp0NUHbr8oNF6bE2STsgzyDrs1ALCKYEIzJIay6zAGS0uTbum pocA== 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=dn/vmIORy9P3PGm97KXzW184IChfgip+XE+qUfM536w=; b=TpiDH2zZOIvOTCTXNkRYxb5FGZO0B6i1qQ+LUowJgdftX/usnNXah0A7V4T49u3vKw vTjexZgMopv2oaDKTP7hMdlDwWlycoYDYbVjpIkQjrDEAJXzQLCZJH8WwkKW0+bVx80C bkkpWJs6MhG/pAt9mzE44gltSSDcGfIy2BRUK0yCGBpT3TDVoct3OFMOnEdptJAkt8gE 3BrvV3yTNo/ezqdz57abs/Tfx4xSItD3+U00mpCU7P+aijYPODRY2qmtWHtlM9OnpCWs SN2DHk1M23JC+GcxUkH24zWBmabrbMJSTsi7QL8+LmaLkhEehgNTMfi8xolydmeEwuDh bWcQ== X-Gm-Message-State: AMCzsaXSuWdyoA4Rrc/VEb0cXxeJJyT+zOfkNUVCoAFkKn5RlL9UzqGr UL/7vUcZJaau0N17JhrA68aaWyaGS078/JrfRMVuaA== X-Google-Smtp-Source: ABhQp+T9O4MCFnRpr8Pa5aiSLy/jVeq9pNyvo16eWm7YwQI5ONOi5+GCT4t1OL1A5pjM0t1TX86PeVYAB9mziKp9iI0= X-Received: by 10.200.63.242 with SMTP id v47mr4070303qtk.29.1509612839943; Thu, 02 Nov 2017 01:53:59 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.102.184 with HTTP; Thu, 2 Nov 2017 01:53:19 -0700 (PDT) In-Reply-To: <730a8e1b-2a90-426b-3497-dab406376ebf@cysols.com> References: <730a8e1b-2a90-426b-3497-dab406376ebf@cysols.com> From: Hiroshi Tsunoda Date: Thu, 2 Nov 2017 09:53:19 +0100 X-Google-Sender-Auth: dOorzb7hZRRgHJxSAJo0hIrpUgE Message-ID: To: Glenn Mansfield Keeni Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MIB-DOCTORS] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-11 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 08:54:05 -0000 Dear Glenn, Thank you very much for your very elaborate review. I will do another editorial check for nits according to your suggestions. Best regards, -- tsuno 2017-11-01 5:07 GMT+01:00 Glenn Mansfield Keeni : > Hi Tsuno, > Thanks for addressing the issues in the new draft. It > looks good. I do not have any major issues with the MIB. > But before we give a go-ahead I would like to ask to you > do another editorial check for nits.These are basically > s/network/networks/ > type of fixes. > A minor issue with the MIB on naming related mater- > I would suggest > s/l2L3VpnMcastPmsiFieldGroup/l2L3VpnMcastCoreGroup/ > > Glenn > > > On 2017/10/22 1:14, Hiroshi Tsunoda wrote: >> >> Dear Glenn, >> >> Thank you for your comments and for waiting for the update. >> I posted a new revision (-11) as follows. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-11.txt >> Htmlized: >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11 >> Htmlized: >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-11 >> Diff: >> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-11 >> >> Please see the responses for your comments in the followings. >> >> 2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni : >>> >>> 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION >>> 1.1 It will be good to give a reference (RFCNNNN) for >>> noTunnelInfo (0) : no tunnel information present >>> That will make it consistent with the other items. >>> This change will require adding RFCNNNN to the REFERENCE clause. >> >> >> Fixed. >> >>> 1.2 pimBidir (5) : BIDIR-PIM Tree [RFC5015] >>> RFC5015 needs to be added to the Reference section >> >> >> RFC5015 added to the Reference section. >> >>> 3. Page-7,8: says >>> " A L2L3VpnMcastProviderTunnelType object of value >>> noTunnelInfo(0) indicates that the corresponding >>> Provider Multicast Service Interface (PMSI) Tunnel >>> attribute does not have a Tunnel Identifier." >>> It may be better to align the wording with RFC6514 (Page 11) >>> ' When the Tunnel Type is set to "No tunnel information >>> present", the PMSI Tunnel attribute carries no tunnel >>> information (no Tunnel Identifier).' >> >> >> Fixed. Thank you for your advice. >> >>> 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION: >>> E: Extension flag [RFC7902] >>> RFC7902 needs to be added to the Reference section >> >> >> Fixed. RFC7902 is now in the Reference section. >> >>> 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE >>> "RFC6514, Section 5 >>> RFC7902 >>> " >>> It will be nice to have a section pointer for RFC7902 too. >>> (User-friendly and consistency). >>> Please check the same for all the REFERENCE clause pointers >> >> >> Added a section point for Sec.3 of RFC7902. >> >>> 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION >>> "When UDP-based S-PMSI signaling is used, the value of >>> this object is zero." >>> This is actually a 48-bit string. What would be the >>> representation of "zero" above be? Will it be a string of >>> length 0, a string containing a single ascii character "0" >>> 6 ascii "0"s, 48 '0' bits ? >>> >>> 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION: >>> "When UDP-based S-PMSI signaling is used, the value of >>> this object is zero that indicates the absence of MPLS >>> Label." >>> Once again. "zero" above is imprecise. >> >> >> In the current revision, these parts are revised as follows. >> When the P-tunnel does not have a correspondent PMSI tunnel >> attribute, the value of this object will be 0. >> >>> 8. Compliance: >>> It would be good to design the compliance module as follows: >>> l2L3VpnMcastCoreCompliance: >>> MANDATORY-GROUPS { >>> l2L3VpnMcastPmsiFieldGroup >>> } >>> l2L3VpnMcastFullCompliance: >>> MANDATORY-GROUPS { >>> l2L3VpnMcastPmsiFieldGroup >>> l2L3VpnMcastOptionalGroup >>> } >> >> >> Fixed along with your comments. Thank you. >> >>> General: >>> 10 Page-2 Section-1 >>> 10.1 In BGP/MPLS Virtual Private Networks (VPN) >>> In BGP/MPLS Virtual Private Networks (VPNs) ? >> >> >> Fixed. >> >>> 10.2 Throughout this document, we will use the term >>> "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support >>> multicast. >>> >>> Throughout this document, we will use the term >>> "L2L3VpnMCast network" to mean a network that comprises of >>> BGP/MPLS L2 and L3 VPNs and supports multicast. >> >> >> Fixed. Now, the term "L2L3VpnMCast network" is used throughout the >> document. >> >>> 10.3 Page-4 Section-3 bullet 2 >>> Please review the paragraph for readability. >> >> >> Revised the paragraph in order to improve readability. >> >>> 10.4 It will be good to avoid page-breaks within quoted clauses. >>> example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE >> >> >> Thank you for your comments. I adjusted the page-breaks along with this >> comment. >> >> Thanks again. >> >> -- tsuno >> >> 2017-09-02 9:47 GMT+02:00 Glenn Mansfield Keeni : >>> >>> Dear Tsuno, >>> >>> Thanks for the revised draft. I have reviewed the draft. >>> Some issues remain. These are listed below >>> Please consider the issues/comments and update the draft. >>> >>> Glenn >>> >>> +--------------------------------------------------------+ >>> >>> 1. Page-6: L2L3VpnMcastProviderTunnelType: DESCRIPTION >>> 1.1 It will be good to give a reference (RFCNNNN) for >>> noTunnelInfo (0) : no tunnel information present >>> That will make it consistent with the other items. >>> This change will require adding RFCNNNN to the REFERENCE clause. >>> 1.2 pimBidir (5) : BIDIR-PIM Tree [RFC5015] >>> RFC5015 needs to be added to the Reference section >>> >>> 2. Page-6: L2L3VpnMcastProviderTunnelType: SYNTAX >>> The rewritten SYNTAX clause without the repetitions looks better. >>> Thanks. >>> >>> 3. Page-7,8: says >>> " A L2L3VpnMcastProviderTunnelType object of value >>> noTunnelInfo(0) indicates that the corresponding >>> Provider Multicast Service Interface (PMSI) Tunnel >>> attribute does not have a Tunnel Identifier." >>> It may be better to align the wording with RFC6514 (Page 11) >>> ' When the Tunnel Type is set to "No tunnel information >>> present", the PMSI Tunnel attribute carries no tunnel >>> information (no Tunnel Identifier).' >>> >>> 4. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: DESCRIPTION: >>> E: Extension flag [RFC7902] >>> RFC7902 needs to be added to the Reference section >>> >>> 5. Page-12: l2L3VpnMcastPmsiTunnelAttributeFlags: REFERENCE >>> "RFC6514, Section 5 >>> RFC7902 >>> " >>> It will be nice to have a section pointer for RFC7902 too. >>> (User-friendly and consistency). >>> Please check the same for all the REFERENCE clause pointers >>> 6. Page-12: l2L3VpnMcastPmsiTunnelAttributeAddlFlags: DESCRIPTION >>> "When UDP-based S-PMSI signaling is used, the value of >>> this object is zero." >>> This is actually a 48-bit string. What would be the >>> representation of "zero" above be? Will it be a string of >>> length 0, a string containing a single ascii character "0" >>> 6 ascii "0"s, 48 '0' bits ? >>> >>> 7. Page-14: l2L3VpnMcastPmsiTunnelAttributeLabel: DESCRIPTION: >>> "When UDP-based S-PMSI signaling is used, the value of >>> this object is zero that indicates the absence of MPLS >>> Label." >>> Once again. "zero" above is imprecise. >>> >>> 8. Compliance: >>> It would be good to design the compliance module as follows: >>> l2L3VpnMcastCoreCompliance: >>> MANDATORY-GROUPS { >>> l2L3VpnMcastPmsiFieldGroup >>> } >>> l2L3VpnMcastFullCompliance: >>> MANDATORY-GROUPS { >>> l2L3VpnMcastPmsiFieldGroup >>> l2L3VpnMcastOptionalGroup >>> } >>> >>> >>> General: >>> 10 Page-2 Section-1 >>> 10.1 In BGP/MPLS Virtual Private Networks (VPN) >>> In BGP/MPLS Virtual Private Networks (VPNs) ? >>> >>> 10.2 Throughout this document, we will use the term >>> "L2L3VpnMCast" to mean BGP/MPLS L2 and L3 VPN that support >>> multicast. >>> >>> Throughout this document, we will use the term >>> "L2L3VpnMCast network" to mean a network that comprises of >>> BGP/MPLS L2 and L3 VPNs and supports multicast. >>> >>> 10.3 Page-4 Section-3 bullet 2 >>> Please review the paragraph for readability. >>> >>> 10.4 It will be good to avoid page-breaks within quoted clauses. >>> example: Page-6 L2L3VpnMcastProviderTunnelType: REFERENCE >>> >>> >>> >>> >>> On 2017/08/28 3:27, Hiroshi Tsunoda wrote: >>>> >>>> >>>> Dear Glenn, >>>> >>>> Thank you for your comments and for waiting for the update. >>>> I posted a new revision (-10) as follows. >>>> >>>> URL: >>>> >>>> >>>> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-10.txt >>>> Htmlized: >>>> >>>> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10 >>>> Htmlized: >>>> >>>> >>>> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-10 >>>> Diff: >>>> >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-10 >>>> >>>> In the new revision, the following changes are made. >>>> - Updated the description of following TC and objects >>>> in order to clarify the role of this MIB and to improve >>>> the readability >>>> -- L2L3VpnMcastProviderTunnelId >>>> -- l2L3VpnMcastPmsiTunnelAttributeTable >>>> - Removed some redundant expressions >>>> - Updated compliance statements >>>> >>>> Please see the responses for your comments >>>> in the followings. >>>> >>>> 2017-07-09 14:11 GMT+02:00 Glenn Mansfield Keeni : >>>>> >>>>> >>>>> L2L3-VPN-MCAST-TC-MIB:112: [5] {type-without-format} warning: type >>>>> `L2L3VpnMcastProviderTunnelId' has no format specification >>>>> This may be avoided by specifying a format in which the >>>>> L2L3VpnMcastProviderTunnelId should be printed. >>>>> Is there a preferred format? How will this be printed? >>>>> One continuous octet string? >>>> >>>> >>>> >>>> The size and format of TunnelID depends on Tunnel Type. >>>> and no preferred format is exist as of now. >>>> Therefore, I have decided to not give format specification >>>> to L2L3VpnMcastProviderTunnelId. >>>> >>>>> A. The l2L3VpnMcastPmsiTunnelAttributeTable needs all of the following >>>>> four MOs as index for its rows >>>>> l2L3VpnMcastPmsiTunnelAttributeFlags, >>>>> l2L3VpnMcastPmsiTunnelAttributeType, >>>>> l2L3VpnMcastPmsiTunnelAttributeLabel, >>>>> l2L3VpnMcastPmsiTunnelAttributeId >>>>> The l2L3VpnMcastPmsiTunnelAttributeId by itself is inadequate? If >>>>> yes >>>>> please explain it to me. Or point to the text that contains the >>>>> explanation. >>>>> I have been unable to confirm the above from the draft - that is very >>>>> likely due to my lack of understanding of the l2L3VpnMcast technology. >>>> >>>> >>>> >>>> According to Sec. 7.4.1.1 of RFC6513, >>>> P-tunnel is identified by its type and id. >>>> Thus, in the latest revision, the following two objects are used as >>>> index of the table. >>>> l2L3VpnMcastPmsiTunnelAttributeType, >>>> l2L3VpnMcastPmsiTunnelAttributeId >>>> >>>> Thanks in advance, >>>> >>>> -- tsuno >>>> >>>> _______________________________________________ >>>> 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 Nov 27 15:10:36 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 E433A127419 for ; Mon, 27 Nov 2017 15:10:33 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=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 jZp-HGTpXKTX for ; Mon, 27 Nov 2017 15:10:32 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 199C212704B for ; Mon, 27 Nov 2017 15:10:32 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id 33so32530064qtv.1 for ; Mon, 27 Nov 2017 15:10:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to:cc; bh=F84rsQ1W1i8NIKmGH/iVukulwUQ+mnhXreIC0q01wZ0=; b=ZxO9jpwYFKuMOr4CcbCcnV3LDyP9fHLoppcmCKCS7TWi8R91AwJ6GHBxFVIEdNhFEL yxo6yGVTJKycSN5CA+zyM7EYHRxsOOEmlPVZfbORLhRuzbv1orPOd5biF/u2tIL6A+lP sEyZdOoYphX/Rjv0moayHTYzF3Y7vemOSA0qLNLGaqquFbqREpvZ3zR31qp9OcWB8Qop cjfs94+jGxG9WFCUP4FrrEoMOXFsknUZ/uD3eemqxCVBJqMSnHfroZqJmLKvCBNS/e8V nZL/qZcWdpt4gnCU/uKKJWdlxZwsSX+pEF22vAK8dknm3mdVNkr/Wli7LCPHnl7HOKJ+ s5Gw== 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:from:date:message-id:subject :to:cc; bh=F84rsQ1W1i8NIKmGH/iVukulwUQ+mnhXreIC0q01wZ0=; b=tDFSeXqRd5APs7O9SSqq3ahl8Umqw4uq2Y49xVFckkK5C3eCx8WGkieQqGZZrOsBxh Q2sIxxnAWHfjimd4IKhbWOGIzmr32jJyC3I49VlBNSOWJ0SoaUqqW6fi3qYoSMxU0ET+ eAwPAVOh/bca91PgIGCQrvOLt1vag6QAwzaIZ4sGLG2a2vQdgeZAobmQEBQXZfzO5NT4 qMRhbcqx7LeGIJ0OvYGhNo0COPAoWz48YqjI9XKdRSf+CwzkzlUUK6QF6ebn1MLEg1F+ k9WxYXjfBB0Ri38BuQ4I/YAdiFzBILAuXdZ6mfhYcT2y2MsmkaPR6tA7xAMEBtrmGpXt GXVw== X-Gm-Message-State: AJaThX4gh0NLD/PAo1Sv6cgx+5Fxw3otVAjuxb0Mvad6IemYW9lbanjD S6gOrTYotR4hGYaNrk7YMf2flOWY5L17uxOr5unJJQ== X-Google-Smtp-Source: AGs4zManfZB09HGwYCFj20I/pI2wKRZXNqEN5HXGRcss3p0TPQ3SuS6URFqAi+H7TMH05BGkL1U4qRrH0OXF7b/23gM= X-Received: by 10.237.61.243 with SMTP id j48mr1884131qtf.52.1511824231221; Mon, 27 Nov 2017 15:10:31 -0800 (PST) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.86.84 with HTTP; Mon, 27 Nov 2017 15:09:50 -0800 (PST) From: Hiroshi Tsunoda Date: Tue, 28 Nov 2017 00:09:50 +0100 X-Google-Sender-Auth: 6cXTOhdcpu1_U5Q-nHR9RLFxov0 Message-ID: To: "Glenn M. Keeni" Cc: Mach Chen , mib-doctors@ietf.org, "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , bess@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [MIB-DOCTORS] Update to draft-ietf-bess-l2l3-vpn-mcast-mib-12 X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 23:10:34 -0000 Dear Glenn, May I ask you to give one more review for draft-ietf-bess-l2l3-vpn-mcast-mib matter? I posted a new revision (-12). In this revision, I have made the following changes in order to make the MIB simpler and be less dependent on BGP. - Added l2L3VpnMCastPmsiTunnelLeafInfoRequired object. This object corresponds to "Leaf Information Required" flag in Flags field. - Removed two objects shown below - l2L3VpnMcastPmsiTunnelAttributeFlags - l2L3VpnMcastPmsiTunnelAttributeAddlFlags - Fixed some editorial issues. Links to the draft and diff are as follows. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-12.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-12 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-12 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-12 Thanks in advance, -- tsuno