Subject: opaque object ---an extra object field

From: "Hong Liao" <[email-masked]>
Date: Wed, 6 Jun 2001 18:25:15 -0400

>This rule should be followed for all unsupported object classes, even if
>there is an IANA assignment for that class number

>-- David

I agree with it.   I have question:  The opaque object can be either the
existing object of RSVP message with unknown class/c-type, or an extra
object in any RSVP message content as an unrecognized object(rfc 2205,
section 3.10).  Am I right? If it is right, I suggest to put this opaque
object inside the Path/Resv message field in the rsvp-te draft.

Thanks,

Julia

LDP Hello wrote:
>
> I agree with Adrian.
>
> http://www.iana.org/assignments/rsvp-parameters
> explains all the unassigned Classes for RSVP.
>
> Any Object with unassigned or unknown Class number
> must be considered Opaque Object and must be treated
> according to RFC2205's section 3.10. ie must be
> rejected if the class is 0bbbbbbb, ignore silently if
> class is 10bbbbbb and ignore but forward if 11bbbbbb.

---

From: David Charlap <[email-masked]>
Date: Wed, 06 Jun 2001 18:55:16 -0400

Hong Liao wrote:
> 
> I have question:  The opaque object can be either the existing
> object of RSVP message with unknown class/c-type, or an extra
> object in any RSVP message content as an unrecognized object(rfc
> 2205, section 3.10).  Am I right? If it is right, I suggest to put
> this opaque object inside the Path/Resv message field in the
> rsvp-te draft.

If it an unknown C-Type of a known class, you have no choice but to
reject the entire message with a PathErr/ResvErr.

If it is an unknown class, then you follow section 3.10.

There is no difference between "unknown class" and "extra object".

If you're asking about where in the sequence of objects you should put
unknown objects, I don't think it should matter.  There are very few
rules regarding object ordering.  The only hard ones that I can think of
are:

- INTEGRITY, if used, must come immediately after the common header,
  and before everything else.
- Each flow descriptor that has FLOWSPEC must begin with that
  FLOWSPEC.
- Each flow descriptor that does not have a FLOWSPEC must begin with
  the FILTERSPEC.
- The list of flow descriptors must follow the STYLE object.

Within these rules, I think you're pretty must free to put unknown
objects wherever you like.  Personally, I think the best place to put
unknown objects when forwarding them is:

- In Path messages, immediately before the sender descriptor
- In Resv messages, immediately before the STYLE object

But I don't think there is any rule, as long as the resulting message
doesn't violate any existing object-ordering rules.

-- David