The MPLS WG Archive

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

If you are going to make any more changes, then pls do
consider this (which I think got lost between the cracks):

> > >Bert> > >We are discussing similar change for RFC3291bis.
> > >
> > >For TeHopAddress you have:
> > >
> > >             When this TEXTUAL-CONVENTION is used as the syntax of an
> > >             index object, there may be issues which the limit of 128
> > >             sub-identifiers specified in SMIv2, STD 58. In this case,
> > >             the object definition MUST include a 'SIZE' clause to
> > >             limit the number of potential instance sub-identifiers."
> > >         SYNTAX     OCTET STRING (SIZE (0..255))
> > >
> > >The MIST include a 'SIZE' might be better rephrased as:
> > >
> > >          When this TEXTUAL-CONVENTION is used as the syntax of an
> > >          index object, there may be issues with the limit of 128
> > >          sub-identifiers specified in SMIv2, STD 58. In this case,
> > >          the object definition MUST include a 'SIZE' clause to
> > >          limit the number of potential instance sub-identifiers
> > >          or else the applicable constraints MUST be stated in the
> > >          appropriate conceptual row DESCRIPTION clauses or in the
> > >          surrounding documentation if there is no single DESCRIPTION
> > >          clause that is appropriate."
> > >         SYNTAX     OCTET STRING (SIZE (0..255))
> > >
> > >I wonder if SIZE(0..255) is not too generous. The TeHopAddressTypes defined
> > >sofar all fit within 16 octets I believe. What sort of (longer) address types
> > >do we expect in the future? DNS names? The DNS names is the reason for 255
> > >in RFC3291. If we never expect to use them... maybe the 255 is a bit too
> > >much?
> > >
> > >Thanks,
> > >Bert
Thanks,
Bert