The MPLS WG Archive

[jcucchiara@mindspring.com]

At 11:46 PM 5/12/03 +0200, Wijnen, Bert (Bert) wrote:
>If you are going to make any more changes, then pls do
>consider this (which I think got lost between the cracks):

Hi Bert,

Yes, we'll be updating this one.  We have the nits on
the line length and can add the suggested text below also.

  -Thanks,
   Joan


>
>> > >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 
>