Subject: Object ordering in RSVP Messages

From: "manoj juneja" <[email-masked]>
Date: Thu, 27 Sep 2001 15:53:17 -0700

Hi All,
        I have a doubt regarding the object ordering of message_id and
message_id_ack and message_id_nack in RFC 2961. I can understand the
reason behind the object ordering of message_id and integrity object.
What is the reason for defining the ordering for message_id_ack/nack
object. Should a protocol layer ignore the complete message if this
order is not followed ?
I mean to say even if message_id / message_id_ack/nack is not present
at their designated position in RSVP message, should the complete
message be ignored ?

Thanks in Advance,
manoj.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

From: "Feng, Mark" <[email-masked]>
Date: Thu, 27 Sep 2001 16:30:22 -0700

I am not sure why the order of those objects are important; but if the
standard says it is mandatory to have this order, then I would say that drop
the message if the order is not right.

- Mark

> -----Original Message-----
> From: manoj juneja [mailto:[email-masked]]
> Sent: Thursday, September 27, 2001 3:53 PM
> To: [email-masked]
> Subject: Object ordering in RSVP Messages
> 
> 
> Hi All,

---

From: Bob Braden <[email-masked]>
Date: Fri, 28 Sep 2001 22:35:53 GMT

*> From [email-masked]  Fri Sep 28 14:34:00 2001
  *> From: "Feng, Mark" <[email-masked]>
  *> To: "'manoj juneja'" <[email-masked]>, [email-masked]
  *> Subject: RE: Object ordering in RSVP Messages
  *> Date: Thu, 27 Sep 2001 16:30:22 -0700
  *> MIME-Version: 1.0
  *> 
  *> I am not sure why the order of those objects are important; but if the
  *> standard says it is mandatory to have this order, then I would say that drop
  *> the message if the order is not right.
  *> 
  *> - Mark
  *> 

I would suggest that you follow the Jon Postel Robustness Principle
(see section 1.2.2 of RFC 1122, for example, if you don't already
have it imprinted on your T shirt or your brain.  Then imprint
it on your T-shirt and your brain.)

Bob Braden

  *> > -----Original Message-----
  *> > From: manoj juneja [mailto:[email-masked]]
  *> > Sent: Thursday, September 27, 2001 3:53 PM
  *> > To: [email-masked]
  *> > Subject: Object ordering in RSVP Messages
  *> > 
  *> > 
  *> > Hi All,
  *> >         I have a doubt regarding the object ordering of message_id and
  *> > message_id_ack and message_id_nack in RFC 2961. I can understand the
  *> > reason behind the object ordering of message_id and integrity object.
  *> > What is the reason for defining the ordering for message_id_ack/nack
  *> > object. Should a protocol layer ignore the complete message if this
  *> > order is not followed ?
  *> > I mean to say even if message_id / message_id_ack/nack is not present
  *> > at their designated position in RSVP message, should the complete
  *> > message be ignored ?
  *> > 
  *> > Thanks in Advance,
  *> > manoj.
  *> > 
  *> > _________________________________________________________________
  *> > Get your FREE download of MSN Explorer at 
  *> > http://explorer.msn.com/intl.asp
  *> > 
  *>

---

From: "Feng, Mark" <[email-masked]>
Date: Fri, 28 Sep 2001 16:35:56 -0700

I tend to disagree with this kind of "robustness".

Here is what I think the reason of putting the objects in such order. The
receiver of the message can simply call some functional module to handle the
Mesasge_Id_Ack, Message_Id_Nack objects, which might be linked to different
PSB/RSBs. Then these objects can be stripped off. The rest of the message
can be then processed as a normal message, without worrying finding more
Message_Id_Ack/Message_Id_Nack objects.

As to the "robustness", IMO, a standard is written so that different
implementations can be done independently, and still inter-work. There are
things, such as what've been discussed, that are defined so that the
implementation can be more efficient. If there are certain things that are
defined clearly by the standard, then they should be done as such.
Otherwise, why having them specified in the first place? I am not quite sure
how difficult it is to get the ordering of the message right, as specified
by the standard. Do we really want to build some implementation to handle
all such standard non-comformance, and end up with a potentially
unyieldingly complicated system?

- Mark

> From: Bob Braden [mailto:[email-masked]]
> Sent: Friday, September 28, 2001 3:36 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Object ordering in RSVP Messages
> 
> 
>

---

From: Bob Braden <[email-masked]>
Date: Fri, 28 Sep 2001 23:45:36 GMT

*> From [email-masked]  Fri Sep 28 16:34:57 2001
  *> From: "Feng, Mark" <[email-masked]>
  *> To: "'Bob Braden'" <[email-masked]>, [email-masked],
  *>    [email-masked]
  *> Subject: RE: Object ordering in RSVP Messages
  *> Date: Fri, 28 Sep 2001 16:35:56 -0700
  *> MIME-Version: 1.0
  *> 
  *> I tend to disagree with this kind of "robustness".
  *> 
  *> Here is what I think the reason of putting the objects in such order. The
  *> receiver of the message can simply call some functional module to handle the
  *> Mesasge_Id_Ack, Message_Id_Nack objects, which might be linked to different
  *> PSB/RSBs. Then these objects can be stripped off. The rest of the message
  *> can be then processed as a normal message, without worrying finding more
  *> Message_Id_Ack/Message_Id_Nack objects.

Frankly, your argument sounds completely bogus to me.  If you "strip off"
some objects, you are wasting unnecessary time.  There is no obvious (to me)
reason why the order of processing Ack/Nack objects should matter.

  *> 
  *> As to the "robustness", IMO, a standard is written so that different
  *> implementations can be done independently, and still inter-work. There are

No argument there, and that is exactly the point.

  *> things, such as what've been discussed, that are defined so that the
  *> implementation can be more efficient. If there are certain things that are

It is not hard to make an implementation that can take advantage of
efficiency when it is available but still does the right thing when it
is not.  We have been successfully applying Postel's Principle for the
past 25 years.

There is a deeper issue about whether you believe that a standard should
define every last detail and every implementation must perfectly conform,
or whether you want to define the minimum required for interoperability
and leave the rest to the imagination and creativity of the implementors.
The Internet Way is the latter.  Some from other industries feel
profoundly uncomfortable with this approach.

We got where we are by the Internet Way, not the Other Way.  Down the
Other Way lay X.25, for example.

Bob Braden

Bob Braden

  *> defined clearly by the standard, then they should be done as such.
  *> Otherwise, why having them specified in the first place? I am not quite sure
  *> how difficult it is to get the ordering of the message right, as specified
  *> by the standard. Do we really want to build some implementation to handle
  *> all such standard non-comformance, and end up with a potentially
  *> unyieldingly complicated system?
  *> 
  *> - Mark
  *> 
  *> > -----Original Message-----
  *> > From: Bob Braden [mailto:[email-masked]]
  *> > Sent: Friday, September 28, 2001 3:36 PM
  *> > To: [email-masked]; [email-masked]; [email-masked]
  *> > Subject: RE: Object ordering in RSVP Messages
  *> > 
  *> > 
  *> > 
  *> >   *> From [email-masked]  Fri Sep 28 14:34:00 2001
  *> >   *> From: "Feng, Mark" <[email-masked]>
  *> >   *> To: "'manoj juneja'" <[email-masked]>, [email-masked]
  *> >   *> Subject: RE: Object ordering in RSVP Messages
  *> >   *> Date: Thu, 27 Sep 2001 16:30:22 -0700
  *> >   *> MIME-Version: 1.0
  *> >   *> 
  *> >   *> I am not sure why the order of those objects are 
  *> > important; but if the
  *> >   *> standard says it is mandatory to have this order, then I 
  *> > would say that drop
  *> >   *> the message if the order is not right.
  *> >   *> 
  *> >   *> - Mark
  *> >   *> 
  *> > 
  *> > I would suggest that you follow the Jon Postel Robustness Principle
  *> > (see section 1.2.2 of RFC 1122, for example, if you don't already
  *> > have it imprinted on your T shirt or your brain.  Then imprint
  *> > it on your T-shirt and your brain.)
  *> > 
  *> > Bob Braden
  *> > 
  *> >   *> > -----Original Message-----
  *> >   *> > From: manoj juneja [mailto:[email-masked]]
  *> >   *> > Sent: Thursday, September 27, 2001 3:53 PM
  *> >   *> > To: [email-masked]
  *> >   *> > Subject: Object ordering in RSVP Messages
  *> >   *> > 
  *> >   *> > 
  *> >   *> > Hi All,
  *> >   *> >         I have a doubt regarding the object ordering 
  *> > of message_id and
  *> >   *> > message_id_ack and message_id_nack in RFC 2961. I can 
  *> > understand the
  *> >   *> > reason behind the object ordering of message_id and 
  *> > integrity object.
  *> >   *> > What is the reason for defining the ordering for 
  *> > message_id_ack/nack
  *> >   *> > object. Should a protocol layer ignore the complete 
  *> > message if this
  *> >   *> > order is not followed ?
  *> >   *> > I mean to say even if message_id / message_id_ack/nack 
  *> > is not present
  *> >   *> > at their designated position in RSVP message, should 
  *> > the complete
  *> >   *> > message be ignored ?
  *> >   *> > 
  *> >   *> > Thanks in Advance,
  *> >   *> > manoj.
  *> >   *> > 
  *> >   *> > 
  *> > _________________________________________________________________
  *> >   *> > Get your FREE download of MSN Explorer at 
  *> >   *> > http://explorer.msn.com/intl.asp
  *> >   *> > 
  *> >   *> 
  *> > 
  *>

---

From: "Feng, Mark" <[email-masked]>
Date: Fri, 28 Sep 2001 17:25:51 -0700

> Sent: Friday, September 28, 2001 4:46 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]

My apology for the bad wording. I am not saying to remove the objects
physically. Instead, after the Ack/Nack objects are processed, no further
action needs to be taken against them. Then the message can be processed as
a regular message.

Imagine the Ack/Nack is scattered all over the place in, let's say, a Path
message. The module/function that is responsible to handle the Path message
would have to constantly  look out for any potential Ack/Nack objects, which
are not even related to that particular PSB, and involves different kind of
processing.

> Other Way lay X.25, for example.

I totally agree the standard should not define every last detail. That's why
there are words like "must", "should", "may", etc.. In case of how to handle
cases where the "must" are violated, I think that's where the disagreement
is, specifically regarding the order of the Ack/Nack objects.

But like you mentioned, if you can find a way to handle it logically and
efficiently, by all means, go for it. I've had no argument there.

- Mark

>   *> >   *> To: "'manoj juneja'" 
> <[email-masked]>, [email-masked]