Re: [MIB-DOCTORS] InetAddress SIZE rules.

["Bert Wijnen (IETF)" <[e-mail]>]

Juergen, thanks for the answer. I think we agree.
You may worry that your answer is not clear? Maybe my review comments to
the authors is even less clear. But I agree that what they have done does not seem
very efficient (having a saparate object/pair (InetAddressType/Inetaddress) for IPv4 and
one for IPv6. I think I made that clear in my comments to authors too (I did send a copy
to MIB doctors list). Feel free to jump in if you want to.

Bert

On 08/05/2017 16:38, Juergen Schoenwaelder wrote:
> On Mon, May 08, 2017 at 04:02:12PM +0200, Bert Wijnen (IETF) wrote:
>> In https://tools.ietf.org/html/draft-ietf-softwire-map-mib-07
>> I see:
>>
>>    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?
>>
>> Juergen (or anyone else) can you confirm if my understanding is correct?
>>
>
> It seems the objects in question are always representing IPv6
> prefixes, that is, mapRuleIPv6PrefixType is essentially a constant as
> if it were subtyped to only include the value ipv6(2). The question is
> whether using the triple (InetAddressType, InetAddress,
> InetAddressPrefixLength) is really useful and the suggested way of
> doing things. This must have come up before but I think I garbage
> collected this part of my memory. Using the triple is good for generic
> tools, exchanging constants on the other hand is also not very
> efficient.
>
> Right now, I would say that InetAddress(SIZE (0..16)) is consistent
> with InetAddressType, i.e., the machine readable information says this
> is a generic Internet address. The other alternative would be to use
> InetAddressType { ipv6(2) } and InetAddress(SIZE (16)) and then both
> together indicate to tools that this is by no means a generic Internet
> address. Doing a mixture of both seems inconsistent - but on the wire
> you will anyway get InetAddressType { ipv6(2) } and InetAddress(SIZE
> (16)).
>
> Sorry for not providing a clear answer.
>
> /js
>