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