Subject: [MIB-DOCTORS] question on InetAddressType/InetAddress

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 27 Jan 2009 11:58:01 +0100

While re-reviewing  aprelimenary new version of the mgmd-mib, 
I see things like:

mgmdRouterCacheAddressType OBJECT-TYPE
    SYNTAX     InetAddressType
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
            "The address type of the mgmdRouterCacheTable entry. This
            value applies to both the mgmdRouterCacheAddress and the
            mgmdRouterCacheLastReporter entries."
    ::= { mgmdRouterCacheEntry 1 }

mgmdRouterCacheAddress OBJECT-TYPE
    SYNTAX      InetAddress (SIZE(4|16))
    MAX-ACCESS not-accessible
    STATUS     current
    DESCRIPTION
            "The IP multicast group address for which this entry
            contains information. The InetAddressType, e.g.
            IPv4 or IPv6, is identified by the
            mgmdRouterCacheAddressType variable in the mgmdRouterCache
            table."
    ::= { mgmdRouterCacheEntry 2 }

I have spoken with Brian Haberman (editor of this document) and my understanding
is that he is firm in stating that they only want to allow IPv4/IPv6 addresses. 

So that is why he/they put  the SIZE(4|16) in the InetAddress Syntax.
If such is the case, then I feel one might as well (in fact I think it is better)
put InetAddressType (ipv4,ipv6) as subtype for the AddressType.

Do other MIB doctors agree with me?

Bert Wijnen

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 27 Jan 2009 12:15:03 +0100

On Tue, Jan 27, 2009 at 11:58:01AM +0100, Bert Wijnen (IETF) wrote:

> I have spoken with Brian Haberman (editor of this document) and my
> understanding is that he is firm in stating that they only want to
> allow IPv4/IPv6 addresses.
> 
> If such is the case, then I feel one might as well (in fact I think
> it is better) put InetAddressType (ipv4,ipv6) as subtype for the
> AddressType.

Yes, if they want to restrict things to IPv4/IPv6, they should do this
via the enumeration since the size restriction still allows e.g. DNS
names with 4/16 characters.

I hope they also by intention disallow scoped addresses... Otherwise,
the size restriction needs to be changed or removed completely.

/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/>
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "David Harrington" <[email-masked]>
Date: Tue, 27 Jan 2009 10:03:28 -0500

+1

A question: if a technology change made it possible
protocol-sense-wise to use a different type of address, e.g. a DNS
address, in the future, will SMIv2 change rules permit the
InetAddressType IPv4/IPv6 restriction to be changed? It is an
enumeration, and usually it is possible to add new enumerations. But
here we deal with restrictions; SMIv2 does not (seem to) discuss
adding and lifting restrictions to enumeration values. How do we plan
to handle that? or do we wait until a real case emerges to worry about
it?

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen 
> Schoenwaelder
> Sent: Tuesday, January 27, 2009 6:15 AM
> To: Bert Wijnen (IETF)
> Cc: MIB Doctors (E-mail); Brian Haberman
> Subject: Re: [MIB-DOCTORS] question on InetAddressType/InetAddress
>

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Tue, 27 Jan 2009 16:09:26 +0100

For that, I discussed with Brian that

- if he ever expects that other than ipv4/ipv6 addresses would make sense,
  that in that case he would use the MODULE-COMPLIANCE to indicate
  what is to be supported today. And then if any otehr type is needed in the
  future, then they can do a new MODULE-COMPLIANCE without changing
  the MIB module itself.
- if they expect that they will NEVER have to support anything else than IPv4
  and IPv6, then this approach seems best. If it turns out the the NEVER is
  not really NEVER, then at that time we will have to find out how flexible
  the mib-doctors at that time will be, and depending on that, they will
  have to deprecate these objects and create new ones or they may
  be allow to change the sybtypes.

Bert
  ----- Original Message ----- 
  From: David Harrington 
  To: [email-masked] ; 'Bert Wijnen (IETF)' 
  Cc: 'MIB Doctors (E-mail)' ; 'Brian Haberman' 
  Sent: Tuesday, January 27, 2009 4:03 PM
  Subject: RE: [MIB-DOCTORS] question on InetAddressType/InetAddress

  +1

  dbh

---

From: Dave Thaler <[email-masked]>
Date: Tue, 27 Jan 2009 11:04:12 -0800

Juergen Schoenwaelder writes:
[...]
> the size restriction needs to be changed or removed completely.

Yes this is by intent.  Since the objects are already per-interface,
a scope ID is never necessary.

-Dave