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
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
