From nobody Mon Jun 5 03:24:28 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 AA5E7129404; Mon, 5 Jun 2017 03:24:26 -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 F6AcEwQbyrok; Mon, 5 Jun 2017 03:24:24 -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 C7CDF129431; Mon, 5 Jun 2017 03:24:23 -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 v55AOFim027586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Jun 2017 19:24:15 +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: <56E7D219.7000902@orange.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> From: Glenn Mansfield Keeni Message-ID: <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com> Date: Mon, 5 Jun 2017 19:24:10 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 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] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 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, 05 Jun 2017 10:24:26 -0000 Dear Tsuno/Zhang, Thanks for the good work. The document readability is vastly improved. The following are the comments on draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt Glenn 0. The MIBs L2L3-VPN-MCAST-TC-MIB and L2L3-VPN-MCAST-MIB compile OK. There are level-5 warnings mibs/L2L3-VPN-MCAST-TC-MIB:64: [5] {type-unref} warning: current type `L2L3VpnMcastProviderTunnelType' is not referenced in this module mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-unref} warning: current type `L2L3VpnMcastProviderTunnelId' is not referenced in this module mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-without-format} warning: type `L2L3VpnMcastProviderTunnelId' has no format specification mibs/L2L3-VPN-MCAST-TC-MIB:169: [5] {type-unref} warning: current type `L2L3VpnMcastProviderTunnelPointer' is not referenced in this module mibs/L2L3-VPN-MCAST-TC-MIB:198: [5] {type-unref} warning: current type `L2L3VpnMcastProviderTunnelPointerType' is not referenced in this module These may be ignored. 1. The explanations for the size of the identifiers for each tunneling technology in TC L2L3VpnMcastProviderTunnelId is nicely done. These are aligned with definitions in rfc6514. In noTunnelId (0), -- No tunnel information is there a specific reason to name it 'noTunnelId' instead of 'noTunnelInfo'. 2. The TCs L2L3VpnMcastProviderTunnelPointerType, and L2L3VpnMcastProviderTunnelPointer Are probably not required. The value of the RowPointer [rfc2579] object is ' the name of the instance of the first accessible columnar object in the conceptual row' So the pointer will explicitly contain the name of the table. An auxilliary type object to indicate the table name is not necessary. [This is an oversight on my part. I should have noticed this earlier.] Other Editorials: P-2. Sec-1. 1. para-1 makes tedious reading. Could this be improved? 2. "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)" The usage of the '/' here is unclear. 3. "and L3 VPNs. Therefore, TCs and MOs defined" The context of the 'Therefore' is not clear. 4. "The are two type" Probably s/The/There/ ? On 2017/05/26 21:25, Hiroshi Tsunoda wrote: > Dear Glenn, > > Thank you for your thorough review and waiting for the updated. > > I posted a new revision taking into account your latest comments. > In the new revision, all of your comments are addressed. > I also revised the draft to improve the readability. > > Please see some notes below. > > URL: > https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt > Htmlized(1): > https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 > Htmlized(2): > https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-08 > > 2017-05-02 14:44 GMT+02:00 Hiroshi Tsunoda : >> 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni : >>> Dear Tsuno/Zhang >>> Thanks for waiting. The review of >>> draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. >>> >>> Glenn >>> >>> C1. Abstract: >>> The draft now defines 2 MIB modules. Please revise the abstract >>> and probably the title of the document too. > > Fixed. > >>> C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. >>> (Three {type-unref} warnings are there, may be ignored.) > > I have confirmed that the latest version of MIB modules can also be > compiled successfully. > >>> C3. Page 4: >>> s/3. Summary of MIB Module/ >>> 3. Summary of MIB Modules/ > > Fixed. > >>> C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>> s/"Denotes a pointer to the row pertaining to a table entry/ >>> /"This textual convention represents a pointer to a row in >>> the table represented by the following object of type >>> L2L3VpnMcastProviderTunnelPointerType./ > > Fixed. > >>> C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>> The explanation in the last paragraph seems out of place. >>> It may be removed. > > Fixed. > >>> C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION >>> it is unclear when the value 'null(0)' will be used. >>> Is this allowed only when the corresponding object of type >>> L2L3VpnMcastProviderTunnelPointer has a value that is a >>> zero-length string ? If yes, please make that clear. > > 'null(0)' is the default value and indicates that the corresponding > L2L3VpnMcastProviderTunnelPointer object is not assigned. > In the new revision, this point is described clearly. > >>> C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION >>> s/created by a PE router/maintained by a PE router/ > > Fixed. > >>> C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId >>> Do you really want to keep this object in L2L3-VPN-MCAST-MIB. >>> It will change every time a new "tunnel type" is added to >>> L2L3VpnMcastProviderTunnelType. That will defeat the purpose >>> of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB >>> It may be a good idea to define a textual convention like >>> L2L3VpnMcastPmsiTunnelAttributeId >>> in the L2L3-VPN-MCAST-TC-MIB and use that textual convention >>> in the L2L3-VPN-MCAST-MIB > > Thank you for your suggestion. I revised the definition according to > your suggestion. > >>> C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION >>> A. s/Thus, the size of this object is 16 octets in IPv4/ >>> Thus, the size of this object is 8 octets in IPv4/ > > Fixed. > >>> B. The last 2 paragraphs do not tie up well with the previous >>> paragraphs in the DESCRIPTION. > > Those 2 paragraphs are removed in the new revision. > >>> C. In the last paragraph >>> "this object is a pair of source and group IP addresses" >>> is unlcear. Please clarify. > > Fixed. In the new revision, this point is described as follows. > > "the corresponding Tunnel Identifier is composed of > the source IP address and the group IP address." > >>> C10. Page 15: Security Considerations >>> I would think that any field that reveals information about >>> a Multicast VPN and/or its members is sensitive. >>> Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal >>> information about the participating members? If yes, it must >>> be marked as sensitive. > > I revised this point according to your suggestion. > >>> C11. Editorial: >>> >>> A. This does not pertain to the MIBs as such, >>> but I am uncomfortable with the several variations >>> of the phrase >>> "Layer 2 and Layer 3 Virtual Private Networks (VPN) >>> that support multicast" >>> that appears in the text. I do not have a solution >>> on hand but it would be perhaps be more readable to >>> define and use a simple name/notation the beast for >>> which the MIB is being designed (e.g. "L2L3VPNMCast"). >>> >>> B. Same with the phrase >>> "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private >>> Network) >>> it would be probably be easier on the reader if an >>> abbreviation like L2L3VPNs was used where ever >>> applicable. > > Thank you for your comments. > In the new reivsion the abbreviation "L2L3VPNMCast" > is defined and used throughout the draft. > >>> C12. P2:Para4: s/within MIB module specifications//; > > Fixed. > >>> C13. General: >>> A. The DESCRIPTION clauses could do would some more >>> packing. (Too much space at the end of lines) >>> B. Please check the articles a/an/the once again. Some >>> usages do not seem right to me. > > Fixed. > > Sincerely yours, > > -- tsuno > From nobody Mon Jun 5 07:41:05 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 52E98129415 for ; Mon, 5 Jun 2017 07:41:03 -0700 (PDT) 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 mj9XABasbUWR for ; Mon, 5 Jun 2017 07:41:00 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 597961293D9 for ; Mon, 5 Jun 2017 07:41:00 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l14so54957413ywk.1 for ; Mon, 05 Jun 2017 07:41:00 -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=jPbVBbfl5yZNvZ+ce8wJ4xztxujWMnKEAHQQCrld17A=; b=KspTbvSlW/5FKsCeUvkn6haDy9FYkFNQwgFNuv80Kh0+eW1nN+9z0DIYoJspA/TaQn LtQY8KysFlUukylfONGNTAnYXY9xWhaYQXRPS/fHpGrxsmH2PElBVRnylaCXX2H/HqCR Cf2uxlDS2JjFKQQLYw+rF6LQKrrWE8m4HRzQp6Yfm//GvjTVyJJ6bWJc3ojo/qq9SCxD Jrq5EsmxA0yJfs2hTDNZaChRqp0RpbQikK6R1xsGXRLWuRzn2Db7/B0S945+NKA/4BqD pwABTSHZTRslJFyQrDAToAgyxwTQNmIjfDtGbtvceCJ1VbVeBq+EIC2S8myXBcU6ojCq 9Org== 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=jPbVBbfl5yZNvZ+ce8wJ4xztxujWMnKEAHQQCrld17A=; b=hnmM/xu7zcQb6e7UPxfIYkhYzDOUXT56QOutSxWPAsKAwRXYJbvGgs3RH7u5obpvKf 7qq2Xq9f3qLMbPmxuoUCh/xrq+bKIn9CHtxbNFDrjnMFURdkyqAATErNZ9bN5ULqr5/q 5adVzVrwL+dbYVkDh0QDjs/m8R7dMnZecNVJKIEfAn5+CXcQbTM33sg3CmRa906L6SFr KGX4ps/Rci2yMr7N5kur1FibNIhS0/z/QVxhH0eJx7JXGZaXi1Gja7ICpMPfm/fhnCrM x1d0L0WVI62wGlDuKlTlIiCMk1wLwm2/ZvYPUhZdGPviV/D2CX0sd2VDCd1rrjpg+/0w scfA== X-Gm-Message-State: AKS2vOzDQFnqqY+OUCvUGMPHkoaWnxnixvoJ/njK73yylZYcNp7mQeNO MnjN/ZzS/NBRmWz/Bi9L16mSlY00nJDa X-Received: by 10.55.154.142 with SMTP id c136mr9204803qke.123.1496673659217; Mon, 05 Jun 2017 07:40:59 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.101.229 with HTTP; Mon, 5 Jun 2017 07:40:18 -0700 (PDT) In-Reply-To: <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com> References: <56E7D219.7000902@orange.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com> From: Hiroshi Tsunoda Date: Mon, 5 Jun 2017 16:40:18 +0200 X-Google-Sender-Auth: RKAiA8LlSr_WNGUirZC39j9h2Ao 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] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 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, 05 Jun 2017 14:41:03 -0000 Dear Glenn, Thank you very much for your review. I am going to resubmit a revision as soon as possible. Please wait for a moment regarding MVPN-MIB. -- tsuno 2017-06-05 12:24 GMT+02:00 Glenn Mansfield Keeni : > Dear Tsuno/Zhang, > Thanks for the good work. The document readability is > vastly improved. > The following are the comments on > draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt > > Glenn > > 0. The MIBs > L2L3-VPN-MCAST-TC-MIB and > L2L3-VPN-MCAST-MIB > compile OK. There are level-5 warnings > mibs/L2L3-VPN-MCAST-TC-MIB:64: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelType' is not referenced in this module > mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelId' is not referenced in this module > mibs/L2L3-VPN-MCAST-TC-MIB:90: [5] {type-without-format} warning: type > `L2L3VpnMcastProviderTunnelId' has no format specification > mibs/L2L3-VPN-MCAST-TC-MIB:169: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelPointer' is not referenced in this module > mibs/L2L3-VPN-MCAST-TC-MIB:198: [5] {type-unref} warning: current type > `L2L3VpnMcastProviderTunnelPointerType' is not referenced in this module > > These may be ignored. > > 1. The explanations for the size of the identifiers for each tunneling > technology in TC L2L3VpnMcastProviderTunnelId > is nicely done. These are aligned with definitions in rfc6514. > In > noTunnelId (0), -- No tunnel information > is there a specific reason to name it 'noTunnelId' instead of > 'noTunnelInfo'. > > 2. The TCs > L2L3VpnMcastProviderTunnelPointerType, and > L2L3VpnMcastProviderTunnelPointer > Are probably not required. The value of the RowPointer [rfc2579] > object is ' the name of the instance of the first > accessible columnar object in the conceptual row' > So the pointer will explicitly contain the name of the table. > An auxilliary type object to indicate the table name is not > necessary. > [This is an oversight on my part. I should have noticed this earlier.] > > > Other Editorials: > P-2. Sec-1. > 1. para-1 makes tedious reading. Could this be improved? > > 2. "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)" > The usage of the '/' here is unclear. > > 3. "and L3 VPNs. Therefore, TCs and MOs defined" > The context of the 'Therefore' is not clear. > > 4. "The are two type" > Probably s/The/There/ ? > > > > > > > On 2017/05/26 21:25, Hiroshi Tsunoda wrote: >> >> Dear Glenn, >> >> Thank you for your thorough review and waiting for the updated. >> >> I posted a new revision taking into account your latest comments. >> In the new revision, all of your comments are addressed. >> I also revised the draft to improve the readability. >> >> Please see some notes below. >> >> URL: >> >> https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-08.txt >> Htmlized(1): >> https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 >> Htmlized(2): >> >> https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-08 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-08 >> >> 2017-05-02 14:44 GMT+02:00 Hiroshi Tsunoda : >>> >>> 2017-05-01 12:32 GMT+02:00 Glenn Mansfield Keeni : >>>> >>>> Dear Tsuno/Zhang >>>> Thanks for waiting. The review of >>>> draft-ietf-bess-l2l3-vpn-mcast-mib-07 follows. >>>> >>>> Glenn >>>> >>>> C1. Abstract: >>>> The draft now defines 2 MIB modules. Please revise the abstract >>>> and probably the title of the document too. >> >> >> Fixed. >> >>>> C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. >>>> (Three {type-unref} warnings are there, may be ignored.) >> >> >> I have confirmed that the latest version of MIB modules can also be >> compiled successfully. >> >>>> C3. Page 4: >>>> s/3. Summary of MIB Module/ >>>> 3. Summary of MIB Modules/ >> >> >> Fixed. >> >>>> C4. Page 6: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>>> s/"Denotes a pointer to the row pertaining to a table entry/ >>>> /"This textual convention represents a pointer to a row in >>>> the table represented by the following object of type >>>> L2L3VpnMcastProviderTunnelPointerType./ >> >> >> Fixed. >> >>>> C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION >>>> The explanation in the last paragraph seems out of place. >>>> It may be removed. >> >> >> Fixed. >> >>>> C6 Page 7: L2L3VpnMcastProviderTunnelPointerType DESCRIPTION >>>> it is unclear when the value 'null(0)' will be used. >>>> Is this allowed only when the corresponding object of type >>>> L2L3VpnMcastProviderTunnelPointer has a value that is a >>>> zero-length string ? If yes, please make that clear. >> >> >> 'null(0)' is the default value and indicates that the corresponding >> L2L3VpnMcastProviderTunnelPointer object is not assigned. >> In the new revision, this point is described clearly. >> >>>> C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION >>>> s/created by a PE router/maintained by a PE router/ >> >> >> Fixed. >> >>>> C8. Page 12: l2L3VpnMcastPmsiTunnelAttributeId >>>> Do you really want to keep this object in L2L3-VPN-MCAST-MIB. >>>> It will change every time a new "tunnel type" is added to >>>> L2L3VpnMcastProviderTunnelType. That will defeat the purpose >>>> of separating L2L3-VPN-MCAST-TC-MIB from L2L3-VPN-MCAST-MIB >>>> It may be a good idea to define a textual convention like >>>> L2L3VpnMcastPmsiTunnelAttributeId >>>> in the L2L3-VPN-MCAST-TC-MIB and use that textual convention >>>> in the L2L3-VPN-MCAST-MIB >> >> >> Thank you for your suggestion. I revised the definition according to >> your suggestion. >> >>>> C9. Page 13: l2L3VpnMcastPmsiTunnelAttributeId DESCRIPTION >>>> A. s/Thus, the size of this object is 16 octets in IPv4/ >>>> Thus, the size of this object is 8 octets in IPv4/ >> >> >> Fixed. >> >>>> B. The last 2 paragraphs do not tie up well with the previous >>>> paragraphs in the DESCRIPTION. >> >> >> Those 2 paragraphs are removed in the new revision. >> >>>> C. In the last paragraph >>>> "this object is a pair of source and group IP addresses" >>>> is unlcear. Please clarify. >> >> >> Fixed. In the new revision, this point is described as follows. >> >> "the corresponding Tunnel Identifier is composed of >> the source IP address and the group IP address." >> >>>> C10. Page 15: Security Considerations >>>> I would think that any field that reveals information about >>>> a Multicast VPN and/or its members is sensitive. >>>> Does the l2L3VpnMcastPmsiTunnelAttributeId field reveal >>>> information about the participating members? If yes, it must >>>> be marked as sensitive. >> >> >> I revised this point according to your suggestion. >> >>>> C11. Editorial: >>>> >>>> A. This does not pertain to the MIBs as such, >>>> but I am uncomfortable with the several variations >>>> of the phrase >>>> "Layer 2 and Layer 3 Virtual Private Networks (VPN) >>>> that support multicast" >>>> that appears in the text. I do not have a solution >>>> on hand but it would be perhaps be more readable to >>>> define and use a simple name/notation the beast for >>>> which the MIB is being designed (e.g. "L2L3VPNMCast"). >>>> >>>> B. Same with the phrase >>>> "Layer 2 (L2) and Layer 3 (L3) VPN (Virtual Private >>>> Network) >>>> it would be probably be easier on the reader if an >>>> abbreviation like L2L3VPNs was used where ever >>>> applicable. >> >> >> Thank you for your comments. >> In the new reivsion the abbreviation "L2L3VPNMCast" >> is defined and used throughout the draft. >> >>>> C12. P2:Para4: s/within MIB module specifications//; >> >> >> Fixed. >> >>>> C13. General: >>>> A. The DESCRIPTION clauses could do would some more >>>> packing. (Too much space at the end of lines) >>>> B. Please check the articles a/an/the once again. Some >>>> usages do not seem right to me. >> >> >> Fixed. >> >> Sincerely yours, >> >> -- tsuno >> > From nobody Wed Jun 21 10:36:05 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 30E36128C83 for ; Wed, 21 Jun 2017 10:35:51 -0700 (PDT) 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=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 vprqjaurMrGV for ; Wed, 21 Jun 2017 10:35:46 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 84A3E128BB7 for ; Wed, 21 Jun 2017 10:35:46 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id p21so16381494qke.3 for ; Wed, 21 Jun 2017 10:35:46 -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=RsZ9ICNHzfQ9ZuMvFJBmUbcvTc8OiW6HURybyXMKDLI=; b=qWTnovLI/Iuj+ANREE3otKNn84vKfaTeSvF3R3bn653+hfzDti2OjXfrLcBdOfFQJQ n4KvxFLfprfKmgOc7II1hYmEIbCYzeGPO2TlfilsJJtpBuRixj0dSLM4H7j9begvnwcB wk3uK+mZgXumwtnGU+oN2SSHopo1ledaDG0e/2s+mIL7rnTQw3SH6Ud0NpZE4/T+fpIz 8mKNwO/v9wVho0mIJt2wahCQjYPc+HArT6RdD+Vt4OdNbXNUY5u9XoG/RDW7bf4/Bj+e Db55m/h3o256GZeutvqDmnASqTujkJyELVL1SrOQQktgCqAzgu0ZE1UA6yOQpkrljFXo uDUw== 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=RsZ9ICNHzfQ9ZuMvFJBmUbcvTc8OiW6HURybyXMKDLI=; b=jeuYl45gX4HezKFi4X/vPMBX8IU5VgvVgCKRUZk4CUCr7YVcl7+88fQl/cV2uT2hCf Pl/4GlAwPtwkb3jNuubMXcpAq2LOxrfb0imXaDPiGMUgFaE26DrMyYMX9jb55tC/npJ6 5Wj5dDCrA70PTvq/tg04x1E7yJb1X6hXT5aOxJSOdUm7f7z5q3bta8vL+2Ne62jAXKv5 t4h+nzJ+QthOoXfaG4hVjetgslJjzfPwFrtIeMRrXGpNv+gGti7AGUtFslSl/APb+bcc Woha5RxP9ecp/o8Bx51WpvxXmlviCLdZnYApSay87tVResV3kqIqCP+yXdAEqOtC6hCx EQgQ== X-Gm-Message-State: AKS2vOxF93WLW4BSm6ikv1yzQcKq3Ahi7k90d3cbSZ5MdukdXURPyQPf eMTLVtKPdzDABo1v0oc4vTKKMHgllu2x X-Received: by 10.55.15.9 with SMTP id z9mr39587024qkg.195.1498066545630; Wed, 21 Jun 2017 10:35:45 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.101.229 with HTTP; Wed, 21 Jun 2017 10:35:05 -0700 (PDT) In-Reply-To: <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com> References: <56E7D219.7000902@orange.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> <3bb4da95-ce97-385d-ae59-963d8c6f3db0@cysols.com> From: Hiroshi Tsunoda Date: Wed, 21 Jun 2017 19:35:05 +0200 X-Google-Sender-Auth: ktIZQCqXEuWgdXu8_UaHNInNOhs 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] MIBDoc review of draft-ietf-bess-l2l3-vpn-mcast-mib-07 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, 21 Jun 2017 17:35:51 -0000 Dear Glenn, Thank you for your comments. I posted a new revision (-09) as follows. URL: https://www.ietf.org/internet-drafts/draft-ietf-bess-l2l3-vpn-mcast-mib-09.txt Htmlized: https://tools.ietf.org/html/draft-ietf-bess-l2l3-vpn-mcast-mib-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-bess-l2l3-vpn-mcast-mib-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-l2l3-vpn-mcast-mib-09 In the new revision, all of your comments are addressed and the following additional changes are made. - Update the definition and description of L2L3VpnMcastProviderTunnelType Describe the enumerated values and the corresponding tunnel type. I added new valule, transportTunnel (8) defined in [RFC7524]. - Add some description related to transportTunnel (8) into the defi L2L3VpnMcastProviderTunnelId - Update the description of l2L3VpnMcastPmsiTunnelAttributeFlags according to [RFC7902] - Added a new object, l2L3VpnMcastPmsiTunnelAttributeAddlFlags. This is defined in [RFC7902] I also removed some paragraph from 1.1 Terminology section, because those seem verbose. Please see some other notes below. 2017-06-05 12:24 GMT+02:00 Glenn Mansfield Keeni : > 1. The explanations for the size of the identifiers for each tunneling > technology in TC L2L3VpnMcastProviderTunnelId > is nicely done. These are aligned with definitions in rfc6514. > In > noTunnelId (0), -- No tunnel information > is there a specific reason to name it 'noTunnelId' instead of > 'noTunnelInfo'. Fixed. > 2. The TCs > L2L3VpnMcastProviderTunnelPointerType, and > L2L3VpnMcastProviderTunnelPointer > Are probably not required. The value of the RowPointer [rfc2579] > object is ' the name of the instance of the first > accessible columnar object in the conceptual row' > So the pointer will explicitly contain the name of the table. > An auxilliary type object to indicate the table name is not > necessary. > [This is an oversight on my part. I should have noticed this earlier.] These TCs were removed and related descriptions in other parts in the document were updated. > Other Editorials: > P-2. Sec-1. > 1. para-1 makes tedious reading. Could this be improved? > > 2. "Border Gateway Protocol/ MultiProtocol Label Switching (BGP/MPLS)" > The usage of the '/' here is unclear. Updated. In the new revision, BGP/MPLS VPN is explained in para-1, and multicast support in BGP/MPLS Layer 2 and Layer 3 is explained in para-2 separately. > 3. "and L3 VPNs. Therefore, TCs and MOs defined" > The context of the 'Therefore' is not clear. Fixed. I removed the related sentence because it seemed not required already. > 4. "The are two type" > Probably s/The/There/ ? Fixed. Thank you for pointing it out. -- tsuno