From nobody Mon May 1 03:34:31 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 F1B5B128BA2; Mon, 1 May 2017 03:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zz85c2F8kbm; Mon, 1 May 2017 03:34:20 -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 570511293E0; Mon, 1 May 2017 03:32:36 -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 v41AWQna007825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 May 2017 19:32:27 +0900 (JST) (envelope-from glenn@cysols.com) To: Hiroshi Tsunoda References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> Cc: Mach Chen , "mib-doctors@ietf.org" , "Jeffrey (Zhaohui) Zhang" , "EXT - thomas.morin@orange.com" , Martin Vigoureux , "bess@ietf.org" From: Glenn Mansfield Keeni Message-ID: <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> Date: Mon, 1 May 2017 19:32:22 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> Content-Type: text/plain; charset=iso-2022-jp; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Archived-At: Subject: [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, 01 May 2017 10:34:22 -0000 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. C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. (Three {type-unref} warnings are there, may be ignored.) C3. Page 4: s/3. Summary of MIB Module/ 3. Summary of MIB Modules/ 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./ C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION The explanation in the last paragraph seems out of place. It may be removed. 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. C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION s/created by a PE router/maintained by a PE router/ 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 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/ B. The last 2 paragraphs do not tie up well with the previous paragraphs in the DESCRIPTION. C. In the last paragraph "this object is a pair of source and group IP addresses" is unlcear. Please clarify. 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. 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. C12. P2:Para4: s/within MIB module specifications//; 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. From nobody Tue May 2 05:48:18 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 39A82124217 for ; Tue, 2 May 2017 05:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCJjqOOBnoY9 for ; Tue, 2 May 2017 05:48:07 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BB41315C6 for ; Tue, 2 May 2017 05:44:56 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id r189so15014891qkf.1 for ; Tue, 02 May 2017 05:44:56 -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=lMPVHHyIXuM+CYGb63QhRhoRf0yBDEfrwvw4HBrrPks=; b=eORROj34Wz5GUVgmScgZfBXkptQNoSmrxCg3+DBp2ihtw/bIoCRvNHDGljw3kIcrTz sP6nBdd2cLd88PYtTkBEU49lDK40CWftJUfLM+vWW0u6HXwjTYnXYZgVrBeF9t/oLl0v hfZ5rJzs/9TiB5YLjy5YKHeRdxxTAJgCPm9eZzeaNaZcW567SSkpBNEwgsTHjWos8a1E 5l+4yAHxiXRs0rhhKUZpzmoru3s2ZGIOoVM5g0pqma7orfPYBRD+X1ik72k74a+giwvt 8WSef/AiNOilTOP67ciIq03FncpPZrPRwz+Mpn+a7Xkg6pjwn82AxL3Os6qVqvf/Xm7t BJ8g== 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=lMPVHHyIXuM+CYGb63QhRhoRf0yBDEfrwvw4HBrrPks=; b=F7w9DbQp+QLkAYt14DqCZGg4bvtMOUVRJwyEG3Brp+cJ0LmcXfqWnUgW87IhdMJXgv OLwvZSaCwQsMqEA4XfyA05GHt7CkeJJl5tABTS/3iI3shP79BQYFrWm+/pwuRyMO8Cvw T0goN3LzNLVpgnqkc8Rf8uDk4dnYPhwFmDqDy0ZS0gmUmZoq+XkopsYcieoXvrYBGclO oeyfJirnmn/jwFySs/snc4oxpwaY2f1/XF8tGm5Z0P3zQiOzUTCC1YLgS8z2+FblpqGo k1gnHOFr6mZ85GzVArJv7qSVc89C00JGITzKJHKDc+yGOIVhg9JHdsZvgd07C9CRtAGU W6RA== X-Gm-Message-State: AN3rC/5wzjkiXoS66n0MFq/rGJT5UIcWgXfWlqIS4HsVKP9+cMqhcuVd yL4L09Oi3va5kn8BEd3vmIogIrXc0htw X-Received: by 10.55.113.134 with SMTP id m128mr25448371qkc.258.1493729095315; Tue, 02 May 2017 05:44:55 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.30.52 with HTTP; Tue, 2 May 2017 05:44:14 -0700 (PDT) In-Reply-To: <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> From: Hiroshi Tsunoda Date: Tue, 2 May 2017 14:44:14 +0200 X-Google-Sender-Auth: j6ZyOQim-7mU7tkJNF96zyYEFfU 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: Tue, 02 May 2017 12:48:09 -0000 Dear Glenn, Thank you very much for your thorough review. I have greatly appreciated it. I am going to check and update the draft taking into account your comments. I try to submit the updated draft by the end of next week. Best regards, -- tsuno 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. > > C2. The MIBs (L2L3-VPN-MCAST-TC-MIB, L2L3-VPN-MCAST-MIB) compile OK. > (Three {type-unref} warnings are there, may be ignored.) > > C3. Page 4: > s/3. Summary of MIB Module/ > 3. Summary of MIB Modules/ > > 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./ > > C5. Page 7: L2L3VpnMcastProviderTunnelPointer DESCRIPTION > The explanation in the last paragraph seems out of place. > It may be removed. > > 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. > > C7. Page 9: l2L3VpnMcastPmsiTunnelAttributeTable DESCRIPTION > s/created by a PE router/maintained by a PE router/ > > 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 > > 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/ > B. The last 2 paragraphs do not tie up well with the previous > paragraphs in the DESCRIPTION. > C. In the last paragraph > "this object is a pair of source and group IP addresses" > is unlcear. Please clarify. > > 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. > > 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. > > C12. P2:Para4: s/within MIB module specifications//; > > 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. > > > > From nobody Tue May 2 06:40:34 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 0C3A113159B for ; Tue, 2 May 2017 06:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.623 X-Spam-Level: X-Spam-Status: No, score=-12.623 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 37ROzekXBy2V for ; Tue, 2 May 2017 06:40:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20D212009C for ; Tue, 2 May 2017 06:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4529; q=dns/txt; s=iport; t=1493732207; x=1494941807; h=subject:references:to:cc:from:message-id:date: mime-version:in-reply-to; bh=yZmoYhPrqkbSGCIGQLlakydnPby25uzf2NvbOjeUwWQ=; b=kIC56qW6FKr+SYS7UKdzAABFgMae/wKgIklHN5va8ZqMFBVTT1gsd+F4 SHKWuDDawSu9uw/x9b8wG3E2rhSRz9Z1ooT+mBiN8YK83bySFz/Yzo94a 0l6hSlLpMy/qhv6Y20REgSpVsIl2qmrPLNU4tuZPSlWbiMlT1gUNMqp0g s=; X-Files: Attached Message Part : 150 X-IronPort-AV: E=Sophos;i="5.37,405,1488844800"; d="scan'208,217";a="652583797" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2017 13:36:46 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v42DaiXj011444; Tue, 2 May 2017 13:36:44 GMT References: <2792DE7D-4C80-4848-8E2B-54EF1DEB29F3@icann.org> To: randy_presuhn@acm.org, Michael MacFaden , Michael MacFaden , "dromasca@gmail.com" , Joan Cucchiara Cc: Benoit Claise , "MIB Doctors (E-mail)" , Terry Manderson , ianfarrer@gmx.com From: Benoit Claise X-Forwarded-Message-Id: <2792DE7D-4C80-4848-8E2B-54EF1DEB29F3@icann.org> Message-ID: Date: Tue, 2 May 2017 15:36:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2792DE7D-4C80-4848-8E2B-54EF1DEB29F3@icann.org> Content-Type: multipart/mixed; boundary="------------30CA4FD62C85F906A3C9D60D" Archived-At: Subject: [MIB-DOCTORS] Fwd: Early review of draft-ietf-softwire-map-mib 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, 02 May 2017 13:40:33 -0000 This is a multi-part message in MIME format. --------------30CA4FD62C85F906A3C9D60D Content-Type: multipart/alternative; boundary="------------855399C5082FC548346B008C" --------------855399C5082FC548346B008C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, Pinging the usual suspects who still accepts to review MIB modules (from https://trac.ietf.org/trac/ops/wiki/mib-doctors-review-history): Mike, Randy, Dan, Joan. The MIB module below is a very short read-only MIB module. Who would have the time to review this one? Note: the main MIB doctor page is at https://www.ietf.org/iesg/directorate/mib-doctors.html Regards, Benoit -------- Forwarded Message -------- Subject: [MIB-DOCTORS] Early review of draft-ietf-softwire-map-mib Date: Thu, 30 Mar 2017 19:29:59 +0000 From: Terry Manderson To: mib-doctors@ietf.org CC: Ian Farrer Hi MIB Friends, As the responsible AD of SOFTWIRE, I am looking for an early review of draft-ietf-softwire-map-mib https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07 Cheers Terry --------------855399C5082FC548346B008C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Dear all,

Pinging the usual suspects who still accepts to review MIB modules (from https://trac.ietf.org/trac/ops/wiki/mib-doctors-review-history): Mike, Randy, Dan, Joan.
The MIB module below is a very short read-only MIB module. Who would have the time to review this one?

Note: the main MIB doctor page is at https://www.ietf.org/iesg/directorate/mib-doctors.html

Regards, Benoit




-------- Forwarded Message --------
Subject: [MIB-DOCTORS] Early review of draft-ietf-softwire-map-mib
Date: Thu, 30 Mar 2017 19:29:59 +0000
From: Terry Manderson <terry.manderson@icann.org>
To: mib-doctors@ietf.org <mib-doctors@ietf.org>
CC: Ian Farrer <ianfarrer@gmx.com> 


Hi MIB Friends,

As the responsible AD of SOFTWIRE, I am looking for an early review of draft-ietf-softwire-map-mib

https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07

Cheers
Terry
--------------855399C5082FC548346B008C-- --------------30CA4FD62C85F906A3C9D60D Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk1JQi1E T0NUT1JTIG1haWxpbmcgbGlzdA0KTUlCLURPQ1RPUlNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWliLWRvY3RvcnMNCg0K --------------30CA4FD62C85F906A3C9D60D-- From nobody Tue May 2 07:54:40 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 768D61316E9 for ; Tue, 2 May 2017 07:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 wOPlnDnqIH1M for ; Tue, 2 May 2017 07:54:37 -0700 (PDT) Received: from lb2-smtp-cloud6.xs4all.net (lb2-smtp-cloud6.xs4all.net [194.109.24.28]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF40B131683 for ; Tue, 2 May 2017 07:50:51 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:4c71:cd2b:4f3e:75a5]) by smtp-cloud6.xs4all.net with ESMTP id FSql1v00D0TlmKh01Sqol1; Tue, 02 May 2017 16:50:49 +0200 To: Benoit Claise , randy_presuhn@acm.org, Michael MacFaden , Michael MacFaden , "dromasca@gmail.com" , Joan Cucchiara References: <2792DE7D-4C80-4848-8E2B-54EF1DEB29F3@icann.org> Cc: "MIB Doctors (E-mail)" , ianfarrer@gmx.com, Terry Manderson From: "Bert Wijnen (IETF)" Message-ID: Date: Tue, 2 May 2017 16:50:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MIB-DOCTORS] Fwd: Early review of draft-ietf-softwire-map-mib 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, 02 May 2017 14:54:39 -0000 I can do this. Maybe not today, but probably this week Bert On 02/05/2017 15:36, Benoit Claise wrote: > Dear all, > > Pinging the usual suspects who still accepts to review MIB modules (from > https://trac.ietf.org/trac/ops/wiki/mib-doctors-review-history): Mike, Randy, Dan, Joan. > The MIB module below is a very short read-only MIB module. Who would have the time to review this one? > > Note: the main MIB doctor page is at https://www.ietf.org/iesg/directorate/mib-doctors.html > > Regards, Benoit > > > > > -------- Forwarded Message -------- > Subject: [MIB-DOCTORS] Early review of draft-ietf-softwire-map-mib > Date: Thu, 30 Mar 2017 19:29:59 +0000 > From: Terry Manderson > To: mib-doctors@ietf.org > CC: Ian Farrer > > > > Hi MIB Friends, > > As the responsible AD of SOFTWIRE, I am looking for an early review of draft-ietf-softwire-map-mib > > https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07 > > Cheers > Terry > > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From nobody Tue May 2 08:13:48 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 C3B4D12EC01 for ; Tue, 2 May 2017 08:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 MrpUe-MzvYQP for ; Tue, 2 May 2017 08:13:45 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119B1126C89 for ; Tue, 2 May 2017 08:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1420; q=dns/txt; s=iport; t=1493737831; x=1494947431; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Bbeul95V5/OEki3HDU0/DOyHI+KhuAzNa8LisETARsE=; b=RN6Z2iSY6F7xC1PUH24ENBIzepDOIxFbmLApt8GaaP5BBrP1eZbJYyZm ohDAQ2qxkb58Lb8SvA12zqzu1rmz/H59SABsH+sVdIPmPqaZaLIrThGxp ejVKTp+F6gAG9AOhjUWAK5s3cK7zSiJTzWOWKnKp/gcLbrKspGzWbou2+ c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AAC8oAhZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhDeBDI4Ac5BalW2CDyELhXgChQcYAQIBAQEBAQEBayiFFQEBAQE?= =?us-ascii?q?DAQE2NgsQCxEDAQIBLicoCAYBDAYCAQGKAgMVDrFWixsBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYBYZfggmCcIJUh1UfAQSdVIcbi3aCAoh5I4ZAjAaIKx84gQouIAg?= =?us-ascii?q?ZFUSGcj42AYkIAQEB?= X-IronPort-AV: E=Sophos;i="5.37,405,1488844800"; d="scan'208";a="652585917" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 May 2017 15:10:28 +0000 Received: from [10.60.67.90] (ams-bclaise-8919.cisco.com [10.60.67.90]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v42FARqA018884; Tue, 2 May 2017 15:10:28 GMT To: "Bert Wijnen (IETF)" , randy_presuhn@acm.org, Michael MacFaden , Michael MacFaden , "dromasca@gmail.com" , Joan Cucchiara References: <2792DE7D-4C80-4848-8E2B-54EF1DEB29F3@icann.org> Cc: "MIB Doctors (E-mail)" , ianfarrer@gmx.com, Terry Manderson From: Benoit Claise Message-ID: <6739958b-84e4-f8c1-cede-2c37a35fec52@cisco.com> Date: Tue, 2 May 2017 17:10:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MIB-DOCTORS] Fwd: Early review of draft-ietf-softwire-map-mib 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, 02 May 2017 15:13:47 -0000 Thanks Bert. https://trac.ietf.org/trac/ops/wiki/mib-doctors-review-history is now updated. Regards, Benoit > I can do this. Maybe not today, but probably this week > > Bert > > On 02/05/2017 15:36, Benoit Claise wrote: >> Dear all, >> >> Pinging the usual suspects who still accepts to review MIB modules (from >> https://trac.ietf.org/trac/ops/wiki/mib-doctors-review-history): >> Mike, Randy, Dan, Joan. >> The MIB module below is a very short read-only MIB module. Who would >> have the time to review this one? >> >> Note: the main MIB doctor page is at >> https://www.ietf.org/iesg/directorate/mib-doctors.html >> >> Regards, Benoit >> >> >> >> >> -------- Forwarded Message -------- >> Subject: [MIB-DOCTORS] Early review of draft-ietf-softwire-map-mib >> Date: Thu, 30 Mar 2017 19:29:59 +0000 >> From: Terry Manderson >> To: mib-doctors@ietf.org >> CC: Ian Farrer >> >> >> >> Hi MIB Friends, >> >> As the responsible AD of SOFTWIRE, I am looking for an early review >> of draft-ietf-softwire-map-mib >> >> https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07 >> >> Cheers >> Terry >> >> >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > . > From nobody Mon May 8 07:02:24 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9BD12948B for ; Mon, 8 May 2017 07:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 3LZfpEzJXWs9 for ; Mon, 8 May 2017 07:02:16 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 449A012948A for ; Mon, 8 May 2017 07:02:15 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:5f4:343c:cbdf:d5d2]) by smtp-cloud2.xs4all.net with ESMTP id Hq2C1v006327dWa01q2DYl; Mon, 08 May 2017 16:02:14 +0200 To: Juergen Schoenwaelder Cc: MIB Doctors From: "Bert Wijnen (IETF)" Message-ID: <6ca4ae08-fa9b-60d8-436b-61515a739f57@bwijnen.net> Date: Mon, 8 May 2017 16:02:12 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MIB-DOCTORS] InetAddress SIZE rules. 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, 08 May 2017 14:02:23 -0000 In https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07 I see: mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddress(SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." ::= { mapRuleEntry 3 } mmmmm, when the InetAddressType is ipv6(2), then my understanding of RFC4001 is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can chime in here? Juergen (or anyone else) can you confirm if my understanding is correct? Thanks, Bert From nobody Mon May 8 07:38:11 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA8412949B for ; Mon, 8 May 2017 07:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.464 X-Spam-Level: * X-Spam-Status: No, score=1.464 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 I4iIFGN3GSJV for ; Mon, 8 May 2017 07:38:08 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07AB129492 for ; Mon, 8 May 2017 07:38:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2C6E6EFE; Mon, 8 May 2017 16:38:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id hxPgOfvpRxLR; Mon, 8 May 2017 16:38:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 May 2017 16:38:05 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0917E2005E; Mon, 8 May 2017 16:38:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9Yp_b7nj7COG; Mon, 8 May 2017 16:38:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C3E62005F; Mon, 8 May 2017 16:38:02 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0A1B13F3D970; Mon, 8 May 2017 16:38:02 +0200 (CEST) Date: Mon, 8 May 2017 16:38:01 +0200 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Cc: MIB Doctors Message-ID: <20170508143801.GB12134@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bert Wijnen (IETF)" , MIB Doctors References: <6ca4ae08-fa9b-60d8-436b-61515a739f57@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6ca4ae08-fa9b-60d8-436b-61515a739f57@bwijnen.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [MIB-DOCTORS] InetAddress SIZE rules. 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, 08 May 2017 14:38:10 -0000 On Mon, May 08, 2017 at 04:02:12PM +0200, Bert Wijnen (IETF) wrote: > In https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07 > I see: > > mapRuleIPv6Prefix OBJECT-TYPE > SYNTAX InetAddress(SIZE (0..16)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The IPv6 prefix defined in mapping rule which will be > assigned to CE. The address type is given by > mapRuleIPv6PrefixType." > ::= { mapRuleEntry 3 } > > > mmmmm, when the InetAddressType is ipv6(2), then my understanding of RFC4001 > is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can chime in here? > > Juergen (or anyone else) can you confirm if my understanding is correct? > It seems the objects in question are always representing IPv6 prefixes, that is, mapRuleIPv6PrefixType is essentially a constant as if it were subtyped to only include the value ipv6(2). The question is whether using the triple (InetAddressType, InetAddress, InetAddressPrefixLength) is really useful and the suggested way of doing things. This must have come up before but I think I garbage collected this part of my memory. Using the triple is good for generic tools, exchanging constants on the other hand is also not very efficient. Right now, I would say that InetAddress(SIZE (0..16)) is consistent with InetAddressType, i.e., the machine readable information says this is a generic Internet address. The other alternative would be to use InetAddressType { ipv6(2) } and InetAddress(SIZE (16)) and then both together indicate to tools that this is by no means a generic Internet address. Doing a mixture of both seems inconsistent - but on the wire you will anyway get InetAddressType { ipv6(2) } and InetAddress(SIZE (16)). Sorry for not providing a clear answer. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon May 8 07:55:54 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 948F31294B8 for ; Mon, 8 May 2017 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 HvDG26VDWV4J for ; Mon, 8 May 2017 07:55:51 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD021294A8 for ; Mon, 8 May 2017 07:55:50 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:5f4:343c:cbdf:d5d2]) by smtp-cloud2.xs4all.net with ESMTP id Hqvn1v00P327dWa01qvo8V; Mon, 08 May 2017 16:55:49 +0200 To: draft-ietf-softwire-map-mib.all@ietf.org, MIB Doctors From: "Bert Wijnen (IETF)" Message-ID: Date: Mon, 8 May 2017 16:55:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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, 08 May 2017 14:55:54 -0000 [not sure if draft-ietf-softwire-map-mib.all@ietf.org also includes the softwire WG mailing list. Anyways, I am not subscribed to that WG list, so I probably can't post there. Pls WG chairs forward if needed/wanted]. I did an early MIB doctor review for this document. The syntax check with SMICNG is clean. Great. My comments/questions: - section 4 states: The MAP-E MIB provides a way to configure and monitor the MAP devices in MAP encapsulation mode through SNMP. Yet there are no read-write or read-create objects defined in the MIB module. So I don't think you can "configure" anything on the MAP devices via SNMP with this MIB module - section 4.1.1 states: The mapRule subtree describes managed objects used for managing the multiple mapping rules in the MAP encapsulation mode. So, since the MIB module is read-only, I think I would change s/managing/monitoring/. But maybe that is just a wording choice. - section 4.1.2 - The BR MUST perform a validation of the consistency of the source IPv6 address and source port number for the packet using BMR. - The Customer Edge (CE) SHOULD check that MAP received packets' transport-layer destination port number is in the range configured by MAP for the CE. Mmmm... what is BR ? Please expand the acronym the first time you use it in your document. Same for BMR. I am not sure that the MIB document is the place to tell (normatively (MUST/SHOULD) a BR that it MUST perform a certain protocol function. That is (I assume) specified in the RFC7597 itself, right? Maybe you mean to say that the BR (and CE) MUST and SHOULD report any invalid packets as found per the rules in RFC7579. They MUST/SHOULD report them via this MIB module (as per your MODULE Conformance). Oh well, again this may be a wording issue. If my interpretation here is correct, I can live with your wording although I think it can be clearer and that the proper compliance language is in the proper document. - section 5. I think I would change: 5. Definitions MAP-E-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32, Unsigned32, Counter64 FROM SNMPv2-SMI ifIndex FROM IF-MIB InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; Into 5. Definitions The following MIB module imports definitions from [RFC2578], [RFC2580], [RFC2863], and [RFC4001]. MAP-E-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, mib-2, Integer32, Unsigned32, Counter64 FROM SNMPv2-SMI -- RFC2578 ifIndex FROM IF-MIB -- RFC2863 InetAddressType, InetAddress, InetAddressPrefixLength FROM INET-ADDRESS-MIB -- RFC4001 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; -- RFC2580 That way, you have a reference to each document (they are all normative) and in the MIB module itself (where you cannot put references/citations) you would still have document which RFC the imports are from. Handy when a MIB module has been extracted from an RFC. In the MIB module itself: mapRuleID OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An identifier used to distinguish the multiple mapping rule which is unique with each CE in the same BR." ::= { mapRuleEntry 1 } Since this is an index object, it be better defined as unsigned 32. See RFC4181, section 4.6.1.1. Specifically page 15, which states - Unsigned32 with a range that excludes zero is RECOMMENDED for most index objects. It is acceptable to include zero in the range when it is semantically significant or when it is used as the index value for a unique row with special properties. Such usage SHOULD be clearly documented in the DESCRIPTION clause. mapRuleIPv6PrefixType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-only STATUS current DESCRIPTION "This object MUST be set to the value of ipv6(2) to present the IPv6 address.It describes the address type of the mapRuleIPv6Prefix and mapRuleBRIPv6Address." Such MUST language is not recommended. The way to specify such mandatory value you best use the MODULE COMPLIANCE statement. Such is RECOMMENDED as per RFC4181, page 26 mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddress(SIZE (0..16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." ::= { mapRuleEntry 3 } mmmmm, when the InetAddressType is ipv6(2), then my understanding of RFC4001 is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can chime in here? And if it is ALWAYS an IPv6 address, then maybe it is even better to use InetAddressIPv6 as the OBJECT-TYPE. I see the same set of 2 objects for IPv4. In my view, the idea of InetAddressType and InetAddress were/are to allow yopu to specify one or a single pair that can hold each of the 2 (or even more if needed) AddressTypes. So why are there separate objects for IPv4 and IPv6 ??? mapRulePSID OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The PSID value algorithmically identifies a set of ports assigned to a CE." REFERENCE "PSID: section 3 of RFC 7597." ::= { mapRuleEntry 9 } Mmmm... section 3 of RFC7597 only defines the term. The algorithm is in section 5.1 Maybe that is a better place to point to. Reading that section 5.1 in RFC7597, I wonder if "Integer32" is the best representation. In section 5.1, I see a PSID that is 6 bits (figure 2 on page 10). But there is also text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. I am not an expert (basically have no knowledge about) on RFC7597. But sofar I cannot determine what the value range might be and how Integer32 is a good representation for the PSID. Please explain (not just to me, but adding text to the internet drafts and the DESCRIPTION clause of this object) mapRulePSIDLen OBJECT-TYPE SYNTAX Integer32 My understanding sofar is that this object can never take a negative value, so Unsigned32 would be better I think. mapRuleType OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the mapping rule. A value of 0 means it is a BMR; a non-zero value means it is a FMR." REFERENCE "BMR, FMR: section 5 of RFC 7597." ::= { mapRuleEntry 13 } That probably works. But it is probably much better to do a ENUMERATION, Which has a SYNTAX of INTEGER and then lists enumberated values. That makes it much more extensible in the future (if needed). mapMIBSecurityGroup OBJECT-GROUP OBJECTS { mapSecurityCheckInvalidv4, mapSecurityCheckInvalidv6 } STATUS current DESCRIPTION " The collection of this objects are used to give the information on MAP security checks." ::= { mapMIBGroups 2 } These objects are defined with ACCESS accessible-for-notify. I think that means you have to define this group as a NOTIFICATION-GROUP instead of an OBJECT-GROUP. - Section 7. Security considerations: These are the objects and their sensitivity/vulnerability: mapRuleIPv6PrefixType mapRuleIPv6Prefix ... etc (quite a list of objects). But nowhere do I see text about "their sensitivity/vulnerability". ?? Still to be added? Bert From nobody Mon May 8 14:54:27 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 023F312714F for ; Mon, 8 May 2017 14:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Pl2pe1a6EAx5 for ; Mon, 8 May 2017 14:54:24 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEFE124B0A for ; Mon, 8 May 2017 14:54:23 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:7044:2816:a4f8:15a9]) by smtp-cloud6.xs4all.net with ESMTP id HxuL1v0081x6p3w01xuM10; Mon, 08 May 2017 23:54:21 +0200 To: MIB Doctors References: <6ca4ae08-fa9b-60d8-436b-61515a739f57@bwijnen.net> <20170508143801.GB12134@elstar.local> From: "Bert Wijnen (IETF)" Message-ID: Date: Mon, 8 May 2017 23:54:21 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170508143801.GB12134@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MIB-DOCTORS] InetAddress SIZE rules. 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, 08 May 2017 21:54:26 -0000 Juergen, thanks for the answer. I think we agree. You may worry that your answer is not clear? Maybe my review comments to the authors is even less clear. But I agree that what they have done does not seem very efficient (having a saparate object/pair (InetAddressType/Inetaddress) for IPv4 and one for IPv6. I think I made that clear in my comments to authors too (I did send a copy to MIB doctors list). Feel free to jump in if you want to. Bert On 08/05/2017 16:38, Juergen Schoenwaelder wrote: > On Mon, May 08, 2017 at 04:02:12PM +0200, Bert Wijnen (IETF) wrote: >> In https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07 >> I see: >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddress(SIZE (0..16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::= { mapRuleEntry 3 } >> >> >> mmmmm, when the InetAddressType is ipv6(2), then my understanding of RFC4001 >> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can chime in here? >> >> Juergen (or anyone else) can you confirm if my understanding is correct? >> > > It seems the objects in question are always representing IPv6 > prefixes, that is, mapRuleIPv6PrefixType is essentially a constant as > if it were subtyped to only include the value ipv6(2). The question is > whether using the triple (InetAddressType, InetAddress, > InetAddressPrefixLength) is really useful and the suggested way of > doing things. This must have come up before but I think I garbage > collected this part of my memory. Using the triple is good for generic > tools, exchanging constants on the other hand is also not very > efficient. > > Right now, I would say that InetAddress(SIZE (0..16)) is consistent > with InetAddressType, i.e., the machine readable information says this > is a generic Internet address. The other alternative would be to use > InetAddressType { ipv6(2) } and InetAddress(SIZE (16)) and then both > together indicate to tools that this is by no means a generic Internet > address. Doing a mixture of both seems inconsistent - but on the wire > you will anyway get InetAddressType { ipv6(2) } and InetAddress(SIZE > (16)). > > Sorry for not providing a clear answer. > > /js > From nobody Thu May 11 21:45:45 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 0B3C5129B97; Thu, 11 May 2017 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 0cMpE5HgHF6N; Thu, 11 May 2017 21:45:41 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 322F0129A90; Thu, 11 May 2017 21:39:43 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.184]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0AZLvKGPBVZCC+uKg--.36300S3; Fri, 12 May 2017 12:39:34 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" References: In-Reply-To: Date: Fri, 12 May 2017 12:39:45 +0800 Message-ID: <003201d2cad9$c83bec50$58b3c4f0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLICzQDa7vUXcvIRTKNfLp9wiksMwAgXU3Q Content-Language: zh-cn X-CM-TRANSID: AQAAf0AZLvKGPBVZCC+uKg--.36300S3 X-Coremail-Antispam: 1UD129KBjvJXoW3CF4xur1kCF15Jw48Kw1rWFg_yoWDZryDp3 9aya1Yk3yDXr47CrZ7Xw4vgFyFyrZ29FW7Gr98Xry7C390yF97tF47K3Wq9a4kGr18ta1j v3yjvFy5GrZ8AaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r45MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bw2NNUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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: Fri, 12 May 2017 04:45:44 -0000 Hi Bert, Thanks a lot for your thorough MIB doctor review.=20 Because I have a fever in the early of this week, sorry to reply you a = little late.=20 Please see my reply inline. >>-----Original Message----- >>From: bertietf@bwijnen.net [mailto:bertietf@bwijnen.net] >>Sent: Monday, May 08, 2017 10:56 PM >>To: draft-ietf-softwire-map-mib.all@ietf.org; MIB Doctors >>Subject: early MIB Doctor review for draft-ietf-softwire-map-mib-07 >> >>[not sure if draft-ietf-softwire-map-mib.all@ietf.org also includes = the >>softwire WG mailing list. Anyways, I am not subscribed to that WG = list, so I >>probably can't post there. Pls WG chairs forward if needed/wanted]. >> >>I did an early MIB doctor review for this document. >> >>The syntax check with SMICNG is clean. Great. >> >>My comments/questions: >> >>- section 4 states: >> The MAP-E MIB provides a way to configure and monitor the MAP >>devices >> in MAP encapsulation mode through SNMP. >> Yet there are no read-write or read-create objects defined in the = MIB >> module. So I don't think you can "configure" anything on the MAP >>devices >> via SNMP with this MIB module >> >>- section 4.1.1 states: >> The mapRule subtree describes managed objects used for managing >>the >> multiple mapping rules in the MAP encapsulation mode. >> So, since the MIB module is read-only, I think I would change >> s/managing/monitoring/. But maybe that is just a wording choice. [fuyu] : We will change the "configure and monitor" to "manage and = monitor". Thanks. >>- section 4.1.2 >> - The BR MUST perform a validation of the consistency of the >>source >> IPv6 address and source port number for the packet using BMR. >> >> - The Customer Edge (CE) SHOULD check that MAP received >>packets' >> transport-layer destination port number is in the range >>configured by >> MAP for the CE. >> Mmmm... what is BR ? Please expand the acronym the first time you >>use it in your document. Same for BMR. [fuyu] : I will add the explanation for acronym in the updated version.=20 >> I am not sure that the MIB document is the place to tell = (normatively >>(MUST/SHOULD) >> a BR that it MUST perform a certain protocol function. That is (I >>assume) specified >> in the RFC7597 itself, right? >> Maybe you mean to say that the BR (and CE) MUST and SHOULD >>report any invalid >> packets as found per the rules in RFC7579. They MUST/SHOULD >>report them via this >> MIB module (as per your MODULE Conformance). >> Oh well, again this may be a wording issue. >> If my interpretation here is correct, I can live with your wording >>although I think >> it can be clearer and that the proper compliance language is in = the >>proper document. [fuyu] Yes, it is a good suggestion. The protocol function requirement = is specified in RFC7597. So we will change the description and delete MUST/SHOULD language. >> >>- section 5. >> I think I would change: >> >> 5. Definitions >> >> MAP-E-MIB DEFINITIONS ::=3D BEGIN >> >> >> IMPORTS >> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >> Integer32, Unsigned32, Counter64 >> FROM SNMPv2-SMI >> ifIndex >> FROM IF-MIB >> InetAddressType, InetAddress, >> InetAddressPrefixLength >> FROM INET-ADDRESS-MIB >> OBJECT-GROUP, MODULE-COMPLIANCE >> FROM SNMPv2-CONF; >> >> Into >> >> 5. Definitions >> >> The following MIB module imports definitions from [RFC2578], >>[RFC2580], >> [RFC2863], and [RFC4001]. >> >> MAP-E-MIB DEFINITIONS ::=3D BEGIN >> >> >> IMPORTS >> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >> Integer32, Unsigned32, Counter64 >> FROM SNMPv2-SMI -- RFC2578 >> ifIndex >> FROM IF-MIB -- RFC2863 >> InetAddressType, InetAddress, >> InetAddressPrefixLength >> FROM INET-ADDRESS-MIB -- RFC4001 >> OBJECT-GROUP, MODULE-COMPLIANCE >> FROM SNMPv2-CONF; -- RFC2580 >> >> That way, you have a reference to each document (they are all >>normative) >> and in the MIB module itself (where you cannot put >>references/citations) you >> would still have document which RFC the imports are from. Handy >>when a MIB module >> has been extracted from an RFC. [fuyu]: Yes, it is more clear. Thanks, I will change it in the updated = version. >>In the MIB module itself: >> >> mapRuleID OBJECT-TYPE >> SYNTAX Integer32 (1..2147483647) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "An identifier used to distinguish the multiple mapping >> rule which is unique with each CE in the same BR." >> ::=3D { mapRuleEntry 1 } >> >> Since this is an index object, it be better defined as unsigned 32. >> See RFC4181, section 4.6.1.1. Specifically page 15, which states >> - Unsigned32 with a range that excludes zero is RECOMMENDED >>for >> most index objects. It is acceptable to include zero in the >> range when it is semantically significant or when it is used = as >> the index value for a unique row with special properties. = Such >> usage SHOULD be clearly documented in the DESCRIPTION >>clause. [fuyu]: I will change it into unsigned 32. >> >> mapRuleIPv6PrefixType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object MUST be set to the value of ipv6(2) to >> present the IPv6 address.It describes the >> address type of the mapRuleIPv6Prefix and >> mapRuleBRIPv6Address." >> >> Such MUST language is not recommended. The way to specify such >>mandatory >> value you best use the MODULE COMPLIANCE statement. Such is >>RECOMMENDED >> as per RFC4181, page 26 [fuyu]: I will delete the MUST in the updated version. >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddress(SIZE (0..16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::=3D { mapRuleEntry 3 } >> >> mmmmm, when the InetAddressType is ipv6(2), then my >>understanding of RFC4001 >> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can >>chime in here? >> >> And if it is ALWAYS an IPv6 address, then maybe it is even better = to >>use >> InetAddressIPv6 as the OBJECT-TYPE. >> >> I see the same set of 2 objects for IPv4. >> >> In my view, the idea of InetAddressType and InetAddress were/are = to >>allow yopu to specify >> one or a single pair that can hold each of the 2 (or even more if >>needed) AddressTypes. >> >> So why are there separate objects for IPv4 and IPv6 ??? [fuyu]:OK, I will change it into=20 mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddressIPv6 MAX-ACCESS read-only STATUS current DESCRIPTION "The IPv6 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv6PrefixType." ::=3D { mapRuleEntry 3 } mapRuleIPv4Prefix OBJECT-TYPE SYNTAX InetAddressIPv4 MAX-ACCESS read-only STATUS current DESCRIPTION " The IPv4 prefix defined in mapping rule which will be assigned to CE. The address type is given by mapRuleIPv4PrefixType." ::=3D { mapRuleEntry 6 } Do you think it OK? >> >> mapRulePSID OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The PSID value algorithmically identifies a set of >> ports assigned to a CE." >> REFERENCE >> "PSID: section 3 of RFC 7597." >> ::=3D { mapRuleEntry 9 } >> >> Mmmm... section 3 of RFC7597 only defines the term. The algorithm >>is in section 5.1 >> Maybe that is a better place to point to. >> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is = the >>best representation. >> In section 5.1, I see a PSID that is 6 bits (figure 2 on page = 10). But >>there is also >> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >> I am not an expert (basically have no knowledge about) on = RFC7597. >>But sofar I cannot >> determine what the value range might be and how Integer32 is a >>good representation for >> the PSID. Please explain (not just to me, but adding text to the >>internet drafts >> and the DESCRIPTION clause of this object) [fuyu]:Different PSID values guarantee non-overlapping port sets. The length of PSID is k bits, and the default value of PSID offset = is 6 bits. So the bit length of PSID is variable. Thank you for your question. I have reconsidered the SYNTAS of the PSID. It can never be a = negative value. I think Unsigned32 will be better. =20 >> >> mapRulePSIDLen OBJECT-TYPE >> SYNTAX Integer32 >> >> My understanding sofar is that this object can never take a = negative >>value, >> so Unsigned32 would be better I think. [fuyu]: I will change it into Unsigned32 in the updated version. >> >> mapRuleType OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The type of the mapping rule. A value of 0 means it >> >> is a BMR; a non-zero value means it is a FMR." >> REFERENCE >> "BMR, FMR: section 5 of RFC 7597." >> ::=3D { mapRuleEntry 13 } >> >> That probably works. But it is probably much better to do a >>ENUMERATION, Which >> has a SYNTAX of INTEGER and then lists enumberated values. That >>makes it much >> more extensible in the future (if needed). [fuyu]: Thanks for your suggestion. I will updated it in the next = version. >> mapMIBSecurityGroup OBJECT-GROUP >> OBJECTS { >> mapSecurityCheckInvalidv4, >> mapSecurityCheckInvalidv6 } >> STATUS current >> DESCRIPTION >> " The collection of this objects are used to give the >> information on MAP security checks." >> ::=3D { mapMIBGroups 2 } >> >> These objects are defined with ACCESS accessible-for-notify. I = think >>that means >> you have to define this group as a NOTIFICATION-GROUP instead of >>an OBJECT-GROUP. [fuyu]: mapSecurityCheckInvalidv4 and mapSecurityCheckInvalidv6 indicate = the number of the invalid IPv4 or IPv6 packets received by the MAP-E. So I think define this group as OBJECT-GROUP will be = better. I will change the ACCESS of these objects from = accessible-for-notify into read-only. >> - Section 7. Security considerations: >> >> These are the objects and their sensitivity/vulnerability: >> >> mapRuleIPv6PrefixType >> >> mapRuleIPv6Prefix >> >> ... etc (quite a list of objects). >> >> But nowhere do I see text about "their = sensitivity/vulnerability". ?? >> Still to be added? [fuyu]: Some of the readable objects in this MIB module may be = considered sensitive or vulnerable in some network environments. These objects are readable,=20 so maybe they are considered sensitive or vulnerable in some use = case. We have a description why they are sensitive or vulnerable above the = list of objects. >>Bert Thanks again for your MIB doctor review. Cheers=20 Yu From nobody Fri May 12 08:11:12 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 EC57912EB41 for ; Fri, 12 May 2017 08:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 E1LuzFoc0ebh for ; Fri, 12 May 2017 08:11:08 -0700 (PDT) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57AEA12EB59 for ; Fri, 12 May 2017 08:05:17 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:4487:86e5:9500:e416]) by smtp-cloud2.xs4all.net with ESMTP id KT5C1v0031C3Fy301T5DEj; Fri, 12 May 2017 17:05:15 +0200 To: Yu Fu References: <003201d2cad9$c83bec50$58b3c4f0$@cn> Cc: draft-ietf-softwire-map-mib.all@ietf.org, 'MIB Doctors' From: "Bert Wijnen (IETF)" Message-ID: <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> Date: Fri, 12 May 2017 17:05:11 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <003201d2cad9$c83bec50$58b3c4f0$@cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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: Fri, 12 May 2017 15:11:11 -0000 inline On 12/05/2017 06:39, Yu Fu wrote: > Hi Bert, > > Thanks a lot for your thorough MIB doctor review. > Because I have a fever in the early of this week, sorry to reply you a little late. > no problem > Please see my reply inline. > >>> -----Original Message----- >>> From: bertietf@bwijnen.net [mailto:bertietf@bwijnen.net] >>> Sent: Monday, May 08, 2017 10:56 PM >>> To: draft-ietf-softwire-map-mib.all@ietf.org; MIB Doctors >>> Subject: early MIB Doctor review for draft-ietf-softwire-map-mib-07 >>> >>> [not sure if draft-ietf-softwire-map-mib.all@ietf.org also includes the >>> softwire WG mailing list. Anyways, I am not subscribed to that WG list, so I >>> probably can't post there. Pls WG chairs forward if needed/wanted]. >>> >>> I did an early MIB doctor review for this document. >>> >>> The syntax check with SMICNG is clean. Great. >>> >>> My comments/questions: >>> >>> - section 4 states: >>> The MAP-E MIB provides a way to configure and monitor the MAP >>> devices >>> in MAP encapsulation mode through SNMP. >>> Yet there are no read-write or read-create objects defined in the MIB >>> module. So I don't think you can "configure" anything on the MAP >>> devices >>> via SNMP with this MIB module >>> >>> - section 4.1.1 states: >>> The mapRule subtree describes managed objects used for managing >>> the >>> multiple mapping rules in the MAP encapsulation mode. >>> So, since the MIB module is read-only, I think I would change >>> s/managing/monitoring/. But maybe that is just a wording choice. > > [fuyu] : We will change the "configure and monitor" to "manage and monitor". Thanks. > ok >>> - section 4.1.2 >>> - The BR MUST perform a validation of the consistency of the >>> source >>> IPv6 address and source port number for the packet using BMR. >>> >>> - The Customer Edge (CE) SHOULD check that MAP received >>> packets' >>> transport-layer destination port number is in the range >>> configured by >>> MAP for the CE. >>> Mmmm... what is BR ? Please expand the acronym the first time you >>> use it in your document. Same for BMR. > > [fuyu] : I will add the explanation for acronym in the updated version. > great >>> I am not sure that the MIB document is the place to tell (normatively >>> (MUST/SHOULD) >>> a BR that it MUST perform a certain protocol function. That is (I >>> assume) specified >>> in the RFC7597 itself, right? >>> Maybe you mean to say that the BR (and CE) MUST and SHOULD >>> report any invalid >>> packets as found per the rules in RFC7579. They MUST/SHOULD >>> report them via this >>> MIB module (as per your MODULE Conformance). >>> Oh well, again this may be a wording issue. >>> If my interpretation here is correct, I can live with your wording >>> although I think >>> it can be clearer and that the proper compliance language is in the >>> proper document. > > [fuyu] Yes, it is a good suggestion. The protocol function requirement is specified in RFC7597. > So we will change the description and delete MUST/SHOULD language. >>> ok >>> - section 5. >>> I think I would change: >>> >>> 5. Definitions >>> >>> MAP-E-MIB DEFINITIONS ::= BEGIN >>> >>> >>> IMPORTS >>> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >>> Integer32, Unsigned32, Counter64 >>> FROM SNMPv2-SMI >>> ifIndex >>> FROM IF-MIB >>> InetAddressType, InetAddress, >>> InetAddressPrefixLength >>> FROM INET-ADDRESS-MIB >>> OBJECT-GROUP, MODULE-COMPLIANCE >>> FROM SNMPv2-CONF; >>> >>> Into >>> >>> 5. Definitions >>> >>> The following MIB module imports definitions from [RFC2578], >>> [RFC2580], >>> [RFC2863], and [RFC4001]. >>> >>> MAP-E-MIB DEFINITIONS ::= BEGIN >>> >>> >>> IMPORTS >>> MODULE-IDENTITY, OBJECT-TYPE, mib-2, >>> Integer32, Unsigned32, Counter64 >>> FROM SNMPv2-SMI -- RFC2578 >>> ifIndex >>> FROM IF-MIB -- RFC2863 >>> InetAddressType, InetAddress, >>> InetAddressPrefixLength >>> FROM INET-ADDRESS-MIB -- RFC4001 >>> OBJECT-GROUP, MODULE-COMPLIANCE >>> FROM SNMPv2-CONF; -- RFC2580 >>> >>> That way, you have a reference to each document (they are all >>> normative) >>> and in the MIB module itself (where you cannot put >>> references/citations) you >>> would still have document which RFC the imports are from. Handy >>> when a MIB module >>> has been extracted from an RFC. > > [fuyu]: Yes, it is more clear. Thanks, I will change it in the updated version. > ok >>> In the MIB module itself: >>> >>> mapRuleID OBJECT-TYPE >>> SYNTAX Integer32 (1..2147483647) >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "An identifier used to distinguish the multiple mapping >>> rule which is unique with each CE in the same BR." >>> ::= { mapRuleEntry 1 } >>> >>> Since this is an index object, it be better defined as unsigned 32. >>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>> - Unsigned32 with a range that excludes zero is RECOMMENDED >>> for >>> most index objects. It is acceptable to include zero in the >>> range when it is semantically significant or when it is used as >>> the index value for a unique row with special properties. Such >>> usage SHOULD be clearly documented in the DESCRIPTION >>> clause. > > [fuyu]: I will change it into unsigned 32. > Pls also think about the question if the value can ever be zero for a good reason. Normally INDEX object do not have a value of zero. >>> >>> mapRuleIPv6PrefixType OBJECT-TYPE >>> SYNTAX InetAddressType >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "This object MUST be set to the value of ipv6(2) to >>> present the IPv6 address.It describes the >>> address type of the mapRuleIPv6Prefix and >>> mapRuleBRIPv6Address." >>> >>> Such MUST language is not recommended. The way to specify such >>> mandatory >>> value you best use the MODULE COMPLIANCE statement. Such is >>> RECOMMENDED >>> as per RFC4181, page 26 > > [fuyu]: I will delete the MUST in the updated version. > But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state below), then there is no need for an InetAddressType. >>> >>> mapRuleIPv6Prefix OBJECT-TYPE >>> SYNTAX InetAddress(SIZE (0..16)) >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IPv6 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv6PrefixType." >>> ::= { mapRuleEntry 3 } >>> >>> mmmmm, when the InetAddressType is ipv6(2), then my >>> understanding of RFC4001 >>> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen can >>> chime in here? >>> >>> And if it is ALWAYS an IPv6 address, then maybe it is even better to >>> use >>> InetAddressIPv6 as the OBJECT-TYPE. >>> >>> I see the same set of 2 objects for IPv4. >>> >>> In my view, the idea of InetAddressType and InetAddress were/are to >>> allow yopu to specify >>> one or a single pair that can hold each of the 2 (or even more if >>> needed) AddressTypes. >>> >>> So why are there separate objects for IPv4 and IPv6 ??? > > [fuyu]:OK, I will change it into > > mapRuleIPv6Prefix OBJECT-TYPE > SYNTAX InetAddressIPv6 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The IPv6 prefix defined in mapping rule which will be > assigned to CE. The address type is given by > mapRuleIPv6PrefixType." > ::= { mapRuleEntry 3 } > > mapRuleIPv4Prefix OBJECT-TYPE > SYNTAX InetAddressIPv4 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > " The IPv4 prefix defined in mapping rule which will be > assigned to CE. The address type is given by > mapRuleIPv4PrefixType." > ::= { mapRuleEntry 6 } > > Do you think it OK? > Yes. And you then do not need the InetAddressType object. >>> >>> mapRulePSID OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The PSID value algorithmically identifies a set of >>> ports assigned to a CE." >>> REFERENCE >>> "PSID: section 3 of RFC 7597." >>> ::= { mapRuleEntry 9 } >>> >>> Mmmm... section 3 of RFC7597 only defines the term. The algorithm >>> is in section 5.1 >>> Maybe that is a better place to point to. >>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is the >>> best representation. >>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page 10). But >>> there is also >>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>> I am not an expert (basically have no knowledge about) on RFC7597. >>> But sofar I cannot >>> determine what the value range might be and how Integer32 is a >>> good representation for >>> the PSID. Please explain (not just to me, but adding text to the >>> internet drafts >>> and the DESCRIPTION clause of this object) > > [fuyu]:Different PSID values guarantee non-overlapping port sets. > The length of PSID is k bits, and the default value of PSID offset is 6 bits. > So the bit length of PSID is variable. Thank you for your question. > I have reconsidered the SYNTAS of the PSID. It can never be a negative value. > I think Unsigned32 will be better. > So do you just map the 4 octets of the PSID into this object? Is it not better to then use OCTET-STRING with a SIZE(4) ?? Maybe with a DISPLY-HINT added as well Do you normally display the value as an (unsigned) integer? Or do you normally display it as 0Xxxxxxxxx ?? Or maybe as bits? >>> >>> mapRulePSIDLen OBJECT-TYPE >>> SYNTAX Integer32 >>> >>> My understanding sofar is that this object can never take a negative >>> value, >>> so Unsigned32 would be better I think. > > [fuyu]: I will change it into Unsigned32 in the updated version. Does it also make sense to add a range? (what are the possible values?) ?? >>> >>> mapRuleType OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The type of the mapping rule. A value of 0 means it >>> >>> is a BMR; a non-zero value means it is a FMR." >>> REFERENCE >>> "BMR, FMR: section 5 of RFC 7597." >>> ::= { mapRuleEntry 13 } >>> >>> That probably works. But it is probably much better to do a >>> ENUMERATION, Which >>> has a SYNTAX of INTEGER and then lists enumberated values. That >>> makes it much >>> more extensible in the future (if needed). > > [fuyu]: Thanks for your suggestion. I will updated it in the next version. > ok > >>> mapMIBSecurityGroup OBJECT-GROUP >>> OBJECTS { >>> mapSecurityCheckInvalidv4, >>> mapSecurityCheckInvalidv6 } >>> STATUS current >>> DESCRIPTION >>> " The collection of this objects are used to give the >>> information on MAP security checks." >>> ::= { mapMIBGroups 2 } >>> >>> These objects are defined with ACCESS accessible-for-notify. I think >>> that means >>> you have to define this group as a NOTIFICATION-GROUP instead of >>> an OBJECT-GROUP. > > [fuyu]: mapSecurityCheckInvalidv4 and mapSecurityCheckInvalidv6 indicate the number of the invalid IPv4 or IPv6 packets received by the > MAP-E. So I think define this group as OBJECT-GROUP will be better. > I will change the ACCESS of these objects from accessible-for-notify into read-only. > OK >>> - Section 7. Security considerations: >>> >>> These are the objects and their sensitivity/vulnerability: >>> >>> mapRuleIPv6PrefixType >>> >>> mapRuleIPv6Prefix >>> >>> ... etc (quite a list of objects). >>> >>> But nowhere do I see text about "their sensitivity/vulnerability". ?? >>> Still to be added? > > [fuyu]: Some of the readable objects in this MIB module may be considered sensitive or > vulnerable in some network environments. These objects are readable, > so maybe they are considered sensitive or vulnerable in some use case. > We have a description why they are sensitive or vulnerable above the list of objects. > Mmmm... can you point me to that text? I do not see that you describe the vulnerability at any place. You do describe what the objects are for, but that does not clearly explain what the security risks are if some unauthorize person would see them. If you describe that at some other place in the document, then at least I would suggest to add a pointer to that text in the Security COnsiderations Secion. Bert >>> Bert > > Thanks again for your MIB doctor review. > > Cheers > Yu > > > From nobody Tue May 16 00:13:26 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E96129B7D; Tue, 16 May 2017 00:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 zjKIES9qEQFK; Tue, 16 May 2017 00:13:11 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id A33EC12E041; Tue, 16 May 2017 00:10:12 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5hubDpRpZQJixKg--.40173S4; Tue, 16 May 2017 15:09:55 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" , References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> In-Reply-To: <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> Date: Tue, 16 May 2017 15:10:08 +0800 Message-ID: <002201d2ce13$73ccd570$5b668050$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLLMf+kXJXxUjaxQv+CCRcaXI+9NgB8BaKQ Content-Language: zh-cn X-CM-TRANSID: AQAAf0B5hubDpRpZQJixKg--.40173S4 X-Coremail-Antispam: 1UD129KBjvJXoW3XFy7Jw4DGFW8Kw4fAF4UXFb_yoW3Xw1xp3 93ta15trWqqa17CrWv9w1vq34FyFZ3ZFy5Gr98try3C390yr97JF47KF1j9ayDJr10qa1j vrWUX3s8C3s8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Cb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28IrcIa0xkI8VA2jI 8067AKxVWUGwA2048vs2IY020Ec7CjxVAFwI0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kE wVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW5JVW7JwA2z4x0Y4vE2Ix0cI8IcVCY1x 0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7Cj xVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrV C2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE 7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_GF4l42xK82IYc2Ij64vIr4 1l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK 67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI 8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAv wI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14 v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bYD7-UUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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: Tue, 16 May 2017 07:13:13 -0000 Hi Bert, Please see my reply inline.=20 I have cc the email to the softwire WG so that the WG could see the MIB = Doctor's comments. >> In the MIB module itself: >> >> mapRuleID OBJECT-TYPE >> SYNTAX Integer32 (1..2147483647) >> MAX-ACCESS not-accessible >> STATUS current >> DESCRIPTION >> "An identifier used to distinguish the multiple >>mapping >> rule which is unique with each CE in the same BR." >> ::=3D { mapRuleEntry 1 } >> >> Since this is an index object, it be better defined as unsigned 32. >> See RFC4181, section 4.6.1.1. Specifically page 15, which states >> - Unsigned32 with a range that excludes zero is >>RECOMMENDED for >> most index objects. It is acceptable to include zero in the >> range when it is semantically significant or when it is used = as >> the index value for a unique row with special properties. >>Such >> usage SHOULD be clearly documented in the DESCRIPTION >>clause. >> >> [fuyu]: I will change it into unsigned 32. >> >Pls also think about the question if the value can ever be zero for a = good >reason. >Normally INDEX object do not have a value of zero. [fuyu] Yes, since it is an index object and the value range is not = include zero. I think unsigned 32 is better. >> >> >> mapRuleIPv6PrefixType OBJECT-TYPE >> SYNTAX InetAddressType >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "This object MUST be set to the value of ipv6(2) to >> present the IPv6 address.It describes the >> address type of the mapRuleIPv6Prefix and >> mapRuleBRIPv6Address." >> >> Such MUST language is not recommended. The way to specify >>such >> mandatory >> value you best use the MODULE COMPLIANCE statement. Such is >> RECOMMENDED >> as per RFC4181, page 26 >> >> [fuyu]: I will delete the MUST in the updated version. >> >But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state >below), then there is no need for an InetAddressType. [fuyu] :Yes, I will delete the object of mapRuleIPv6PrefixType and = mapRuleIPv4PrefixType too. Thank you for your remind. >> >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddress(SIZE (0..16)) >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::=3D { mapRuleEntry 3 } >> >> mmmmm, when the InetAddressType is ipv6(2), then my >>understanding >> of RFC4001 >> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen >> can chime in here? >> >> And if it is ALWAYS an IPv6 address, then maybe it is even better >> to use >> InetAddressIPv6 as the OBJECT-TYPE. >> >> I see the same set of 2 objects for IPv4. >> >> In my view, the idea of InetAddressType and InetAddress >>were/are >> to allow yopu to specify >> one or a single pair that can hold each of the 2 (or even more if >> needed) AddressTypes. >> >> So why are there separate objects for IPv4 and IPv6 ??? >> >> [fuyu]:OK, I will change it into >> >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv6 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The IPv6 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv6PrefixType." >> ::=3D { mapRuleEntry 3 } >> >> mapRuleIPv4Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv4 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> " The IPv4 prefix defined in mapping rule which will be >> assigned to CE. The address type is given by >> mapRuleIPv4PrefixType." >> ::=3D { mapRuleEntry 6 } >> >> Do you think it OK? >> >Yes. And you then do not need the InetAddressType object. [fuyu] : Yes, I will delete the objects of mapRuleIPv6PrefixType and = mapRuleIPv4PrefixType too. Thank you for your remind. >> >> >> mapRulePSID OBJECT-TYPE >> SYNTAX Integer32 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> "The PSID value algorithmically identifies a set of >> ports assigned to a CE." >> REFERENCE >> "PSID: section 3 of RFC 7597." >> ::=3D { mapRuleEntry 9 } >> >> Mmmm... section 3 of RFC7597 only defines the term. The >> algorithm is in section 5.1 >> Maybe that is a better place to point to. >> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >> the best representation. >> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >> 10). But there is also >> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >> I am not an expert (basically have no knowledge about) on >>RFC7597. >> But sofar I cannot >> determine what the value range might be and how Integer32 is a >> good representation for >> the PSID. Please explain (not just to me, but adding text to the >> internet drafts >> and the DESCRIPTION clause of this object) >> >> [fuyu]:Different PSID values guarantee non-overlapping port sets. >> The length of PSID is k bits, and the default value of PSID = offset is 6 >>bits. >> So the bit length of PSID is variable. Thank you for your = question. >> I have reconsidered the SYNTAS of the PSID. It can never be a >>negative value. >> I think Unsigned32 will be better. >> >So do you just map the 4 octets of the PSID into this object? >Is it not better to then use OCTET-STRING with a SIZE(4) ?? >Maybe with a DISPLY-HINT added as well > >Do you normally display the value as an (unsigned) integer? >Or do you normally display it as 0Xxxxxxxxx ?? >Or maybe as bits? [fuyu] We always describe a Basic mapping rule as below: A MAP node (CE or BR) can, via the BMR or equivalent FMR, determine the IPv4 address and port set as shown below: EA bits offset: 40 IPv4 suffix bits (p) Length of IPv4 address (32) - IPv4 prefix length (24) =3D 8 IPv4 address: 192.0.2.18 (0xc0000212) PSID start: 40 + p =3D 40 + 8 =3D 48 PSID length: o - p =3D (56 - 40) - 8 =3D 8 PSID: 0x34 (1232) So I think display the values as (unsigned) integer or display it as = 0Xxxxxxxxx both will be OK. Do you have the surggstions? >> >> >> mapRulePSIDLen OBJECT-TYPE >> SYNTAX Integer32 >> >> My understanding sofar is that this object can never take a >> negative value, >> so Unsigned32 would be better I think. >> >> [fuyu]: I will change it into Unsigned32 in the updated version. >> >Does it also make sense to add a range? (what are the possible values?) = ?? [fuyu] The value range of mapRulePSIDLen is greater than or equal to 0 = and no more than 16, so do you think define as below =20 mapRulePSIDLen OBJECT-TYPE SYNTAX Unsigned32(0..16) =20 Will it make sense? >> - Section 7. Security considerations: >> >> These are the objects and their sensitivity/vulnerability: >> >> mapRuleIPv6PrefixType >> >> mapRuleIPv6Prefix >> >> ... etc (quite a list of objects). >> >> But nowhere do I see text about "their >>sensitivity/vulnerability". ?? >> Still to be added? >> >> [fuyu]: Some of the readable objects in this MIB module may be >>considered sensitive or >> vulnerable in some network environments. These objects are >>readable, >> so maybe they are considered sensitive or vulnerable in some use >>case. >> We have a description why they are sensitive or vulnerable above = the >>list of objects. >> >Mmmm... can you point me to that text? I do not see that you describe = the >vulnerability at any place. You do describe what the objects are for, = but >that does not clearly explain what the security risks are if some >unauthorize person would see them. > >If you describe that at some other place in the document, then at least = I >would suggest to add a pointer to that text in the Security = COnsiderations >Secion. [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 = of the section 7. From the first sentence that "Some of the readable objects in this = MIB module may be considered sensitive or vulnerable..." > >Bert Thanks a lot Yu From nobody Tue May 16 01:19:19 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 2627D12EB11 for ; Tue, 16 May 2017 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 L-5lo1HRLu6g for ; Tue, 16 May 2017 01:19:15 -0700 (PDT) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C647812955D for ; Tue, 16 May 2017 01:15:37 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:a860:6f3c:de7:5417]) by smtp-cloud2.xs4all.net with ESMTP id LwFY1v0020Xfuf201wFZ3d; Tue, 16 May 2017 10:15:35 +0200 To: Yu Fu References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> Cc: draft-ietf-softwire-map-mib.all@ietf.org, 'MIB Doctors' , softwires@ietf.org From: "Bert Wijnen (IETF)" Message-ID: <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> Date: Tue, 16 May 2017 10:15:33 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <002201d2ce13$73ccd570$5b668050$@cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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: Tue, 16 May 2017 08:19:18 -0000 inline On 16/05/2017 09:10, Yu Fu wrote: > Hi Bert, > > Please see my reply inline. > > I have cc the email to the softwire WG so that the WG could see the MIB Doctor's comments. > >>> In the MIB module itself: >>> >>> mapRuleID OBJECT-TYPE >>> SYNTAX Integer32 (1..2147483647) >>> MAX-ACCESS not-accessible >>> STATUS current >>> DESCRIPTION >>> "An identifier used to distinguish the multiple >>> mapping >>> rule which is unique with each CE in the same BR." >>> ::= { mapRuleEntry 1 } >>> >>> Since this is an index object, it be better defined as unsigned 32. >>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>> - Unsigned32 with a range that excludes zero is >>> RECOMMENDED for >>> most index objects. It is acceptable to include zero in the >>> range when it is semantically significant or when it is used as >>> the index value for a unique row with special properties. >>> Such >>> usage SHOULD be clearly documented in the DESCRIPTION >>> clause. >>> >>> [fuyu]: I will change it into unsigned 32. >>> >> Pls also think about the question if the value can ever be zero for a good >> reason. >> Normally INDEX object do not have a value of zero. > > [fuyu] Yes, since it is an index object and the value range is not include zero. I think unsigned 32 is better. > OK, but then the definition would better be: SYNTAX Unsigned32 (1..4294967295) That wat it is machinereadably clear that valu 0 is not valid. >>> >>> >>> mapRuleIPv6PrefixType OBJECT-TYPE >>> SYNTAX InetAddressType >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "This object MUST be set to the value of ipv6(2) to >>> present the IPv6 address.It describes the >>> address type of the mapRuleIPv6Prefix and >>> mapRuleBRIPv6Address." >>> >>> Such MUST language is not recommended. The way to specify >>> such >>> mandatory >>> value you best use the MODULE COMPLIANCE statement. Such is >>> RECOMMENDED >>> as per RFC4181, page 26 >>> >>> [fuyu]: I will delete the MUST in the updated version. >>> >> But if you change to InetAddressIPv6 and InetAddressIPv4 (as you state >> below), then there is no need for an InetAddressType. > > > [fuyu] :Yes, I will delete the object of mapRuleIPv6PrefixType and mapRuleIPv4PrefixType too. Thank you for your remind. > OK >>> >>> >>> mapRuleIPv6Prefix OBJECT-TYPE >>> SYNTAX InetAddress(SIZE (0..16)) >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IPv6 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv6PrefixType." >>> ::= { mapRuleEntry 3 } >>> >>> mmmmm, when the InetAddressType is ipv6(2), then my >>> understanding >>> of RFC4001 >>> is that the SIZE for the InetAddress MUST be 16. Maybe Juergen >>> can chime in here? >>> >>> And if it is ALWAYS an IPv6 address, then maybe it is even better >>> to use >>> InetAddressIPv6 as the OBJECT-TYPE. >>> >>> I see the same set of 2 objects for IPv4. >>> >>> In my view, the idea of InetAddressType and InetAddress >>> were/are >>> to allow yopu to specify >>> one or a single pair that can hold each of the 2 (or even more if >>> needed) AddressTypes. >>> >>> So why are there separate objects for IPv4 and IPv6 ??? >>> >>> [fuyu]:OK, I will change it into >>> >>> mapRuleIPv6Prefix OBJECT-TYPE >>> SYNTAX InetAddressIPv6 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The IPv6 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv6PrefixType." >>> ::= { mapRuleEntry 3 } >>> >>> mapRuleIPv4Prefix OBJECT-TYPE >>> SYNTAX InetAddressIPv4 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> " The IPv4 prefix defined in mapping rule which will be >>> assigned to CE. The address type is given by >>> mapRuleIPv4PrefixType." >>> ::= { mapRuleEntry 6 } >>> >>> Do you think it OK? >>> >> Yes. And you then do not need the InetAddressType object. > > [fuyu] : Yes, I will delete the objects of mapRuleIPv6PrefixType and mapRuleIPv4PrefixType too. Thank you for your remind. > ok >>> >>> >>> mapRulePSID OBJECT-TYPE >>> SYNTAX Integer32 >>> MAX-ACCESS read-only >>> STATUS current >>> DESCRIPTION >>> "The PSID value algorithmically identifies a set of >>> ports assigned to a CE." >>> REFERENCE >>> "PSID: section 3 of RFC 7597." >>> ::= { mapRuleEntry 9 } >>> >>> Mmmm... section 3 of RFC7597 only defines the term. The >>> algorithm is in section 5.1 >>> Maybe that is a better place to point to. >>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>> the best representation. >>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>> 10). But there is also >>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>> I am not an expert (basically have no knowledge about) on >>> RFC7597. >>> But sofar I cannot >>> determine what the value range might be and how Integer32 is a >>> good representation for >>> the PSID. Please explain (not just to me, but adding text to the >>> internet drafts >>> and the DESCRIPTION clause of this object) >>> >>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>> The length of PSID is k bits, and the default value of PSID offset is 6 >>> bits. >>> So the bit length of PSID is variable. Thank you for your question. >>> I have reconsidered the SYNTAS of the PSID. It can never be a >>> negative value. >>> I think Unsigned32 will be better. >>> >> So do you just map the 4 octets of the PSID into this object? >> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >> Maybe with a DISPLY-HINT added as well >> >> Do you normally display the value as an (unsigned) integer? >> Or do you normally display it as 0Xxxxxxxxx ?? >> Or maybe as bits? > > [fuyu] We always describe a Basic mapping rule as below: > > A MAP node (CE or BR) can, via the BMR or equivalent FMR, > determine the IPv4 address and port set as shown below: > > EA bits offset: 40 > IPv4 suffix bits (p) Length of IPv4 address (32) - > IPv4 prefix length (24) = 8 > IPv4 address: 192.0.2.18 (0xc0000212) > PSID start: 40 + p = 40 + 8 = 48 > PSID length: o - p = (56 - 40) - 8 = 8 > PSID: 0x34 (1232) > Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? In fact I am not sure I understand much/any of the above. But that is OK, if people who are familiar with (or must use/implement) this and if they understand it then fine. > So I think display the values as (unsigned) integer or display it as 0Xxxxxxxxx both will be OK. > Do you have the surggstions? > My personal feeling/thinking is that it is probably best displayed as 0Xxxxxxxxx. That (I would think) makes it easier to see bit positions as opposed to an (unsigned) integer. But in princople I can live with either. The idea/hope is that if you add a DISPLAY HINT that everyone displays it in the same way. >>> >>> >>> mapRulePSIDLen OBJECT-TYPE >>> SYNTAX Integer32 >>> >>> My understanding sofar is that this object can never take a >>> negative value, >>> so Unsigned32 would be better I think. >>> >>> [fuyu]: I will change it into Unsigned32 in the updated version. >>> >> Does it also make sense to add a range? (what are the possible values?) ?? > > [fuyu] The value range of mapRulePSIDLen is greater than or equal to 0 and no more than 16, so do you think define as below > > mapRulePSIDLen OBJECT-TYPE > SYNTAX Unsigned32(0..16) > > Will it make sense? > > I think that makes sense. Now you can see (machine readable) what the range of valid values is. >>> - Section 7. Security considerations: >>> >>> These are the objects and their sensitivity/vulnerability: >>> >>> mapRuleIPv6PrefixType >>> >>> mapRuleIPv6Prefix >>> >>> ... etc (quite a list of objects). >>> >>> But nowhere do I see text about "their >>> sensitivity/vulnerability". ?? >>> Still to be added? >>> >>> [fuyu]: Some of the readable objects in this MIB module may be >>> considered sensitive or >>> vulnerable in some network environments. These objects are >>> readable, >>> so maybe they are considered sensitive or vulnerable in some use >>> case. >>> We have a description why they are sensitive or vulnerable above the >>> list of objects. >>> >> Mmmm... can you point me to that text? I do not see that you describe the >> vulnerability at any place. You do describe what the objects are for, but >> that does not clearly explain what the security risks are if some >> unauthorize person would see them. >> >> If you describe that at some other place in the document, then at least I >> would suggest to add a pointer to that text in the Security COnsiderations >> Secion. > > [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the section 7. > From the first sentence that "Some of the readable objects in this MIB module may be > considered sensitive or vulnerable..." >> It states that they " may be considered sensitive of vulnerable". But it does not state WHY or IN WHAT CIRCUMSTANCES they might be vulnerable. What bad things are there that an intruder can do (or find out) when he/she gets read access to these objects? I.e. does he get to see confidential or private information? Does he learn about a competitors internal network structure? Or something else? Bert >> Bert > > Thanks a lot > > Yu > > > From nobody Wed May 17 00:19:22 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 955021293DA; Wed, 17 May 2017 00:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8npT_pZmwc0; Wed, 17 May 2017 00:19:18 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id F0639129BFF; Wed, 17 May 2017 00:15:59 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.89]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0CpsuKi+BtZoOuxKg--.42393S3; Wed, 17 May 2017 15:15:46 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" , References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> In-Reply-To: <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> Date: Wed, 17 May 2017 15:15:57 +0800 Message-ID: <002401d2cedd$6efb6870$4cf23950$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLOHSNfBEgrSrxETg2pp8We1O3+SQAlnKBA Content-Language: zh-cn X-CM-TRANSID: AQAAf0CpsuKi+BtZoOuxKg--.42393S3 X-Coremail-Antispam: 1UD129KBjvJXoWxKw4xGF48Cw1UZr1DJF43Wrg_yoWxAw48pF Wftay7KrWDJ34ayrs2qw18try0yrZ2yry3Xr98tryUC390vrn7JF47KrW7ua4DCr18Xa1j v3yUX343ur1UAaUanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bo-BiUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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, 17 May 2017 07:19:20 -0000 Hi Bert, Please see my reply inline. >> >>>> mapRuleID OBJECT-TYPE >>>> SYNTAX Integer32 (1..2147483647) >>>> MAX-ACCESS not-accessible >>>> STATUS current >>>> DESCRIPTION >>>> "An identifier used to distinguish the multiple >>>>mapping >>>> rule which is unique with each CE in the same BR." >>>> ::=3D { mapRuleEntry 1 } >>>> >>>> Since this is an index object, it be better defined as unsigned = 32. >>>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>>> - Unsigned32 with a range that excludes zero is >>>>RECOMMENDED for >>>> most index objects. It is acceptable to include zero in the >>>> range when it is semantically significant or when it is used = as >>>> the index value for a unique row with special properties. >>>> Such >>>> usage SHOULD be clearly documented in the DESCRIPTION >>>>clause. >>>>> >>>> [fuyu]: I will change it into unsigned 32. >>>> >>>> Pls also think about the question if the value can ever be zero for = a >>>> good reason. >>>> Normally INDEX object do not have a value of zero. >>>> >> [fuyu] Yes, since it is an index object and the value range is not = include >>zero. I think unsigned 32 is better. >> >OK, but then the definition would better be: > > SYNTAX Unsigned32 (1..4294967295) >That wat it is machinereadably clear that valu 0 is not valid. [fuyu] :OK, I will updated it. Thanks. >>>> >>>> >>>> mapRulePSID OBJECT-TYPE >>>> SYNTAX Integer32 >>>> MAX-ACCESS read-only >>>> STATUS current >>>> DESCRIPTION >>>> "The PSID value algorithmically identifies a set of >>>> ports assigned to a CE." >>>> REFERENCE >>>> "PSID: section 3 of RFC 7597." >>>> ::=3D { mapRuleEntry 9 } >>>> >>>> Mmmm... section 3 of RFC7597 only defines the term. The >>>> algorithm is in section 5.1 >>>> Maybe that is a better place to point to. >>>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>>> the best representation. >>>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>>> 10). But there is also >>>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 = bits. >>>> I am not an expert (basically have no knowledge about) on >>>> RFC7597. >>>> But sofar I cannot >>>> determine what the value range might be and how Integer32 is a >>>> good representation for >>>> the PSID. Please explain (not just to me, but adding text to = the >>>> internet drafts >>>> and the DESCRIPTION clause of this object) >>>> >>>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>>> The length of PSID is k bits, and the default value of PSID >>>> offset is 6 bits. >>>> So the bit length of PSID is variable. Thank you for your >>>>question. >>>> I have reconsidered the SYNTAS of the PSID. It can never be a >>>> negative value. >>>> I think Unsigned32 will be better. >>>> >>>> So do you just map the 4 octets of the PSID into this object? >>>> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >>>> Maybe with a DISPLY-HINT added as well >>>> >>>> Do you normally display the value as an (unsigned) integer? >>>> Or do you normally display it as 0Xxxxxxxxx ?? >>>> Or maybe as bits? >>>> >>>> [fuyu] We always describe a Basic mapping rule as below: >>>> >>>> A MAP node (CE or BR) can, via the BMR or equivalent FMR, >>>> determine the IPv4 address and port set as shown below: >>>> >>>> EA bits offset: 40 >>>> IPv4 suffix bits (p) Length of IPv4 address (32) - >>>> IPv4 prefix length (24) =3D 8 >>>> IPv4 address: 192.0.2.18 (0xc0000212) >>>> PSID start: 40 + p =3D 40 + 8 =3D 48 >>>> PSID length: o - p =3D (56 - 40) - 8 =3D 8 >>>> PSID: 0x34 (1232) >>>> >>>> >Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? [fuyu] : Ops, sorry .....it's my fault. 1232 is the port number, not = the integer.=20 > >In fact I am not sure I understand much/any of the above. >But that is OK, if people who are familiar with (or must use/implement) = this >and if they understand it then fine. > >>>> >>>> So I think display the values as (unsigned) integer or display it = as >>>>0Xxxxxxxxx both will be OK. >>>> Do you have the surggstions? >>>> >My personal feeling/thinking is that it is probably best displayed as >0Xxxxxxxxx. >That (I would think) makes it easier to see bit positions as opposed to = an >(unsigned) integer. But in princople I can live with either. The = idea/hope is >that if you add a DISPLAY HINT that everyone displays it in the same = way. [fuyu]:Thank you for your suggestions. I will define it as below: RulePSID ::=3D TEXTUAL-CONVENTION DISPLAY-HINT "0x:" STATUS current DESCRIPTION "Represents ..." SYNTAX OCTET STRING (SIZE (4)) mapRulePSID OBJECT-TYPE SYNTAX RulePSID MAX-ACCESS read-only STATUS current DESCRIPTION "The PSID value algorithmically identifies a set of ports assigned to a CE." REFERENCE "PSID: section 5.1 of RFC 7597." ::=3D { mapRuleEntry 9 } Do you think it will be Ok? >>>> >>>>> - Section 7. Security considerations: >>>>> >>>> These are the objects and their sensitivity/vulnerability: >>>> >>>> mapRuleIPv6PrefixType >>>> >>>> mapRuleIPv6Prefix >>>> >>>> ... etc (quite a list of objects). >>>> >>>> But nowhere do I see text about "their >>>> sensitivity/vulnerability". ?? >>>> Still to be added? >>>> >>>> [fuyu]: Some of the readable objects in this MIB module may be >>>> considered sensitive or >>>> vulnerable in some network environments. These objects are >>>> readable, >>>> so maybe they are considered sensitive or vulnerable in some use >>>> case. >>>> We have a description why they are sensitive or vulnerable above >>>> the list of objects. >>>> >>>> Mmmm... can you point me to that text? I do not see that you = describe >>>> the vulnerability at any place. You do describe what the objects = are >>>> for, but that does not clearly explain what the security risks are = if >>>> some unauthorize person would see them. >>>> >>>> If you describe that at some other place in the document, then at >>>> least I would suggest to add a pointer to that text in the Security >>>> COnsiderations Secion. >>>> >>>> [fuyu]: Sorry. I should point it more clearly. It is in the = paragraph 2 of the >>>>section 7. >>>> From the first sentence that "Some of the readable objects in = this >>>>MIB module may be >>>> considered sensitive or vulnerable..." >>>> >>>> >It states that they " may be considered sensitive of vulnerable". >But it does not state WHY or IN WHAT CIRCUMSTANCES they might be >vulnerable. >What bad things are there that an intruder can do (or find out) when >he/she gets read access to these objects? >I.e. does he get to see confidential or private information? Does he = learn >about a competitors internal network structure? Or something else? [fuyu] : I will update it in more detail in this paragraph.Thanks. > >Bert Thanks again Yu From nobody Wed May 17 00:21:25 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 C4EE2129B3C for ; Wed, 17 May 2017 00:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable 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 rwvlDhx7PAzT for ; Wed, 17 May 2017 00:21:16 -0700 (PDT) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B58129B67 for ; Wed, 17 May 2017 00:17:38 -0700 (PDT) Received: from Macintosh-4.fritz.box ([IPv6:2001:981:602b:1:4928:6836:108a:7846]) by smtp-cloud2.xs4all.net with ESMTP id MKHb1v0071etLTN01KHcDv; Wed, 17 May 2017 09:17:36 +0200 To: Yu Fu References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> <002401d2cedd$6efb6870$4cf23950$@cn> Cc: draft-ietf-softwire-map-mib.all@ietf.org, 'MIB Doctors' , softwires@ietf.org From: "Bert Wijnen (IETF)" Message-ID: Date: Wed, 17 May 2017 09:17:36 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <002401d2cedd$6efb6870$4cf23950$@cn> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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, 17 May 2017 07:21:18 -0000 thank you. I am happy mow Bert On 17/05/2017 09:15, Yu Fu wrote: > Hi Bert, > > Please see my reply inline. > >>> >>>>> mapRuleID OBJECT-TYPE >>>>> SYNTAX Integer32 (1..2147483647) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "An identifier used to distinguish the multiple >>>>> mapping >>>>> rule which is unique with each CE in the same BR." >>>>> ::= { mapRuleEntry 1 } >>>>> >>>>> Since this is an index object, it be better defined as unsigned 32. >>>>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>>>> - Unsigned32 with a range that excludes zero is >>>>> RECOMMENDED for >>>>> most index objects. It is acceptable to include zero in the >>>>> range when it is semantically significant or when it is used as >>>>> the index value for a unique row with special properties. >>>>> Such >>>>> usage SHOULD be clearly documented in the DESCRIPTION >>>>> clause. >>>>>> >>>>> [fuyu]: I will change it into unsigned 32. >>>>> >>>>> Pls also think about the question if the value can ever be zero for a >>>>> good reason. >>>>> Normally INDEX object do not have a value of zero. >>>>> >>> [fuyu] Yes, since it is an index object and the value range is not include >>> zero. I think unsigned 32 is better. >>> >> OK, but then the definition would better be: >> >> SYNTAX Unsigned32 (1..4294967295) >> That wat it is machinereadably clear that valu 0 is not valid. > > > [fuyu] :OK, I will updated it. Thanks. > > >>>>> >>>>> >>>>> mapRulePSID OBJECT-TYPE >>>>> SYNTAX Integer32 >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "The PSID value algorithmically identifies a set of >>>>> ports assigned to a CE." >>>>> REFERENCE >>>>> "PSID: section 3 of RFC 7597." >>>>> ::= { mapRuleEntry 9 } >>>>> >>>>> Mmmm... section 3 of RFC7597 only defines the term. The >>>>> algorithm is in section 5.1 >>>>> Maybe that is a better place to point to. >>>>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>>>> the best representation. >>>>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>>>> 10). But there is also >>>>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>>>> I am not an expert (basically have no knowledge about) on >>>>> RFC7597. >>>>> But sofar I cannot >>>>> determine what the value range might be and how Integer32 is a >>>>> good representation for >>>>> the PSID. Please explain (not just to me, but adding text to the >>>>> internet drafts >>>>> and the DESCRIPTION clause of this object) >>>>> >>>>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>>>> The length of PSID is k bits, and the default value of PSID >>>>> offset is 6 bits. >>>>> So the bit length of PSID is variable. Thank you for your >>>>> question. >>>>> I have reconsidered the SYNTAS of the PSID. It can never be a >>>>> negative value. >>>>> I think Unsigned32 will be better. >>>>> >>>>> So do you just map the 4 octets of the PSID into this object? >>>>> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >>>>> Maybe with a DISPLY-HINT added as well >>>>> >>>>> Do you normally display the value as an (unsigned) integer? >>>>> Or do you normally display it as 0Xxxxxxxxx ?? >>>>> Or maybe as bits? >>>>> >>>>> [fuyu] We always describe a Basic mapping rule as below: >>>>> >>>>> A MAP node (CE or BR) can, via the BMR or equivalent FMR, >>>>> determine the IPv4 address and port set as shown below: >>>>> >>>>> EA bits offset: 40 >>>>> IPv4 suffix bits (p) Length of IPv4 address (32) - >>>>> IPv4 prefix length (24) = 8 >>>>> IPv4 address: 192.0.2.18 (0xc0000212) >>>>> PSID start: 40 + p = 40 + 8 = 48 >>>>> PSID length: o - p = (56 - 40) - 8 = 8 >>>>> PSID: 0x34 (1232) >>>>> >>>>> >> Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? > > > [fuyu] : Ops, sorry .....it's my fault. 1232 is the port number, not the integer. > > >> >> In fact I am not sure I understand much/any of the above. >> But that is OK, if people who are familiar with (or must use/implement) this >> and if they understand it then fine. >> >>>>> >>>>> So I think display the values as (unsigned) integer or display it as >>>>> 0Xxxxxxxxx both will be OK. >>>>> Do you have the surggstions? >>>>> >> My personal feeling/thinking is that it is probably best displayed as >> 0Xxxxxxxxx. >> That (I would think) makes it easier to see bit positions as opposed to an >> (unsigned) integer. But in princople I can live with either. The idea/hope is >> that if you add a DISPLAY HINT that everyone displays it in the same way. > > > [fuyu]:Thank you for your suggestions. I will define it as below: > > RulePSID ::= TEXTUAL-CONVENTION > DISPLAY-HINT "0x:" > STATUS current > DESCRIPTION > "Represents ..." > SYNTAX OCTET STRING (SIZE (4)) > > mapRulePSID OBJECT-TYPE > SYNTAX RulePSID > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The PSID value algorithmically identifies a set of > ports assigned to a CE." > REFERENCE > "PSID: section 5.1 of RFC 7597." > ::= { mapRuleEntry 9 } > > Do you think it will be Ok? > >>>>> >>>>>> - Section 7. Security considerations: >>>>>> >>>>> These are the objects and their sensitivity/vulnerability: >>>>> >>>>> mapRuleIPv6PrefixType >>>>> >>>>> mapRuleIPv6Prefix >>>>> >>>>> ... etc (quite a list of objects). >>>>> >>>>> But nowhere do I see text about "their >>>>> sensitivity/vulnerability". ?? >>>>> Still to be added? >>>>> >>>>> [fuyu]: Some of the readable objects in this MIB module may be >>>>> considered sensitive or >>>>> vulnerable in some network environments. These objects are >>>>> readable, >>>>> so maybe they are considered sensitive or vulnerable in some use >>>>> case. >>>>> We have a description why they are sensitive or vulnerable above >>>>> the list of objects. >>>>> >>>>> Mmmm... can you point me to that text? I do not see that you describe >>>>> the vulnerability at any place. You do describe what the objects are >>>>> for, but that does not clearly explain what the security risks are if >>>>> some unauthorize person would see them. >>>>> >>>>> If you describe that at some other place in the document, then at >>>>> least I would suggest to add a pointer to that text in the Security >>>>> COnsiderations Secion. >>>>> >>>>> [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the >>>>> section 7. >>>>> From the first sentence that "Some of the readable objects in this >>>>> MIB module may be >>>>> considered sensitive or vulnerable..." >>>>> >>>>> >> It states that they " may be considered sensitive of vulnerable". >> But it does not state WHY or IN WHAT CIRCUMSTANCES they might be >> vulnerable. >> What bad things are there that an intruder can do (or find out) when >> he/she gets read access to these objects? >> I.e. does he get to see confidential or private information? Does he learn >> about a competitors internal network structure? Or something else? > > [fuyu] : I will update it in more detail in this paragraph.Thanks. >> >> Bert > > Thanks again > Yu > > > From nobody Wed May 17 08:02:47 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 61F20129C5F; Wed, 17 May 2017 08:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HE-O3nVop4sD; Wed, 17 May 2017 08:02:37 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73B951293F5; Wed, 17 May 2017 07:56:04 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 May 2017 07:56:02 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 17 May 2017 07:56:02 -0700 From: Terry Manderson To: "Bert Wijnen (IETF)" , Yu Fu CC: "draft-ietf-softwire-map-mib.all@ietf.org" , 'MIB Doctors' , "softwires@ietf.org" Thread-Topic: early MIB Doctor review for draft-ietf-softwire-map-mib-07 Thread-Index: AQHSzt4ufXUW3DrbCUefV2/mMb2PhqH5up6A Date: Wed, 17 May 2017 14:56:01 +0000 Message-ID: References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> <002401d2cedd$6efb6870$4cf23950$@cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3577913755_241280046" MIME-Version: 1.0 Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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, 17 May 2017 15:02:39 -0000 --B_3577913755_241280046 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Bert, Yu, Thank you very much for your review and activity on this! Cheers Terry On 17/05/2017, 5:17 PM, "Bert Wijnen (IETF)" wrote: thank you. I am happy mow Bert On 17/05/2017 09:15, Yu Fu wrote: > Hi Bert, > > Please see my reply inline. > >>> >>>>> mapRuleID OBJECT-TYPE >>>>> SYNTAX Integer32 (1..2147483647) >>>>> MAX-ACCESS not-accessible >>>>> STATUS current >>>>> DESCRIPTION >>>>> "An identifier used to distinguish the multiple >>>>> mapping >>>>> rule which is unique with each CE in the same BR." >>>>> ::= { mapRuleEntry 1 } >>>>> >>>>> Since this is an index object, it be better defined as unsigned 32. >>>>> See RFC4181, section 4.6.1.1. Specifically page 15, which states >>>>> - Unsigned32 with a range that excludes zero is >>>>> RECOMMENDED for >>>>> most index objects. It is acceptable to include zero in the >>>>> range when it is semantically significant or when it is used as >>>>> the index value for a unique row with special properties. >>>>> Such >>>>> usage SHOULD be clearly documented in the DESCRIPTION >>>>> clause. >>>>>> >>>>> [fuyu]: I will change it into unsigned 32. >>>>> >>>>> Pls also think about the question if the value can ever be zero for a >>>>> good reason. >>>>> Normally INDEX object do not have a value of zero. >>>>> >>> [fuyu] Yes, since it is an index object and the value range is not include >>> zero. I think unsigned 32 is better. >>> >> OK, but then the definition would better be: >> >> SYNTAX Unsigned32 (1..4294967295) >> That wat it is machinereadably clear that valu 0 is not valid. > > > [fuyu] :OK, I will updated it. Thanks. > > >>>>> >>>>> >>>>> mapRulePSID OBJECT-TYPE >>>>> SYNTAX Integer32 >>>>> MAX-ACCESS read-only >>>>> STATUS current >>>>> DESCRIPTION >>>>> "The PSID value algorithmically identifies a set of >>>>> ports assigned to a CE." >>>>> REFERENCE >>>>> "PSID: section 3 of RFC 7597." >>>>> ::= { mapRuleEntry 9 } >>>>> >>>>> Mmmm... section 3 of RFC7597 only defines the term. The >>>>> algorithm is in section 5.1 >>>>> Maybe that is a better place to point to. >>>>> Reading that section 5.1 in RFC7597, I wonder if "Integer32" is >>>>> the best representation. >>>>> In section 5.1, I see a PSID that is 6 bits (figure 2 on page >>>>> 10). But there is also >>>>> text about a PSID of 0x00 and 0xFF, which does not fit in 6 bits. >>>>> I am not an expert (basically have no knowledge about) on >>>>> RFC7597. >>>>> But sofar I cannot >>>>> determine what the value range might be and how Integer32 is a >>>>> good representation for >>>>> the PSID. Please explain (not just to me, but adding text to the >>>>> internet drafts >>>>> and the DESCRIPTION clause of this object) >>>>> >>>>> [fuyu]:Different PSID values guarantee non-overlapping port sets. >>>>> The length of PSID is k bits, and the default value of PSID >>>>> offset is 6 bits. >>>>> So the bit length of PSID is variable. Thank you for your >>>>> question. >>>>> I have reconsidered the SYNTAS of the PSID. It can never be a >>>>> negative value. >>>>> I think Unsigned32 will be better. >>>>> >>>>> So do you just map the 4 octets of the PSID into this object? >>>>> Is it not better to then use OCTET-STRING with a SIZE(4) ?? >>>>> Maybe with a DISPLY-HINT added as well >>>>> >>>>> Do you normally display the value as an (unsigned) integer? >>>>> Or do you normally display it as 0Xxxxxxxxx ?? >>>>> Or maybe as bits? >>>>> >>>>> [fuyu] We always describe a Basic mapping rule as below: >>>>> >>>>> A MAP node (CE or BR) can, via the BMR or equivalent FMR, >>>>> determine the IPv4 address and port set as shown below: >>>>> >>>>> EA bits offset: 40 >>>>> IPv4 suffix bits (p) Length of IPv4 address (32) - >>>>> IPv4 prefix length (24) = 8 >>>>> IPv4 address: 192.0.2.18 (0xc0000212) >>>>> PSID start: 40 + p = 40 + 8 = 48 >>>>> PSID length: o - p = (56 - 40) - 8 = 8 >>>>> PSID: 0x34 (1232) >>>>> >>>>> >> Not sure I understand: 0x34 (1232) ??? 0x34 in my mind is 52, no? > > > [fuyu] : Ops, sorry .....it's my fault. 1232 is the port number, not the integer. > > >> >> In fact I am not sure I understand much/any of the above. >> But that is OK, if people who are familiar with (or must use/implement) this >> and if they understand it then fine. >> >>>>> >>>>> So I think display the values as (unsigned) integer or display it as >>>>> 0Xxxxxxxxx both will be OK. >>>>> Do you have the surggstions? >>>>> >> My personal feeling/thinking is that it is probably best displayed as >> 0Xxxxxxxxx. >> That (I would think) makes it easier to see bit positions as opposed to an >> (unsigned) integer. But in princople I can live with either. The idea/hope is >> that if you add a DISPLAY HINT that everyone displays it in the same way. > > > [fuyu]:Thank you for your suggestions. I will define it as below: > > RulePSID ::= TEXTUAL-CONVENTION > DISPLAY-HINT "0x:" > STATUS current > DESCRIPTION > "Represents ..." > SYNTAX OCTET STRING (SIZE (4)) > > mapRulePSID OBJECT-TYPE > SYNTAX RulePSID > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The PSID value algorithmically identifies a set of > ports assigned to a CE." > REFERENCE > "PSID: section 5.1 of RFC 7597." > ::= { mapRuleEntry 9 } > > Do you think it will be Ok? > >>>>> >>>>>> - Section 7. Security considerations: >>>>>> >>>>> These are the objects and their sensitivity/vulnerability: >>>>> >>>>> mapRuleIPv6PrefixType >>>>> >>>>> mapRuleIPv6Prefix >>>>> >>>>> ... etc (quite a list of objects). >>>>> >>>>> But nowhere do I see text about "their >>>>> sensitivity/vulnerability". ?? >>>>> Still to be added? >>>>> >>>>> [fuyu]: Some of the readable objects in this MIB module may be >>>>> considered sensitive or >>>>> vulnerable in some network environments. These objects are >>>>> readable, >>>>> so maybe they are considered sensitive or vulnerable in some use >>>>> case. >>>>> We have a description why they are sensitive or vulnerable above >>>>> the list of objects. >>>>> >>>>> Mmmm... can you point me to that text? I do not see that you describe >>>>> the vulnerability at any place. You do describe what the objects are >>>>> for, but that does not clearly explain what the security risks are if >>>>> some unauthorize person would see them. >>>>> >>>>> If you describe that at some other place in the document, then at >>>>> least I would suggest to add a pointer to that text in the Security >>>>> COnsiderations Secion. >>>>> >>>>> [fuyu]: Sorry. I should point it more clearly. It is in the paragraph 2 of the >>>>> section 7. >>>>> From the first sentence that "Some of the readable objects in this >>>>> MIB module may be >>>>> considered sensitive or vulnerable..." >>>>> >>>>> >> It states that they " may be considered sensitive of vulnerable". >> But it does not state WHY or IN WHAT CIRCUMSTANCES they might be >> vulnerable. >> What bad things are there that an intruder can do (or find out) when >> he/she gets read access to these objects? >> I.e. does he get to see confidential or private information? Does he learn >> about a competitors internal network structure? Or something else? > > [fuyu] : I will update it in more detail in this paragraph.Thanks. >> >> Bert > > Thanks again > Yu > > > --B_3577913755_241280046 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIYwwYJKoZIhvcNAQcCoIIYtDCCGLACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC FowwggV0MIIEXKADAgECAhAJ0fxYYYV36W1njUywVtW8MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNTAzMjYw MDAwMDBaFw0xODAzMjYxMjAwMDBaMIGQMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEYMBYGA1UEAxMPVGVycnkgTWFu ZGVyc29uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwTImt0Ol/9dOAbnm4lby 4RG1iQEnHVB5UJTYqwX8kqEhA5NPFHbMX22ChnP7M/zIlY+OP2TfKcwfdF5DJN4ybt4gFGzE 9ksigMe365F0uA2Q4+CskwqWo2fGIqrhgb0C68bg6EnZxj73KlJ0mvbQqzLBY8fVwr8srWpB BexjbYSeXp/+0W41ZOJPcdii59TDXRBGuziWjp+rd7yh8KCzKcj/Px1TzAE5U/TftZOfigYi h6KTTDZBGnN+4DDaaCnZ93rveayavI3hd4agqiIWe/gB78+0vHyk5DFoe6HkwuL0qJVaBW57 KIt8AYq+p0P+igNhiQoHkPx3VvS7ZViGdQIDAQABo4IB8jCCAe4wHwYDVR0jBBgwFoAU5wIj gABP2Ne8lAvZP3Q5STI8inkwHQYDVR0OBBYEFIXwv/ZX+K34v+mCL8g1Coo9c6lMMAwGA1Ud EwEB/wQCMAAwJAYDVR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8B Af8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYK YIZIAYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT MIGIBgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0 U0hBMkFzc3VyZWRJRENBLWcxLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcxLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2Nh Y2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG 9w0BAQsFAAOCAQEAH1Dvq3r4yh4+zU4t+5Rg3EzwMpSPxApBivVcW/KPq9uwdlu3yGBPJlG9 j4BXOT7fEUEGpCfyfRhBzTReyc2zask73fDRTzNFl5U3gqzOre5+Xtzv0qHyZGZ2EGcPTFv9 oaAVTug//Z6ZSr4dtDphV/7uSA4Hj1riFh5yxHErwUfrbCneIspVqwSVJqjkKWGID6W0YB0D cYJZGlyAH0FP/4+TMDxXOti2ypQrsZpNSfvc4TGC1p13Lyp4XEY+UysVtcypAgersTBN6gCb 7ueBt5KPTj9pH4w4C0lNO6rRIc6AGtJIuXHYyiy9CXUTOT5xLToXLZCyPXd+HFuWwdD9lzCC Bk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAw MFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBB c3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr +Lp+yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQ elAfJUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK 3OnZ9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uC ig1xGOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/ BAgwBgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9j cmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgB hv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCC AWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABD AGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBl AHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBD AFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBn AHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABp AHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQBy AGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8 lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrg YhmZpgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg 4/mgVgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmw XZG0k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1Y EhEybr1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3 MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20x JDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBa Fw0zMTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMx GTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQg SUQgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfz t2D5cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq 9g+YMjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OM M9nYLxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJ fDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwO sLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGG MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1Ud IwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w 43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbG easS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59Pyvz tyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2 BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdh AbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIHAzCCBeugAwIBAgIQD89pSVGb AJQ9+ZeKCcX9BTANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGln aUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSEwHwYDVQQDExhEaWdpQ2Vy dCBBc3N1cmVkIElEIENBLTEwHhcNMTIwMzI3MDAwMDAwWhcNMTUwMzI3MTIwMDAwWjCBrDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFzAVBgNVBAcTDk1hcmluYSBkZWwg UmV5MTwwOgYDVQQKEzNJbnRlcm5ldCBDb3Jwb3JhdGlvbiBmb3IgQXNzaWduZWQgTmFtZXMg YW5kIE51bWJlcnMxFzAVBgNVBAsTDkROUyBPcGVyYXRpb25zMRgwFgYDVQQDEw9UZXJyeSBN YW5kZXJzb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCkYWeFt1OjJ30tsKGB BQiMjfoNTDSC6JG1CpPj05eZpit0LVkMU0jrtrHczcRzMuqdkaE/QTBjmprbRatlrMEq7uv+ yU9U35crRmjx3yuZDD/6SOO4ZnMFBJvWdevSOWq+8wU4hAEANOnBirYCfF4oixVCBy1bkat1 hsY5xUx5QB12OpnYA0/57QJ6BL7z1ZuF6lJ4yYmU0qI88q9atkahb8l7Nm5TgEbpg6ryyN98 ixnFLmhC/gPoYKHczP3y+JHaMveuJl75hHq6ZuHeH2PyX20VFsXNBKJrvZ8BhTZOoozuNapP jiG6HLdqngPuTz3JVyTTR2FX809nclnxoMWjAgMBAAGjggNoMIIDZDAfBgNVHSMEGDAWgBQV ABIrE5iymQftHt+ivlcNK2cCzTAdBgNVHQ4EFgQUs8L0dmF6T/V40vXJJzF+YNyzNo0wJAYD VR0RBB0wG4EZdGVycnkubWFuZGVyc29uQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9j cmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3JsMDigNqA0hjJodHRw Oi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURDQS0xLmNybDCCAcUGA1Ud IASCAbwwggG4MIIBtAYKYIZIAYb9bAQBAjCCAaQwOgYIKwYBBQUHAgEWLmh0dHA6Ly93d3cu ZGlnaWNlcnQuY29tL3NzbC1jcHMtcmVwb3NpdG9yeS5odG0wggFkBggrBgEFBQcCAjCCAVYe ggFSAEEAbgB5ACAAdQBzAGUAIABvAGYAIAB0AGgAaQBzACAAQwBlAHIAdABpAGYAaQBjAGEA dABlACAAYwBvAG4AcwB0AGkAdAB1AHQAZQBzACAAYQBjAGMAZQBwAHQAYQBuAGMAZQAgAG8A ZgAgAHQAaABlACAARABpAGcAaQBDAGUAcgB0ACAAQwBQAC8AQwBQAFMAIABhAG4AZAAgAHQA aABlACAAUgBlAGwAeQBpAG4AZwAgAFAAYQByAHQAeQAgAEEAZwByAGUAZQBtAGUAbgB0ACAA dwBoAGkAYwBoACAAbABpAG0AaQB0ACAAbABpAGEAYgBpAGwAaQB0AHkAIABhAG4AZAAgAGEA cgBlACAAaQBuAGMAbwByAHAAbwByAGEAdABlAGQAIABoAGUAcgBlAGkAbgAgAGIAeQAgAHIA ZQBmAGUAcgBlAG4AYwBlAC4wdwYIKwYBBQUHAQEEazBpMCQGCCsGAQUFBzABhhhodHRwOi8v b2NzcC5kaWdpY2VydC5jb20wQQYIKwYBBQUHMAKGNWh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRENBLTEuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcN AQEFBQADggEBAGKcMSvyr3YW8kKqyqdspTEKTc6lR6H6OITyC056f6PlMmFZ+nWlkopWlflz QcxOUZv3+5rNogNcwczrxr+eaSx9J+pYCEU3rgBs3yiLDwsD72EJJDAD1x84fQOOJtfYb4oE 4Djzco83Dk4h6sMAiUg0xGcdewhJK80D6tb3xtS75PgFoxLcQrBprLghx2mY8EPErBiO1uXA NWOEU3EH+kvXiKUrDsFyGHQ4FqvVIYv2plu68ltOmBh+wR2oraoJpt9jGbond1MyVFOvi48e 7hgPRXupNbjxB4Wl0wKKGz0qT3ToBpp8VAkULtjiO/iPLx4knuwwvy5sRAwuZAfpVE4xggH/ MIIB+wIBATB5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNV BAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJ RCBDQQIQCdH8WGGFd+ltZ41MsFbVvDAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFM5O bcWHcOLvP8dYn1pLDZtHbqV5MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcN AQkFMQ8XDTE3MDUxNzE0NTU1NVowDQYJKoZIhvcNAQEBBQAEggEAAO417ovKSERuVwkpAJgs mPPCKnikVWdqObcXQp8MSQEg8OU4Jp/HH16WCHEUGVUxRdl0v+dKDjmyNH1YCzjbHHEmO3II 2ce5paTpISUyi4/ywJUQPEzC3yEK76TbwVRzUgjhBrm6HJCGceGKIAa90JN0WaN0KKx7sb3F HO9OcDicptCLyuuPfCApnGJuldtCfJQFx869O1FjOZVa5VPp194AcZP67+F8sPa6V10l0hxk Uj+1R0nzTBl36ZMYDk5cTN+dM2jChqVt+pQTrR6rY2Oqi5WpDO9rj2HDroaQabdQbTflTBBR lVWfvBMymotIU4gi1j4NNFZnNXYOMjiO5g== --B_3577913755_241280046-- From nobody Wed May 17 18:53:51 2017 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0601279E5; Wed, 17 May 2017 18:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 aOSdwtvQC7pO; Wed, 17 May 2017 18:53:48 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1797412947C; Wed, 17 May 2017 18:53:43 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.232]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZa+uH_hxZay6yKg--.42202S3; Thu, 18 May 2017 09:53:13 +0800 (CST) From: "Yu Fu" To: , "'Bert Wijnen \(IETF\)'" Cc: , "'MIB Doctors'" , References: <003201d2cad9$c83bec50$58b3c4f0$@cn> <6874911d-0535-8206-d96d-99a956c5bf85@bwijnen.net> <002201d2ce13$73ccd570$5b668050$@cn> <27ba3af4-49b4-17ee-a0f9-cb280a5141cb@bwijnen.net> <002401d2cedd$6efb6870$4cf23950$@cn> In-Reply-To: Date: Thu, 18 May 2017 09:53:23 +0800 Message-ID: <003001d2cf79$8a40a310$9ec1e930$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHSzt4ufXUW3DrbCUefV2/mMb2PhqH5up6A//+YvZA= Content-Language: zh-cn X-CM-TRANSID: AQAAf0BZa+uH_hxZay6yKg--.42202S3 X-Coremail-Antispam: 1UD129KBjvdXoWrJr4xZFWxKr4UCFWkZFWrZrb_yoWxWrcE9F 429rnrKrWDAF48Z3ZFvrsa9anaga97ua4UA345Kr1ft34UA3s2vrnYv395Zw1UJFyjkFnr CF12qF1Yk34FgjkaLaAFLSUrUUUUUb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUb2xYjsxI4VWxJwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0 cI8IcVCY1x0267AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVWxJr0_GcWle2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xv F2IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r 4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwCY02Avz4vE14v_KwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUc8nYUUUUU X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [MIB-DOCTORS] early MIB Doctor review for draft-ietf-softwire-map-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: Thu, 18 May 2017 01:53:50 -0000 Thanks Terry and Bert, An updated version will be submitted soon. Cheers Yu >-----Original Message----- >From: terry.manderson@icann.org [mailto:terry.manderson@icann.org] >Sent: Wednesday, May 17, 2017 10:56 PM >To: Bert Wijnen (IETF); Yu Fu >Cc: draft-ietf-softwire-map-mib.all@ietf.org; 'MIB Doctors'; >softwires@ietf.org >Subject: Re: early MIB Doctor review for draft-ietf-softwire-map-mib-07 > >Bert, Yu, > >Thank you very much for your review and activity on this! > >Cheers >Terry >> >>On 17/05/2017, 5:17 PM, "Bert Wijnen (IETF)" >>wrote: >> >> thank you. I am happy mow >> >> Bert From nobody Wed May 24 23:15:21 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 0B263129C3D; Wed, 24 May 2017 23:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wIwtDbFatLM; Wed, 24 May 2017 23:15:11 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 704BA129C40; Wed, 24 May 2017 23:15:08 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.146]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5jOxXdiZZz1e1Kg--.45266S3; Thu, 25 May 2017 14:14:47 +0800 (CST) From: "Yu Fu" To: Cc: , "'MIB Doctors'" , Date: Thu, 25 May 2017 14:14:53 +0800 Message-ID: <003701d2d51e$39503a60$abf0af20$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdLVGkWOKVhAssyATxymAkAGncdSbAAAZNzA X-CM-TRANSID: AQAAf0B5jOxXdiZZz1e1Kg--.45266S3 X-Coremail-Antispam: 1UD129KBjvJXoWxAr1UWrW3ZF1fWw15Jr43Jrb_yoW5Jw1UpF Z3t398CrWxta1kK3ykWF1Fv3ZYv3s5trWxuFn8Jr1xZ3yUJ3ZFyF10kryYyr9rJryrKw4x AF48uw15Xan5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkIb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8AwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_JF0_Jw1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvE x4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU8pyIUUUUUU== X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [MIB-DOCTORS] FW: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.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: Thu, 25 May 2017 06:15:13 -0000 Hi Bert, Thanks for your MIB doctor review. I have updated the 08 version based on all your comments. Please see whether it fix all your comments. I have another question when I do the MIB module validation as the Severity level is set to 6(most strict). It has warnings as below. warning: `InetAddress' should be used instead of `InetAddressIPv6' warning: `InetAddress' should be used instead of `InetAddressIPv4' It is because we define the mapRuleIPv6Prefix and mapRuleIPv4Prefix as below: mapRuleIPv6Prefix OBJECT-TYPE SYNTAX InetAddressIPv6 MAX-ACCESS read-only STATUS current DESCRIPTION mapRuleIPv4Prefix OBJECT-TYPE SYNTAX InetAddressIPv4 MAX-ACCESS read-only STATUS current DESCRIPTION Shall we ignore these warnings? Thanks a lot Cheers Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, May 25, 2017 1:46 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires of the IETF. Title : Definitions of Managed Objects for MAP-E Authors : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-08.txt Pages : 15 Date : 2017-05-24 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation (MAP-E) mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-map-mib-08 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From nobody Thu May 25 02:04: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 AAAA2129400; Thu, 25 May 2017 02:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 meElo3rg41zI; Thu, 25 May 2017 02:04:32 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD57B1270A3; Thu, 25 May 2017 02:04:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E94A176; Thu, 25 May 2017 11:04:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Avl1WB3w_HNq; Thu, 25 May 2017 11:04:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 May 2017 11:04:28 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A131F20063; Thu, 25 May 2017 11:04:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7HVsK-cdb_F1; Thu, 25 May 2017 11:04:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C37C020062; Thu, 25 May 2017 11:04:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9299A3F574C1; Thu, 25 May 2017 11:04:26 +0200 (CEST) Date: Thu, 25 May 2017 11:04:25 +0200 From: Juergen Schoenwaelder To: Yu Fu Cc: bertietf@bwijnen.net, softwires@ietf.org, 'MIB Doctors' , draft-ietf-softwire-map-mib.all@ietf.org Message-ID: <20170525090425.GA41496@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Yu Fu , bertietf@bwijnen.net, softwires@ietf.org, 'MIB Doctors' , draft-ietf-softwire-map-mib.all@ietf.org References: <003701d2d51e$39503a60$abf0af20$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003701d2d51e$39503a60$abf0af20$@cn> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [MIB-DOCTORS] FW: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.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: Thu, 25 May 2017 09:04:35 -0000 Hi, since these objects seem to be IP version specific, I think it is OK to ignore the warning. Perhaps consider adding comment such as: -- The object mapRuleIPv6Prefix is IPv6 specific and hence it does -- not use the version agnostic InetAddress. This way, it is documented that any warnings related to this can be ignored. (Otherwise, this question may come up again.) /js On Thu, May 25, 2017 at 02:14:53PM +0800, Yu Fu wrote: > Hi Bert, > > Thanks for your MIB doctor review. > > I have updated the 08 version based on all your comments. Please see whether > it fix all your comments. > > I have another question when I do the MIB module validation as the Severity > level is set to 6(most strict). It has warnings as below. > > warning: `InetAddress' should be used instead of `InetAddressIPv6' > warning: `InetAddress' should be used instead of `InetAddressIPv4' > > It is because we define the mapRuleIPv6Prefix and mapRuleIPv4Prefix as > below: > mapRuleIPv6Prefix OBJECT-TYPE > SYNTAX InetAddressIPv6 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > > mapRuleIPv4Prefix OBJECT-TYPE > SYNTAX InetAddressIPv4 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > > Shall we ignore these warnings? > > Thanks a lot > > Cheers > > Yu > > -----Original Message----- > From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Thursday, May 25, 2017 1:46 PM > To: i-d-announce@ietf.org > Cc: softwires@ietf.org > Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Softwires of the IETF. > > Title : Definitions of Managed Objects for MAP-E > Authors : Yu Fu > Sheng Jiang > Bing Liu > Jiang Dong > Yuchi Chen > Filename : draft-ietf-softwire-map-mib-08.txt > Pages : 15 > Date : 2017-05-24 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for using with network management protocols in the Internet > community. In particular, it defines managed objects for MAP > encapsulation (MAP-E) mode. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-softwire-map-mib-08 > https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu May 25 19:51:27 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 AA911129B69; Thu, 25 May 2017 19:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 aN1tYO82z4kp; Thu, 25 May 2017 19:51:18 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 253C21279EB; Thu, 25 May 2017 19:51:16 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.16]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0C5wVUOmCdZLaa1Kg--.48213S3; Fri, 26 May 2017 10:50:55 +0800 (CST) From: "Yu Fu" To: "'Juergen Schoenwaelder'" Cc: , , "'MIB Doctors'" , References: <003701d2d51e$39503a60$abf0af20$@cn> <20170525090425.GA41496@elstar.local> In-Reply-To: <20170525090425.GA41496@elstar.local> Date: Fri, 26 May 2017 10:50:59 +0800 Message-ID: <002d01d2d5ca$e88c13d0$b9a43b70$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdLVNe/HukKrk9BkQkugf9AG5E/quwAkBwcg X-CM-TRANSID: AQAAf0C5wVUOmCdZLaa1Kg--.48213S3 X-Coremail-Antispam: 1UD129KBjvJXoWxGFW7Aw1xCF4xur1kZF4xJFb_yoWrZF4UpF WxJF4qkr48Jw18Gw4vgF18ZwnYv34fJrWUWrn8Jr17K34Dt3WDtr10kryrCr9rJr1rJr4I yr4UCry3XFs8ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4UMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07j5wIDUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: Re: [MIB-DOCTORS] FW: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.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: Fri, 26 May 2017 02:51:21 -0000 Hi Juergen, Thank you for your reply. OK. I will add a note in the MIB. Cheers Yu >-----Original Message----- >From: j.schoenwaelder@jacobs-university.de >[mailto:j.schoenwaelder@jacobs-university.de] >Sent: Thursday, May 25, 2017 5:04 PM >To: Yu Fu >Cc: bertietf@bwijnen.net; softwires@ietf.org; 'MIB Doctors'; >draft-ietf-softwire-map-mib.all@ietf.org >Subject: Re: [MIB-DOCTORS] FW: [Softwires] I-D Action: >draft-ietf-softwire-map-mib-08.txt > >Hi, > >since these objects seem to be IP version specific, I think it is OK to ignore >the warning. Perhaps consider adding comment such as: > > -- The object mapRuleIPv6Prefix is IPv6 specific and hence it does > -- not use the version agnostic InetAddress. > >This way, it is documented that any warnings related to this can be ignored. >(Otherwise, this question may come up again.) > >/js > >>On Thu, May 25, 2017 at 02:14:53PM +0800, Yu Fu wrote: >> Hi Bert, >> >> Thanks for your MIB doctor review. >> >> I have updated the 08 version based on all your comments. Please see >> whether it fix all your comments. >> >> I have another question when I do the MIB module validation as the >> Severity level is set to 6(most strict). It has warnings as below. >> >> warning: `InetAddress' should be used instead of `InetAddressIPv6' >> warning: `InetAddress' should be used instead of `InetAddressIPv4' >> >> It is because we define the mapRuleIPv6Prefix and mapRuleIPv4Prefix as >> below: >> mapRuleIPv6Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv6 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> >> mapRuleIPv4Prefix OBJECT-TYPE >> SYNTAX InetAddressIPv4 >> MAX-ACCESS read-only >> STATUS current >> DESCRIPTION >> >> Shall we ignore these warnings? >> >> Thanks a lot >> >> Cheers >> >> Yu >> >> -----Original Message----- >>>>>>> From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] >>>>>>> On Behalf Of internet-drafts@ietf.org >>>>>>> Sent: Thursday, May 25, 2017 1:46 PM >>>>>>> To: i-d-announce@ietf.org >>>>>>> Cc: softwires@ietf.org >>>>>>> Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-08.txt >>>>>>> >>>>>>> >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>>> directories. >>>>>>> This draft is a work item of the Softwires of the IETF. >>>>>>> >>>>>>> Title : Definitions of Managed Objects for MAP-E >>>>>>> Authors : Yu Fu >>>>>>> Sheng Jiang >>>>>>> Bing Liu >>>>>>> Jiang Dong >>>>>>> Yuchi Chen >>>>>>> Filename : draft-ietf-softwire-map-mib-08.txt >>>>>>> Pages : 15 >>>>>>> Date : 2017-05-24 >>>>>>> >>>>>>> Abstract: >>>>>>> This memo defines a portion of the Management Information Base >>>>>>(MIB) >>>>>>> for using with network management protocols in the Internet >>>>>>> community. In particular, it defines managed objects for MAP >>>>>>> encapsulation (MAP-E) mode. >>>>>>> >>>>>>> >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ >>>>>>> >>>>>>> There are also htmlized versions available at: >>>>>>> https://tools.ietf.org/html/draft-ietf-softwire-map-mib-08 >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-08 >>>>>>> >>>>>>> A diff from the previous version is available at: >>>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-08 >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission until the htmlized version and diff are available at >>>>>>tools.ietf.org. >>>>>>> >>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Softwires mailing list >>>>>>> Softwires@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/softwires >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> MIB-DOCTORS mailing list >>>>>>> MIB-DOCTORS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>>> >>>>>>-- >>>>>>Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>>>>>Germany >>>>>>Fax: +49 421 200 3103 From nobody Fri May 26 05:26:07 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 53FF61294CD for ; Fri, 26 May 2017 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, 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 awm2CB3LFBn3 for ; Fri, 26 May 2017 05:25:56 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 CF2A21294CE for ; Fri, 26 May 2017 05:25:55 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id c13so6686207qtc.1 for ; Fri, 26 May 2017 05:25:55 -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=h7gvtNVWf70Gl2Sm8kVjF3wB18FO/Bs/sIIFJRh3aRc=; b=zyh2NE512544TPeVthVCNBKs9Shika8C8VSK9YVWmUl9DvexTH6r9mHa4ydVsNDD8P Z9aqzNL1Wk2Agf3Grla1toElUcwz756G2K+J1pFZu8VmAdmwADGGUvmsiwHG34BX9SyN t5y4EOxl1oeKUMOJpB6o64YsvGZDga0cd81w/bv1EwRAR1lidabKLUMteDzh0cP2ktbF BRfb45VPQgckv2XcDUQZSzWMg/W3LhZGSt4jlT+1/DY3jFvCSEAaAQnHdCt/JyCsnpQs qZXT6uM9nBZA1B48uu1C4WJClYSh7Mq+0f3NcKuKkzjqgNxXuC8H1NmU3Z7QAweKE0s2 9jsw== 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=h7gvtNVWf70Gl2Sm8kVjF3wB18FO/Bs/sIIFJRh3aRc=; b=uLxGpQqzaJVYZSAl+4+Uwh92gC+2AyvJ7xtxKGW3nF3xa/mLHGqn64Mev2dALJaeNq rGiv/XOaxaCEvo+CLMzyR2UKXAUvv4PIKZ9riAJcDvP6Br3O7SKAQO0KOtPSI0z90MMy 4Cp+FuGmBrEFJaBvZ3rEPOR9w5k6++Gkt7h00TDCshDr4sqNQ5/hdXUHLHa9PxH2vwmO z7QDdyJZQ8gx9/oI1x/ASE5OweN53+75JF04Mms4L9nEhkXCvOa/rQqIMvOn+cn2atij Xl3UNnNOFooILZ4N7PlbN4Pury31SfCafz7v/oy+IdhFf3rz0hqCw9/+QRZRp0N2JqD2 HknA== X-Gm-Message-State: AODbwcBferXvYdg37AjfTwxNQIAhdZN60Z/g83xduO1URy1o771fWvn6 r5neLAlWQUUVPGyQBBtI3rZGvNItcksw X-Received: by 10.200.47.73 with SMTP id k9mr1928538qta.11.1495801554816; Fri, 26 May 2017 05:25:54 -0700 (PDT) MIME-Version: 1.0 Sender: dr.h.t@ieee.org Received: by 10.140.101.140 with HTTP; Fri, 26 May 2017 05:25:14 -0700 (PDT) In-Reply-To: References: <56E7D219.7000902@orange.com> <56FBD402.9040102@cisco.com> <56FBDD81.6080502@cysols.com> <11152_1459347064_56FBDE78_11152_10229_1_56FBDE77.6030605@orange.com> <56FBE17E.5090609@cisco.com> <570C9586.7030905@cysols.com> <5e663cf0-1418-c410-bcf8-b235ee73fc29@cysols.com> <6f89f1f2-31e9-bf4a-05e9-1bb6e02f339e@cysols.com> <03f83a27-e397-818d-65e7-27f95cd6e6e0@cysols.com> <8f9aaac8-f44d-4844-d376-9c37bd7a81e0@cysols.com> <1848f053-9a5e-2f52-09b4-ce0e1688b557@cysols.com> From: Hiroshi Tsunoda Date: Fri, 26 May 2017 14:25:14 +0200 X-Google-Sender-Auth: sVQX3A_JW-9m8hMTw2BFZUNrkhE 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: Fri, 26 May 2017 12:25:59 -0000 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 Sat May 27 01:44:09 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 196621279E5; Sat, 27 May 2017 01:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2iG-IgZqB9c; Sat, 27 May 2017 01:43:58 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id B18E1126D45; Sat, 27 May 2017 01:43:57 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.174]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0ApMuJBPClZRQ+2Kg--.44980S3; Sat, 27 May 2017 16:43:45 +0800 (CST) From: "Yu Fu" To: Cc: "'Juergen Schoenwaelder'" , "'MIB Doctors'" , , Date: Sat, 27 May 2017 16:43:48 +0800 Message-ID: <002101d2d6c5$5c471770$14d54650$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdLWxGOXrFkopQx3RN2BL44RWW6E2QAACCcA Content-Language: zh-cn X-CM-TRANSID: AQAAf0ApMuJBPClZRQ+2Kg--.44980S3 X-Coremail-Antispam: 1UD129KBjvJXoW7trWxJFyxXw4ruF15AFy7Jrb_yoW8CryfpF WxZ398Gw1fJ3W8K397WF1F9w1vv3s5trWfCFn8Jr10vayUJ3WktF10kryrA39rJrWrGr4x AF48uw15Xan5XrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r43MxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jwXo7UUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [MIB-DOCTORS] FW: [Softwires] I-D Action: draft-ietf-softwire-map-mib-09.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: Sat, 27 May 2017 08:44:01 -0000 Hi all, I have updated the 09 version based on Juergen's suggestions. Thanks. Comments are appreciated. Yu -----Original Message----- From: softwires-bounces@ietf.org [mailto:softwires-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Saturday, May 27, 2017 4:37 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-09.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires of the IETF. Title : Definitions of Managed Objects for MAP-E Authors : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-09.txt Pages : 15 Date : 2017-05-27 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation (MAP-E) mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-softwire-map-mib-09 https://datatracker.ietf.org/doc/html/draft-ietf-softwire-map-mib-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From nobody Sun May 28 15:35:10 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 72D42126C23; Sun, 28 May 2017 15:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 NydItzdTKg5i; Sun, 28 May 2017 15:35:01 -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 AE905126BFD; Sun, 28 May 2017 15:35:00 -0700 (PDT) Received: from [192.168.0.92] (cysvpn05.priv.cysol.co.jp [192.168.0.92]) (authenticated bits=0) by aso.priv.cysol.co.jp (8.14.9/8.14.9) with ESMTP id v4SMYpSC081041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 29 May 2017 07:34:52 +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: <3c7ef211-7c41-ecee-7465-3987a890ce55@cysols.com> Date: Mon, 29 May 2017 07:34:46 +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: Sun, 28 May 2017 22:35:03 -0000 Dear Tsuno, Thanks for the good work. I will review and get back to you. Glenn 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 >