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

["Yu Fu" <[e-mail]>]

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.

>>
>>
>>    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."
>>           ::= { 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.

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

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
     
      mapRulePSIDLen  OBJECT-TYPE
           SYNTAX     Unsigned32(0..16)
    
  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