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