From nobody Tue Oct 3 05:52:37 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 E3D8E1345D5; Tue, 3 Oct 2017 05:52:35 -0700 (PDT) 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 kfGz8cScqybo; Tue, 3 Oct 2017 05:52:32 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 A5DEB1345BD; Tue, 3 Oct 2017 05:52:32 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id v9so1852089oif.13; Tue, 03 Oct 2017 05:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=ZBbMgyyEsPn76XMGK4vMXgAdhRKatXDXUxBHbG9xsUw=; b=HiM3AcnEvJQUvLVtUJwF+WM9z6xAIpHevOlsfmk7c0ilBxSQ9HAnTeuMGBCy/9AHU1 WttxDCc7IGeoDGkEzi0iu34qxZOyEfIQjlZl2jDVTULlY5+vyRyRpWYiB6HHjElPBp8F liti0RT7mtDRBqEmC3joy3KvbpS0Nz30lLnsz90SnF4vxnVRuJvqSXiq51N+XjC0ht3Z mI9K5/wJPc1J409oT055CTk/0O4keLitwyGB14hmR5aGBzV6MEHHoNy1GEQe8ir9Jkah ASBrzlbiur0SI6Hzi0wVFO3rJa0eKUXkMpNaeE7vqfGKL4q8ITNUQa5t8qFqwJhv7LT9 9MdQ== 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:cc; bh=ZBbMgyyEsPn76XMGK4vMXgAdhRKatXDXUxBHbG9xsUw=; b=Eh+gpCHiYHiEj5/sZqFKLopk3FG04X202G2BWgevEWpjiqRNObwDIiVgTtU91+Xhkp lQmjDgF+blHpWTAvgRKXbgVYFkoHO7OTL5oWgUATSuWXrM6whvchiB9Lq1xoxmUn62Qd pFcFScwNgjQJLXTFqVTFplFvh2ci1M7bQkO0P6YyQpEG3zd96kbmJFbr+P30MAUiA/BL NlT2HDhVh8q0zyH7u84NWL/XaPeOsTRfqKryt6cNENYPMGNOCEL295tIehWXJl78OvS+ nZDi9+qdPU+hRmyIVJKuB5s8An3rVFP4RbRG2jx4CVctZjyUnu3cq09BO838mxS2Opou 8FQQ== X-Gm-Message-State: AMCzsaVPy9SXvhUfvc7XbBPDZibpp/Mze6PW8IJfZmrJlG5dWrw4meH6 y2xNDClKoacnUgrd9WxiYSeXQ3We5a9bg+skSdUUAw== X-Google-Smtp-Source: AOwi7QDdSCNRrtDiw+7PEHNDNDOEn2Bi6zmp9P6luZGdmtwjVLqAIyj4eroWBnt2MSbvMHm+jg/nPOEnci1t2TcyKeE= X-Received: by 10.202.180.215 with SMTP id d206mr7140535oif.179.1507035151535; Tue, 03 Oct 2017 05:52:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.76.21 with HTTP; Tue, 3 Oct 2017 05:52:31 -0700 (PDT) From: Joan Cucchiara Date: Tue, 3 Oct 2017 08:52:31 -0400 Message-ID: To: mpls@ietf.org Cc: Kishore Tiruveedhula , Loa Andersson , draft-ietf-mpls-mldp-mib@ietf.org, mpls-chairs@ietf.org, db3546@att.com, mib-doctors@ietf.org Content-Type: multipart/alternative; boundary="001a113cf468df1718055aa3f6e0" Archived-At: Subject: [MIB-DOCTORS] MIB Dr. Review of draft-ietf-mpls-mldp-mib-03.txt 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: Tue, 03 Oct 2017 12:52:36 -0000 --001a113cf468df1718055aa3f6e0 Content-Type: text/plain; charset="UTF-8" Hi Kishore, My apologies for the lateness of the review. The MIB doesn't compile. Please make sure that it compiles using smilint. Here is the URL: http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/?lang=de Here are some comments, but please note, that this cannot be a full review until: 1) the MIB Module compiles cleanly (or an explanation is given for unusual warnings) 2) some of the tables in this MIB Module need to have the relationship to Tables in the LPD-STD-MIB Module clarified (more below on this). 3) Need to add Conformance Statements. See rfc4181 and/or rfc2580. Many of the compiler warnings are complaining about this. Thanks, -Joan Typo in comment: LAST-UPDATED "201710010000Z" -- Octiber 1, 2017 Smilint has the following errors -- please see my comments below prefaced with JEL: mibs/MPLS-MLDP-STD-MIB.my:277: [5] {identifier-external-redefined} warning: redefinition of identifier `MPLS-LDP-STD-MIB::mplsLdpPeerLdpId' /usr/local/share/mibs/ietf/MPLS-LDP-STD-MIB:1041: [6] {previous-definition} info: previous definition of `mplsLdpPeerLdpId' mibs/MPLS-MLDP-STD-MIB.my:272: [3] {sequence-no-column} SEQUENCE element #1 `mplsLdpPeerLdpId' is not a child node under `mplsLdpPeerCapabilityEntry' mibs/MPLS-MLDP-STD-MIB.my:272: [3] {sequence-missing-column} SEQUENCE of `MplsLdpPeerCapabilityEntry' is missing columnar object `mplsLdpPeerLdpId' JEL: The MIB Module is importing these indices: mplsLdpStdMIB, mplsLdpEntityLdpId, mplsLdpEntityIndex, mplsLdpPeerLdpId, mplsLdpSessionStatsEntry FROM MPLS-LDP-STD-MIB -- RFC 3815 When I look at the tables that are using these IMPORTS, they mention "augmented" but there I don't see that the relationship is AUGMENTS used, so I suspect that this is not truly an AUGMENTS, but a SPARSE AUGMENTS. Please clarify. Please note also, that mplsLdpSessionTable came first, so mplsLdpSessionTable can be augmented by a newer table, not the other way around. mibs/MPLS-MLDP-STD-MIB.my:100: [4] {group-membership} warning: node `mplsMldpP2mpCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:115: [4] {group-membership} warning: node `mplsMldpMp2mpCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:130: [4] {group-membership} warning: node `mplsMldpMbbCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:147: [4] {group-membership} warning: node `mplsMldpMbbTime' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:159: [4] {group-membership} warning: node `mplsMldpNumFecs' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:168: [4] {group-membership} warning: node `mplsMldpNumFecsActive' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:178: [4] {group-membership} warning: node `mplsMldpPlrCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:196: [4] {group-membership} warning: node `mplsMldpMptCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:211: [4] {group-membership} warning: node `mplsMldProtLsrCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:226: [4] {group-membership} warning: node `mplsMldProtNodeProtCapable' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:287: [4] {group-membership} warning: node `mplsLdpPeerCapability' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:277: [4] {group-membership} warning: node `mplsLdpPeerLdpId' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:366: [4] {group-membership} warning: node `mplsMldpSessionStatsNumFecsSent' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:382: [4] {group-membership} warning: node `mplsMldpSessionStatsNumMbbReqSentState' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:396: [4] {group-membership} warning: node `mplsMldpSessionStatsNumFecsRcvd' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:412: [4] {group-membership} warning: node `mplsMldpSessionStatsNumMbbReqRcvdState' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:424: [4] {group-membership} warning: node `mplsMldpSessionStatsNumMbbResetAckByTimer' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:492: [4] {group-membership} warning: node `mplsMldpFecType' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:511: [4] {group-membership} warning: node `mplsMldpFecRootAddrType' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:526: [4] {group-membership} warning: node `mplsMldpFecRootAddr' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:543: [4] {group-membership} warning: node `mplsMldpFecOpaqueType' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:565: [4] {group-membership} warning: node `mplsMldpFecOpaqueGenLspId' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:579: [4] {group-membership} warning: node `mplsMldpFecOpaqueTransitSourceOrBidirAddrType' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:595: [4] {group-membership} warning: node `mplsMldpFecOpaqueTransitSourceOrBidirAddr' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:609: [4] {group-membership} warning: node `mplsMldpFecOpaqueTransitGroupAddrType' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:624: [4] {group-membership} warning: node `mplsMldpFecOpaqueTransitGroupAddr' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:640: [4] {group-membership} warning: node `mplsMldpFecAdminStatus' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:654: [4] {group-membership} warning: node `mplsMldpFecOperStatus' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:666: [4] {group-membership} warning: node `mplsMldpFecMoFrr' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:687: [4] {group-membership} warning: node `mplsMldpFecLsrState' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:701: [4] {group-membership} warning: node `mplsMldpFecUpTime' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:778: [4] {group-membership} warning: node `mplsMLdpFecBranchPeerLdpId' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:790: [4] {group-membership} warning: node `mplsMldpFecBranchStatsPackets' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:802: [4] {group-membership} warning: node `mplsMldpFecBranchStatsBytes' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:814: [4] {group-membership} warning: node `mplsMldpFecBranchStatsDiscontinuityTime' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:897: [4] {group-membership} warning: node `mplsMldpFecUpstreamSessPrimary' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:911: [4] {group-membership} warning: node `mplsMldpFecUpstreamSessActive' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:927: [4] {group-membership} warning: node `mplsMldpFecUpstreamSessPackets' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:939: [4] {group-membership} warning: node `mplsMldpFecUpstreamSessBytes' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:951: [4] {group-membership} warning: node `mplsMldpFecUpstreamSessDiscontinuityTime' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1014: [4] {group-membership} warning: node `mplsMldpInterfaceStatsSentPackets' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1025: [4] {group-membership} warning: node `mplsMldpInterfaceStatsSentBytes' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1035: [4] {group-membership} warning: node `mplsMldpInterfaceStatsRecvPackets' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1045: [4] {group-membership} warning: node `mplsMldpInterfaceStatsRecvBytes' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1059: [4] {group-membership} warning: notification `mplsMldpFecUp' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1072: [4] {group-membership} warning: notification `mplsMldpFecDown' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:1084: [4] {group-membership} warning: notification `mplsMldpMoFrrStatusChange' must be contained in at least one conformance group mibs/MPLS-MLDP-STD-MIB.my:833: [2] {type-unknown} unknown type `MplsMldpFecUpstreamSessEntry' JEL: Please fix the typo at line 862: to get rid of the above error "MplsMLdpFecUpstreamSessEntry" should be: MplsMldpFecUpstreamSessEntry mibs/MPLS-MLDP-STD-MIB.my:5: [5] {import-unused} warning: identifier `TimeTicks' imported from module `SNMPv2-SMI' is never used mibs/MPLS-MLDP-STD-MIB.my:7: [5] {import-unused} warning: identifier `MODULE-COMPLIANCE' imported from module `SNMPv2-CONF' is never used mibs/MPLS-MLDP-STD-MIB.my:7: [5] {import-unused} warning: identifier `OBJECT-GROUP' imported from module `SNMPv2-CONF' is never used mibs/MPLS-MLDP-STD-MIB.my:7: [5] {import-unused} warning: identifier `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used mibs/MPLS-MLDP-STD-MIB.my:9: [5] {import-unused} warning: identifier `TruthValue' imported from module `SNMPv2-TC' is never used mibs/MPLS-MLDP-STD-MIB.my:9: [5] {import-unused} warning: identifier `RowStatus' imported from module `SNMPv2-TC' is never used mibs/MPLS-MLDP-STD-MIB.my:9: [5] {import-unused} warning: identifier `StorageType' imported from module `SNMPv2-TC' is never used mibs/MPLS-MLDP-STD-MIB.my:21: [5] {import-unused} warning: identifier `IndexIntegerNextFree' imported from module `DIFFSERV-MIB' is never used mibs/MPLS-MLDP-STD-MIB.my:27: [5] {import-unused} warning: identifier `mplsLdpStdMIB' imported from module `MPLS-LDP-STD-MIB' is never used mibs/MPLS-MLDP-STD-MIB.my:28: [5] {import-unused} warning: identifier `mplsLdpSessionStatsEntry' imported from module `MPLS-LDP-STD-MIB' is never used E: f(MPLS-MLDP-STD-MIB.my), (833,33) Sequence "MplsMldpFecUpstreamSessEntry" is referenced, but not defined E: f(MPLS-MLDP-STD-MIB.my), (862,4) Sequence "MplsMLdpFecUpstreamSessEntry" is defined, but not referenced JEL: same comment as above, typo (MplsMldp with a lower case "l") E: f(MPLS-MLDP-STD-MIB.my), (872,4) Item "mplsMldpFecUpstreamSessFecIndex" must be in sequence for row "mplsMldpFecUpstreamSessEntry" E: f(MPLS-MLDP-STD-MIB.my), (884,4) Item "mplsMldpFecUpstreamSessInSegIndex" must be in sequence for row "mplsMldpFecUpstreamSessEntry" E: f(MPLS-MLDP-STD-MIB.my), (897,5) Item "mplsMldpFecUpstreamSessPrimary" must be in sequence for row "mplsMldpFecUpstreamSessEntry" E: f(MPLS-MLDP-STD-MIB.my), (911,5) Item "mplsMldpFecUpstreamSessActive" must be in sequence for row "mplsMldpFecUpstreamSessEntry" E: f(MPLS-MLDP-STD-MIB.my), (927,4) Item "mplsMldpFecUpstreamSessPackets" must be in sequence for row "mplsMldpFecUpstreamSessEntry" E: f(MPLS-MLDP-STD-MIB.my), (939,4) Item "mplsMldpFecUpstreamSessBytes" must be in sequence for row "mplsMldpFecUpstreamSessEntry" E: f(MPLS-MLDP-STD-MIB.my), (951,4) Item "mplsMldpFecUpstreamSessDiscontinuityTime" must be in sequence for row "mplsMldpFecUpstreamSessEntry" W: f(MPLS-MLDP-STD-MIB.my), (100,4) Item "mplsMldpP2mpCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (115,3) Item "mplsMldpMp2mpCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (130,3) Item "mplsMldpMbbCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (147,6) Item "mplsMldpMbbTime" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (159,4) Item "mplsMldpNumFecs" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (168,4) Item "mplsMldpNumFecsActive" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (178,4) Item "mplsMldpPlrCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (196,4) Item "mplsMldpMptCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (211,4) Item "mplsMldProtLsrCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (226,4) Item "mplsMldProtNodeProtCapable" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (277,6) Item "mplsLdpPeerLdpId" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (287,6) Item "mplsLdpPeerCapability" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (366,6) Item "mplsMldpSessionStatsNumFecsSent" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (382,6) Item "mplsMldpSessionStatsNumMbbReqSentState" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (396,6) Item "mplsMldpSessionStatsNumFecsRcvd" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (412,5) Item "mplsMldpSessionStatsNumMbbReqRcvdState" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (424,5) Item "mplsMldpSessionStatsNumMbbResetAckByTimer" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (492,6) Item "mplsMldpFecType" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (511,6) Item "mplsMldpFecRootAddrType" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (526,6) Item "mplsMldpFecRootAddr" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (543,6) Item "mplsMldpFecOpaqueType" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (565,7) Item "mplsMldpFecOpaqueGenLspId" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (579,6) Item "mplsMldpFecOpaqueTransitSourceOrBidirAddrType" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (595,6) Item "mplsMldpFecOpaqueTransitSourceOrBidirAddr" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (609,6) Item "mplsMldpFecOpaqueTransitGroupAddrType" is not contained in any group defined in the current module W: f(MPLS-MLDP-STD-MIB.my), (624,6) Item "mplsMldpFecOpaqueTransitGroupAddr" is not contained in any group defined in the current module --001a113cf468df1718055aa3f6e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kishore,

My apologies for= the lateness of the review.=C2=A0 =C2=A0The MIB doesn't compile.=C2=A0= Please make sure that it compiles using smilint.=C2=A0 =C2=A0Here is the U= RL:
http://www.ibr.cs.tu-bs.de/projects/libsmi/tools/?lang=3Dde<= /div>

Here are some comments, but please note, that this= cannot be a full review until:
1) the MIB Module compiles cleanl= y (or an explanation is given for unusual warnings)
2) some of th= e tables in this MIB Module need to have the relationship to Tables in the = LPD-STD-MIB Module clarified=C2=A0 (more below on this).=C2=A0
3)= Need to add Conformance Statements.=C2=A0 See rfc4181 and/or rfc2580.=C2= =A0 Many of the compiler warnings are complaining about this.

Thanks,
-Joan




Typo in comment:
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LAST-UPDATED "201710010000Z"=C2= =A0 -- Octiber 1, 2017



Smilint has the following errors --=C2=A0 please see my comments below p= refaced with JEL:


mibs/MPLS-MLDP-ST= D-MIB.my:277: [5] {identifier-external-redefined} warning: redefinition of = identifier `MPLS-LDP-STD-MIB::mplsLdpPeerLdpId'
/usr/local/sh= are/mibs/ietf/MPLS-LDP-STD-MIB:1041: [6] {previous-definition} info: previo= us definition of `mplsLdpPeerLdpId'

mibs/MPLS-= MLDP-STD-MIB.my:272: [3] {sequence-no-column} SEQUENCE element #1 `mplsLdpP= eerLdpId' is not a child node under `mplsLdpPeerCapabilityEntry'
mibs/MPLS-MLDP-STD-MIB.my:272: [3] {sequence-missing-column} SEQUEN= CE of `MplsLdpPeerCapabilityEntry' is missing columnar object `mplsLdpP= eerLdpId'

JEL:=C2=A0 The MIB Module is importi= ng these indices:=C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m= plsLdpStdMIB, mplsLdpEntityLdpId, mplsLdpEntityIndex,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0mplsLdpPeerLdpId, mplsLdpSessionStatsEntry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FROM MPLS-LDP-STD-MIB=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 -- RFC 3815

When I look at the table= s that are using these IMPORTS, they mention "augmented" but ther= e I don't see that=C2=A0
the relationship is AUGMENTS used, s= o I suspect that this is not truly an AUGMENTS, but a SPARSE AUGMENTS.=C2= =A0=C2=A0
Please clarify.=C2=A0 Please note also, that mplsLdpSes= sionTable came first, so=C2=A0 mplsLdpSessionTable can be augmented by a ne= wer table, not the other way around.




mibs/MPLS-MLDP-STD-MIB.my:100: [4] {group-m= embership} warning: node `mplsMldpP2mpCapable' must be contained in at = least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:115: [4] {g= roup-membership} warning: node `mplsMldpMp2mpCapable' must be contained= in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:130:= [4] {group-membership} warning: node `mplsMldpMbbCapable' must be cont= ained in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my= :147: [4] {group-membership} warning: node `mplsMldpMbbTime' must be co= ntained in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.= my:159: [4] {group-membership} warning: node `mplsMldpNumFecs' must be = contained in at least one conformance group
mibs/MPLS-MLDP-STD-MI= B.my:168: [4] {group-membership} warning: node `mplsMldpNumFecsActive' = must be contained in at least one conformance group
mibs/MPLS-MLD= P-STD-MIB.my:178: [4] {group-membership} warning: node `mplsMldpPlrCapable&= #39; must be contained in at least one conformance group
mibs/MPL= S-MLDP-STD-MIB.my:196: [4] {group-membership} warning: node `mplsMldpMptCap= able' must be contained in at least one conformance group
mib= s/MPLS-MLDP-STD-MIB.my:211: [4] {group-membership} warning: node `mplsMldPr= otLsrCapable' must be contained in at least one conformance group
=
mibs/MPLS-MLDP-STD-MIB.my:226: [4] {group-membership} warning: node `m= plsMldProtNodeProtCapable' must be contained in at least one conformanc= e group
mibs/MPLS-MLDP-STD-MIB.my:287: [4] {group-membership} war= ning: node `mplsLdpPeerCapability' must be contained in at least one co= nformance group
mibs/MPLS-MLDP-STD-MIB.my:277: [4] {group-members= hip} warning: node `mplsLdpPeerLdpId' must be contained in at least one= conformance group
mibs/MPLS-MLDP-STD-MIB.my:366: [4] {group-memb= ership} warning: node `mplsMldpSessionStatsNumFecsSent' must be contain= ed in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:38= 2: [4] {group-membership} warning: node `mplsMldpSessionStatsNumMbbReqSentS= tate' must be contained in at least one conformance group
mib= s/MPLS-MLDP-STD-MIB.my:396: [4] {group-membership} warning: node `mplsMldpS= essionStatsNumFecsRcvd' must be contained in at least one conformance g= roup
mibs/MPLS-MLDP-STD-MIB.my:412: [4] {group-membership} warnin= g: node `mplsMldpSessionStatsNumMbbReqRcvdState' must be contained in a= t least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:424: [4] = {group-membership} warning: node `mplsMldpSessionStatsNumMbbResetAckByTimer= ' must be contained in at least one conformance group
mibs/MP= LS-MLDP-STD-MIB.my:492: [4] {group-membership} warning: node `mplsMldpFecTy= pe' must be contained in at least one conformance group
mibs/= MPLS-MLDP-STD-MIB.my:511: [4] {group-membership} warning: node `mplsMldpFec= RootAddrType' must be contained in at least one conformance group
=
mibs/MPLS-MLDP-STD-MIB.my:526: [4] {group-membership} warning: node `m= plsMldpFecRootAddr' must be contained in at least one conformance group=
mibs/MPLS-MLDP-STD-MIB.my:543: [4] {group-membership} warning: n= ode `mplsMldpFecOpaqueType' must be contained in at least one conforman= ce group
mibs/MPLS-MLDP-STD-MIB.my:565: [4] {group-membership} wa= rning: node `mplsMldpFecOpaqueGenLspId' must be contained in at least o= ne conformance group
mibs/MPLS-MLDP-STD-MIB.my:579: [4] {group-me= mbership} warning: node `mplsMldpFecOpaqueTransitSourceOrBidirAddrType'= must be contained in at least one conformance group
mibs/MPLS-ML= DP-STD-MIB.my:595: [4] {group-membership} warning: node `mplsMldpFecOpaqueT= ransitSourceOrBidirAddr' must be contained in at least one conformance = group
mibs/MPLS-MLDP-STD-MIB.my:609: [4] {group-membership} warni= ng: node `mplsMldpFecOpaqueTransitGroupAddrType' must be contained in a= t least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:624: [4] = {group-membership} warning: node `mplsMldpFecOpaqueTransitGroupAddr' mu= st be contained in at least one conformance group
mibs/MPLS-MLDP-= STD-MIB.my:640: [4] {group-membership} warning: node `mplsMldpFecAdminStatu= s' must be contained in at least one conformance group
mibs/M= PLS-MLDP-STD-MIB.my:654: [4] {group-membership} warning: node `mplsMldpFecO= perStatus' must be contained in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:666: [4] {group-membership} warning: node `mpls= MldpFecMoFrr' must be contained in at least one conformance group=
mibs/MPLS-MLDP-STD-MIB.my:687: [4] {group-membership} warning: node `m= plsMldpFecLsrState' must be contained in at least one conformance group=
mibs/MPLS-MLDP-STD-MIB.my:701: [4] {group-membership} warning: n= ode `mplsMldpFecUpTime' must be contained in at least one conformance g= roup
mibs/MPLS-MLDP-STD-MIB.my:778: [4] {group-membership} warnin= g: node `mplsMLdpFecBranchPeerLdpId' must be contained in at least one = conformance group
mibs/MPLS-MLDP-STD-MIB.my:790: [4] {group-membe= rship} warning: node `mplsMldpFecBranchStatsPackets' must be contained = in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:802: = [4] {group-membership} warning: node `mplsMldpFecBranchStatsBytes' must= be contained in at least one conformance group
mibs/MPLS-MLDP-ST= D-MIB.my:814: [4] {group-membership} warning: node `mplsMldpFecBranchStatsD= iscontinuityTime' must be contained in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:897: [4] {group-membership} warning: nod= e `mplsMldpFecUpstreamSessPrimary' must be contained in at least one co= nformance group
mibs/MPLS-MLDP-STD-MIB.my:911: [4] {group-members= hip} warning: node `mplsMldpFecUpstreamSessActive' must be contained in= at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:927: [4= ] {group-membership} warning: node `mplsMldpFecUpstreamSessPackets' mus= t be contained in at least one conformance group
mibs/MPLS-MLDP-S= TD-MIB.my:939: [4] {group-membership} warning: node `mplsMldpFecUpstreamSes= sBytes' must be contained in at least one conformance group
m= ibs/MPLS-MLDP-STD-MIB.my:951: [4] {group-membership} warning: node `mplsMld= pFecUpstreamSessDiscontinuityTime' must be contained in at least one co= nformance group
mibs/MPLS-MLDP-STD-MIB.my:1014: [4] {group-member= ship} warning: node `mplsMldpInterfaceStatsSentPackets' must be contain= ed in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:10= 25: [4] {group-membership} warning: node `mplsMldpInterfaceStatsSentBytes&#= 39; must be contained in at least one conformance group
mibs/MPLS= -MLDP-STD-MIB.my:1035: [4] {group-membership} warning: node `mplsMldpInterf= aceStatsRecvPackets' must be contained in at least one conformance grou= p
mibs/MPLS-MLDP-STD-MIB.my:1045: [4] {group-membership} warning:= node `mplsMldpInterfaceStatsRecvBytes' must be contained in at least o= ne conformance group
mibs/MPLS-MLDP-STD-MIB.my:1059: [4] {group-m= embership} warning: notification `mplsMldpFecUp' must be contained in a= t least one conformance group
mibs/MPLS-MLDP-STD-MIB.my:1072: [4]= {group-membership} warning: notification `mplsMldpFecDown' must be con= tained in at least one conformance group
mibs/MPLS-MLDP-STD-MIB.m= y:1084: [4] {group-membership} warning: notification `mplsMldpMoFrrStatusCh= ange' must be contained in at least one conformance group
mib= s/MPLS-MLDP-STD-MIB.my:833: [2] {type-unknown} unknown type `MplsMldpFecUps= treamSessEntry'

JEL:=C2=A0 Please fix the typo= at line 862: to get rid of the above error=C2=A0 "MplsMLdpFecUpstream= SessEntry" should be: MplsMldpFecUpstreamSessEntry


mibs/MPLS-MLDP-STD-MIB.my:5: [5] {import-unused} warni= ng: identifier `TimeTicks' imported from module `SNMPv2-SMI' is nev= er used
mibs/MPLS-MLDP-STD-MIB.my:7: [5] {import-unused} warning:= identifier `MODULE-COMPLIANCE' imported from module `SNMPv2-CONF' = is never used
mibs/MPLS-MLDP-STD-MIB.my:7: [5] {import-unused} wa= rning: identifier `OBJECT-GROUP' imported from module `SNMPv2-CONF'= is never used
mibs/MPLS-MLDP-STD-MIB.my:7: [5] {import-unused} w= arning: identifier `NOTIFICATION-GROUP' imported from module `SNMPv2-CO= NF' is never used
mibs/MPLS-MLDP-STD-MIB.my:9: [5] {import-un= used} warning: identifier `TruthValue' imported from module `SNMPv2-TC&= #39; is never used
mibs/MPLS-MLDP-STD-MIB.my:9: [5] {import-unuse= d} warning: identifier `RowStatus' imported from module `SNMPv2-TC'= is never used
mibs/MPLS-MLDP-STD-MIB.my:9: [5] {import-unused} w= arning: identifier `StorageType' imported from module `SNMPv2-TC' i= s never used
mibs/MPLS-MLDP-STD-MIB.my:21: [5] {import-unused} wa= rning: identifier `IndexIntegerNextFree' imported from module `DIFFSERV= -MIB' is never used
mibs/MPLS-MLDP-STD-MIB.my:27: [5] {import= -unused} warning: identifier `mplsLdpStdMIB' imported from module `MPLS= -LDP-STD-MIB' is never used
mibs/MPLS-MLDP-STD-MIB.my:28: [5]= {import-unused} warning: identifier `mplsLdpSessionStatsEntry' importe= d from module `MPLS-LDP-STD-MIB' is never used



E: f(MPLS-MLDP-STD-MIB.my), (833,33) Sequenc= e "MplsMldpFecUpstreamSessEntry" is referenced, but not defined
E: f(MPLS-MLDP-STD-MIB.my), (862,4) Sequence "MplsMLdpFecUpst= reamSessEntry" is defined, but not referenced

JEL:=C2=A0 same comment as above, typo=C2=A0 (MplsMldp with a lower case &= quot;l")



E: f(M= PLS-MLDP-STD-MIB.my), (872,4) Item "mplsMldpFecUpstreamSessFecIndex&qu= ot; must be in sequence for row "mplsMldpFecUpstreamSessEntry"
E: f(MPLS-MLDP-STD-MIB.my), (884,4) Item "mplsMldpFecUpstreamS= essInSegIndex" must be in sequence for row "mplsMldpFecUpstreamSe= ssEntry"
E: f(MPLS-MLDP-STD-MIB.my), (897,5) Item "mpls= MldpFecUpstreamSessPrimary" must be in sequence for row "mplsMldp= FecUpstreamSessEntry"
E: f(MPLS-MLDP-STD-MIB.my), (911,5) It= em "mplsMldpFecUpstreamSessActive" must be in sequence for row &q= uot;mplsMldpFecUpstreamSessEntry"
E: f(MPLS-MLDP-STD-MIB.my)= , (927,4) Item "mplsMldpFecUpstreamSessPackets" must be in sequen= ce for row "mplsMldpFecUpstreamSessEntry"
E: f(MPLS-MLD= P-STD-MIB.my), (939,4) Item "mplsMldpFecUpstreamSessBytes" must b= e in sequence for row "mplsMldpFecUpstreamSessEntry"
E:= f(MPLS-MLDP-STD-MIB.my), (951,4) Item "mplsMldpFecUpstreamSessDiscont= inuityTime" must be in sequence for row "mplsMldpFecUpstreamSessE= ntry"
W: f(MPLS-MLDP-STD-MIB.my), (100,4) Item "mplsMld= pP2mpCapable" is not contained in any group defined in the current mod= ule
W: f(MPLS-MLDP-STD-MIB.my), (115,3) Item "mplsMldpMp2mpC= apable" is not contained in any group defined in the current module
W: f(MPLS-MLDP-STD-MIB.my), (130,3) Item "mplsMldpMbbCapable&q= uot; is not contained in any group defined in the current module
= W: f(MPLS-MLDP-STD-MIB.my), (147,6) Item "mplsMldpMbbTime" is not= contained in any group defined in the current module
W: f(MPLS-M= LDP-STD-MIB.my), (159,4) Item "mplsMldpNumFecs" is not contained = in any group defined in the current module
W: f(MPLS-MLDP-STD-MIB= .my), (168,4) Item "mplsMldpNumFecsActive" is not contained in an= y group defined in the current module
W: f(MPLS-MLDP-STD-MIB.my),= (178,4) Item "mplsMldpPlrCapable" is not contained in any group = defined in the current module
W: f(MPLS-MLDP-STD-MIB.my), (196,4)= Item "mplsMldpMptCapable" is not contained in any group defined = in the current module
W: f(MPLS-MLDP-STD-MIB.my), (211,4) Item &q= uot;mplsMldProtLsrCapable" is not contained in any group defined in th= e current module
W: f(MPLS-MLDP-STD-MIB.my), (226,4) Item "m= plsMldProtNodeProtCapable" is not contained in any group defined in th= e current module
W: f(MPLS-MLDP-STD-MIB.my), (277,6) Item "m= plsLdpPeerLdpId" is not contained in any group defined in the current = module
W: f(MPLS-MLDP-STD-MIB.my), (287,6) Item "mplsLdpPeer= Capability" is not contained in any group defined in the current modul= e
W: f(MPLS-MLDP-STD-MIB.my), (366,6) Item "mplsMldpSessionS= tatsNumFecsSent" is not contained in any group defined in the current = module
W: f(MPLS-MLDP-STD-MIB.my), (382,6) Item "mplsMldpSes= sionStatsNumMbbReqSentState" is not contained in any group defined in = the current module
W: f(MPLS-MLDP-STD-MIB.my), (396,6) Item "= ;mplsMldpSessionStatsNumFecsRcvd" is not contained in any group define= d in the current module
W: f(MPLS-MLDP-STD-MIB.my), (412,5) Item = "mplsMldpSessionStatsNumMbbReqRcvdState" is not contained in any = group defined in the current module
W: f(MPLS-MLDP-STD-MIB.my), (= 424,5) Item "mplsMldpSessionStatsNumMbbResetAckByTimer" is not co= ntained in any group defined in the current module
W: f(MPLS-MLDP= -STD-MIB.my), (492,6) Item "mplsMldpFecType" is not contained in = any group defined in the current module
W: f(MPLS-MLDP-STD-MIB.my= ), (511,6) Item "mplsMldpFecRootAddrType" is not contained in any= group defined in the current module
W: f(MPLS-MLDP-STD-MIB.my), = (526,6) Item "mplsMldpFecRootAddr" is not contained in any group = defined in the current module
W: f(MPLS-MLDP-STD-MIB.my), (543,6)= Item "mplsMldpFecOpaqueType" is not contained in any group defin= ed in the current module
W: f(MPLS-MLDP-STD-MIB.my), (565,7) Item= "mplsMldpFecOpaqueGenLspId" is not contained in any group define= d in the current module
W: f(MPLS-MLDP-STD-MIB.my), (579,6) Item = "mplsMldpFecOpaqueTransitSourceOrBidirAddrType" is not contained = in any group defined in the current module
W: f(MPLS-MLDP-STD-MIB= .my), (595,6) Item "mplsMldpFecOpaqueTransitSourceOrBidirAddr" is= not contained in any group defined in the current module
W: f(MP= LS-MLDP-STD-MIB.my), (609,6) Item "mplsMldpFecOpaqueTransitGroupAddrTy= pe" is not contained in any group defined in the current module
<= div>W: f(MPLS-MLDP-STD-MIB.my), (624,6) Item "mplsMldpFecOpaqueTransit= GroupAddr" is not contained in any group defined in the current module=


--001a113cf468df1718055aa3f6e0-- From nobody Sat Oct 21 09:15:43 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 1A4E5132055 for ; Sat, 21 Oct 2017 09:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 SIIQevj5lH3h for ; Sat, 21 Oct 2017 09:15:39 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 73D7413202D for ; Sat, 21 Oct 2017 09:15:39 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id z19so21770512qtg.11 for ; Sat, 21 Oct 2017 09:15:39 -0700 (PDT) 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=4eq7QS/lf1pVzTtu6igfDBAS8fSJikHiAC+A7XvXM30=; b=uZIEIu2NhQcElO8+jRpx9SmvdDgTFNHwvQU+PdE+wIZTSX54wuSbgMK6panPJ6TXai vbUBApuKg71l7ynv9LJamPU/36lsEwHAa0zBXt2bC+gJiuHH1F//4IH9dIJfJSVsyPB7 l4x4Th6dO9bM7I3ab17TotrTC/1gXgFAdKBtdgTdLgA3tF4tp4XFSmQXyq/Wjg8yLqZQ lSr0fyVqR4QNBKCEaPgXoSlJ/QE0aYgN2rqLBFRdymqnAbm5RoXP0fJWsTKx+Y7hj/mO cG210UY0mZS9teqV2/zRZxO9rte+MZrMs7UYCcEVqYNIDY4YDFTx8EXngG2nYsvT3DVx fmwA== 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=4eq7QS/lf1pVzTtu6igfDBAS8fSJikHiAC+A7XvXM30=; b=nC8EqkPEarcA49onxnnXRvwxtVqGbs70QeJsWf03AFvZfldt47w+hmaCOY7M79ez4K 7pSX5CAxbizfzxKUjKkavRgXtat2m2oc6NsvVvNulcY5dm9n5p/g3EVpjZ1F1K0iYNXL mwRInWjnn1V25BNVbz1gubQct8TAf00VrH2m4+tbO7adw41ogybAT7LdIBlNCsXML+6A R47z1WpEce80Ye3C4hz98ASIzU75+q4bJj21wthE9U2Le0DAAYREOUrA/4z1VZdp/HMR xKhylxwp0Ju1OABlMTKX0zm+/APT2q0f2+sro1HYh6cYxZQDCuAi/Z08pWHtlWmt15Zp 37Wg== X-Gm-Message-State: AMCzsaXhnpv+nAoQn8WdLkkSlX9zh6c0r0qhmeEA85Mr2XthBbCQ72zI 4w+MJZSAGZs/frnteXP4sUdJh4mHJorLRelYyrT3tg== X-Google-Smtp-Source: ABhQp+TmEXOOX7H9WlxC0Qw8reNF4yVo/myMMBQC6yv7umMVmi2B2atXLY4UtwzPySojPZu/i8bfXQoMLlR//i0TfJ8= X-Received: by 10.200.47.169 with SMTP id l38mr11662812qta.272.1508602538276; Sat, 21 Oct 2017 09:15:38 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.102.184 with HTTP; Sat, 21 Oct 2017 09:14:57 -0700 (PDT) From: Hiroshi Tsunoda Date: Sat, 21 Oct 2017 18:14:57 +0200 X-Google-Sender-Auth: plfRlFJBM7c25JoZcsy-JMH8qwg 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: [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: Sat, 21 Oct 2017 16:15:42 -0000 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 Tue Oct 31 21:07:44 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 7400313F8AD; Tue, 31 Oct 2017 21:07:37 -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, 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 Ji9e4zCA33aa; Tue, 31 Oct 2017 21:07:35 -0700 (PDT) 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 9A3BF13F8B2; Tue, 31 Oct 2017 21:07:32 -0700 (PDT) Received: from [192.168.0.200] (Lenovo-X1Carbon.win2004.cysol.co.jp [192.168.0.200]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id vA147OHS094241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 1 Nov 2017 13:07:24 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" References: From: Glenn Mansfield Keeni Message-ID: <730a8e1b-2a90-426b-3497-dab406376ebf@cysols.com> Date: Wed, 1 Nov 2017 13:07:19 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Wed, 01 Nov 2017 04:07:38 -0000 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