Bert, Yu, Thank you very much for your review and activity on this!
Cheers Terry On 17/05/2017, 5:17 PM, "Bert Wijnen (IETF)" <[email protected]> wrote: 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 > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
