[Softwires] FW: early MIB Doctor review for draft-ietf-softwire-map-mib-07

"Yu Fu" <fuyu@cnnic.cn> Tue, 16 May 2017 07:13 UTC

Return-Path: <fuyu@cnnic.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C63129480; Tue, 16 May 2017 00:13:02 -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 wrSV73UfQQBB; Tue, 16 May 2017 00:12:59 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 65E4F129C48; Tue, 16 May 2017 00:10:00 -0700 (PDT)
Received: from LIUXD (unknown [218.241.103.213]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5hubDpRpZQJixKg--.40173S3; Tue, 16 May 2017 15:09:55 +0800 (CST)
From: Yu Fu <fuyu@cnnic.cn>
To: softwires@ietf.org
Cc: softwire-chairs@ietf.org
Date: Tue, 16 May 2017 15:10:07 +0800
Message-ID: <002101d2ce13$7386f2d0$5a94d870$@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: AdLICzQDa7vUXcvIRTKNfLp9wiksMwGB3CQA
Content-Language: zh-cn
X-CM-TRANSID: AQAAf0B5hubDpRpZQJixKg--.40173S3
X-Coremail-Antispam: 1UD129KBjvJXoWxKr1DXFWrCFWxCFWruw1DGFg_yoW3XrW8pF Z3Ka1YkrWDJFsrCrZ7Ww4vqasYyFn7GFW7Gr98Xryjkws8JF97tF4Ygas5Xa4DGr40qw4j qrWYvryrGFZ8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkFb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4xMxAIw28I cxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2 IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI 42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42 IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E 87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07bo-BiUUUUU=
X-CM-SenderInfo: pix13q5fqqxugofq/
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/aUgu-rMrVrS_JY3S0Q2h82aR2Ps>
Subject: [Softwires] FW: early MIB Doctor review for draft-ietf-softwire-map-mib-07
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 May 2017 07:13:02 -0000

I have forgotten to forward the early MIB Doctor review to the WG. Sorry...

-----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.

- 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