Subject: Re: Comments on darft-berger-rsvp-refresh-reduct-04-pre.txt

From: [email-masked]
Date: Sun, 17 Oct 1999 11:41:12 -0700

*> format or other minor variations to be indicated.  It would be more
  *> consistent with RSVP to have three new object types:
  *> 
  *> 	MESSAGE_ID
  *> 	MESSAGE_ID_ACK
  *> 	MESSAGE_ID_LIST
  *> 
  *> with 1, 1, and 3 CTypes respectively.

Should be 1, 2, and 3 CTypes; there is the MESSAGE_ID_ACK NACK ctype.

  *> 
  *> I will send a more detailed list of comments separately.
  *> 
  *> Bob
  *>

---

From: Der-Hwa Gan <[email-masked]>
Date: Tue, 19 Oct 1999 19:43:09 -0700

Apologize for being late. 

> >  *>       Msg type: 8 bits
> >  *> 
> >  *>          12 = Bundle
> > XXX          ??
> >
> >  *> 
> >  *>       RSVP checksum: 16 bits
> >  *> 
> >  *>          The one's complement of the one's complement sum of the entire
> >  *>          message, with the checksum field replaced by zero for the pur-
> >  *>          pose of computing the checksum.  An all-zero value means that
> >  *>          no checksum was transmitted.  Because individual sub-messages
> >  *>          carry their own checksum as well as the INTEGRITY object for
> >             /
> >XXX       may                          or an INTEGRITY object
> >
> >  *>          authentication, this field MAY be set to zero.
> >
> >It might be more efficient (and maybe even simpler to code ;-)) to have
> >an outer checksum or integrity object, and omit checksum and integrity
> >object from inner messages.  See comment later.
> 
> Der-Hwa owns this one.  Der Hwa?

If the outer checksum is computed, it is ok to omit
individual checksum for sub-messages. 

The INTEGRITY object is different thing. Each sub-message must
carry its own INTEGRITY, until (a new?) Bundle message is capable of
carrying it. Adding a new bundle message type just for this purpose, I think,
actually complicates implementations. The performance gain is marginal.
I would recommend against it.

Regards,
Der-Hwa