Subject: [MIB-DOCTORS] help please - InetAddressType/InetAddress

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 13 Oct 2011 12:23:55 +0200

I am working in the SIDR WG to create a rpkiRouterMib module.

They have large (can go up to 500K entries) tables that are
to be indexed by InetAddressType, InetAddress, InetPortNumber.

In principle, they only need ipv4 and ipv6 (current discussion
seems to not even want to allow for ipv4z or ipv6z). Not clear
yet if dns is wanted. I personally would be against allowing dns
in these huge tables because of indexing limitations and overhead
if we use dns names.

So my advise I think is that even in the OBJECT-TYPE definition
we will be explicit in stating that only ipv4 and ipv6 are valid
(allowed) values, and so for InetAddress we can limit the size to
(4|16).

Any objections against such advise?
Or any other comments/suggestions?

Thanks,
Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Oct 2011 12:42:34 +0200

> Or any other comments/suggestions?

In some MIB modules, we have expressed address type constraints in
compliance statements rather than constraining the object definition:

        OBJECT      fooType
        SYNTAX      InetAddressType { ipv4(1), ipv6(2) }
        DESCRIPTION
            "An implementation is only required to support global IPv4
             and/or IPv6 address types."

This way, the object definition itself is not constrained but a
compliant implementation can be created by just supporting global IPv4
and/or IPv6 addresses (and the object definition would happily support
IPv8 if that were ever to happen ;-).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Thu, 13 Oct 2011 13:15:59 +0200

Inline

> IPv8 if that were ever to happen ;-).

YES, I am aware of that.
But if I do it that way, then (since the objects are used as Indices) I
MUST explain things like:
- make sure to not create indices that are more than 128 subIDs
- when dns gets resolved if they use it
- etc
And none of that seems needed in the forseeable future if I just
be explicit in the OBJECT-TYPE as opposed to the module-compliance.
In the MODULE compliance I also have to put it in as comments,
since they are index objects and so I cannot list them as OBJECTs.

Oh well.

Bert

---

From: Harrie Hazewinkel <[email-masked]>
Date: Thu, 13 Oct 2011 13:30:48 +0200

Hi,

Would it not make sense to have a specific object that just combines
the two kinds (ipv4 and ipv6) of the InetAddress and so the DNS part
just by type 'ignores'?

I somehow see the need to be flexible enough to have all future changes
possible and supported, but should we not look at today and not to
some potential ipv8 (or ipv10, ..)?

Just thinking of the concern of Bert regarding the indexes and what it
would bring that other InetAddressTypes are supported.

regards,
Harrie

On Oct 13, 2011, at 1:15 PM, Bert Wijnen (IETF) wrote:

> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

Harrie
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 13 Oct 2011 13:51:23 +0200

> since they are index objects and so I cannot list them as OBJECTs.

OK, I missed the INDEX part. Well, if the WG is sure nothing else than
global IPv4 and IPv6 addresses will ever be needed, just subtype the
object definitions. I am not familiar with the RPKI stuff so I simply
have no clue. ;-)

/js

---

From: Michael MacFaden <[email-masked]>
Date: Sat, 15 Oct 2011 21:59:46 -0700

Hi Bert

This restriction seems reasonable to me. The rationale added to the mib
module should be clear as to why the limitation exists.

Mike
On Oct 13, 2011 3:24 AM, "Bert Wijnen (IETF)" <[email-masked]> wrote:

> ______________________________**_________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mib-doctors<https://www.ietf.org/mailman/listinfo/mib-doctors>
>