RE: [rohc] Empty CSRC list issue in IR packet.

Hi Ghyslain,

Your understanding is correct.

As for removing section 4.3.3, I think it would be usefull to leave the
portion that proposes a behavior when the CC field in the dynamic part of
the RTP context and the CC field in the CSRC list do not match.

Thanks,
Remi.

-----Original Message-----
From: Ghyslain Pelletier [mailto:Ghyslain.Pelletier@ericsson.com]
Sent: Wednesday, August 27, 2003 10:06 AM
To: Remi Pelland
Cc: 'rohc@ietf.org'
Subject: Re: [rohc] Empty CSRC list issue in IR packet.

Hi all,

Does the following summarizes accurately the consensus that Remi is
looking after?

1) Section 4.3.1 and 4.3.2 of the implementer's guide clarifies
   rfc3095, and they should remain as they are.

   The text is clear, bring a clarification inline with the
   standard, and this has been interop tested. These two sections
   therefore do not need to be modified. In summary, when an empty
   CSRC list is present, an empty generic list (1-2 octets) must be
   inserted.

   Tommy's mail would then represent the consensus on this:

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01654.html

2) Section 4.3.3 of the implementer's guide should be removed.

   Section 4.3.3 of the implementer's guide is a "deviation" from the
   standard that proposes an improvement that would remove the need to
   send an empty generic list (1-2 octets) in the presence of an empty
   CSRC list. It is a deviation in the sense that the generic CSRC list
   in rfc3095 is of variable lenght but is not optional (must be
   present), while the text in 4.3.3 is keeping it of variable length
   but makes it optional.

   Section 4.3.3 should thus be removed from the implementer's guide,
   but could later be considered as a proposed improvement when
   bringing rfc3095 to draft standard if the profile gets updated at
   the same time.

   Abigail's mail would then represent the consensus on this:

http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01655.html

Is my understanding of the conclusions/consensus correct?
If so, then we will update the Implementer's guide accordingly.

/Ghyslain

-- 
Ghyslain Pelletier, Dipl. Ing.
Wireless IP Optimizations
AWARE - Advanced Wireless Algorithm Research
Ericsson Research, Corporate Unit

Ericsson AB, Laboratoriegränd 11
Box 920, S-97128 Luleå, SWEDEN
Phone : +46 (0) 920 20 24 32 
Mobile: +46 (0) 706 09 27 73
Ghyslain.Pelletier@ericsson.com
http://www.ericsson.com

I have a new mail address: Ghyslain.Pelletier@ericsson.com
My old e-mail address will function until 2004-06-01.
Please change my address in your personal address book.

Remi Pelland wrote:
> 
> Hi,
> 
> A couple of weeks ago, there was a discussion about a section in the
latest
> implementer's guide that corrects RFC 3095 with regards to the handling of
> empty CSRC lists: section 5.7.7.6 of the RFC says that an empty generic
list
> is inserted, while section 4.3.3. of the implementer's guide modifies the
> RFC by saying that no generic list should be present.
> 
> There seemed to be a concensus among those involved in the discussion to
> follow the RFC since this is how interoperability was tested.  That's fine
> and I do not want to restart the discussion on this.
> 
> Now, it has been a couple of weeks and there hasn't been any final
> conclusion on this issue (i.e. officially stating that the RFC method
should
> be used, anouncing the associated correction to the implementer's guide,
> etc...).
> 
> Based on the concensus that existed, I don't think there's a problem for
> those who currently receive mailing list messages.  However, it seems to
me
> like there's a risk that future implementations may use either methods,
> leading to interoperability problems.
> 
> Thanks,
> Remi.
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc