Subject: [clue] Questions on basic message flow in the framework

From: Roni Even <[email-masked]>
Date: Wed, 24 Aug 2011 16:30:09 +0300

Hi,

In the interim meeting I mentioned that I that I support the model but think
that there are parameters that I would like to add. At the meeting it was
clear to me that there will be a new revision soon that will support
parameters at the capture scene level. Trying to see which parameters I
would like to see supported I looked at the message flow and I have some
questions.

Andy presented the basic message flow with three messages:

1.       Consumer capability advertisement

2.       Provider - media capture advertisement

3.       Consumer configuration of provider streams.

I was looking at the use cases of 3 to 3 and 3 to 1 and tried to understand
what will be conveyed in the three messages and how will we use the
information. 

The first question I had was how this relates to SIP. At which stage of the
SIP call will the consumer advertize its capabilities?

In the second part, I was then looking at a  telepresence system that has 3
65" screens where the distance between the screens including the frames is
6". The system has three cameras, each mounted on the center of a screen.
The system is facing a room with three rows each row sits 6 people and each
camera is capable of capturing a third of the room but the default views of
each camera does not overlap with the others. The cameras support zoom and
pan (local from the application).

The system can decode up to four video streams where one is presentation
(H.239 like). The system can support an internal 4-way multipoint call,
means that it can receive the three main video streams from one, two or
three endpoints.

I think that this is a very standard system, nothing special.

The telepresence application is willing to provide all this information as
part of the consumer capability advertisement and according to Andy's slides
the message include physical factors , user preferences and software
limitations.

I am now trying to understand what the purpose of the consumer capability
advertisement is in order to see what information is important to convey.  

Is the reason for the consumer capability advertisement to allow the
provider to propose a better media capability advertisement, or is it to
allow the provider to optimize the content of the media streams he is
sending based on the information provided. This will help with looking at
which parameters can be used. The slides show that the information is used
for the capability advertisements.

The third question I had was if these three messages can be repeated at any
time or do we see a different message to request a mode change.

Thanks

Roni Even

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 24 Aug 2011 13:09:33 -0700

Hi Roni,

Please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Roni Even
> Sent: Wednesday, August 24, 2011 6:30 AM
> To: [email-masked]
> Subject: [clue] Questions on basic message flow in the framework
> 
> Hi,
> 
> In the interim meeting I mentioned that I that I support the model but
think that there are parameters
> that I would like to add. At the meeting it was clear to me that there
will be a new revision soon
> that will support parameters at the capture scene level. Trying to see
which parameters I would like
> to see supported I looked at the message flow and I have some
questions.
> I was looking at the use cases of 3 to 3 and 3 to 1 and tried to
understand what will be conveyed in
> the three messages and how will we use the information.
> 
> The first question I had was how this relates to SIP. At which stage
of the SIP call will the consumer
> advertize its capabilities?

I think it is best to focus on the framework a bit more before mapping
to SIP.  

> In the second part, I was then looking at a  telepresence system that
has 3 65" screens where the
> distance between the screens including the frames is 6". The system
has three cameras, each mounted on
> the center of a screen. The system is facing a room with three rows
each row sits 6 people and each
> camera is capable of capturing a third of the room but the default
views of each camera does not
> overlap with the others. The cameras support zoom and pan (local from
the application).
> 
> The system can decode up to four video streams where one is
presentation (H.239 like). The system can
> support an internal 4-way multipoint call, means that it can receive
the three main video streams from
> one, two or three endpoints.
> 
> The telepresence application is willing to provide all this
information as part of the consumer
> capability advertisement and according to Andy's slides the message
include physical factors , user
> preferences and software limitations.
> 
> I am now trying to understand what the purpose of the consumer
capability advertisement is in order to
> see what information is important to convey.
> 
provider to propose a better
> media capability advertisement, or is it to allow the provider to
optimize the content of the media
> streams he is sending based on the information provided. This will
help with looking at which
> parameters can be used. The slides show that the information is used
for the capability
> advertisements.

I viewed it as being primarily for the former, but using it for the
latter may make sense as well and should not be excluded. The extent to
which the provider actually uses the information is implementation
dependent.
 
> 
> 
> 
> The third question I had was if these three messages can be repeated
at any time or do we see a
> different message to request a mode change.
> 

My understanding, based on the presentation in the virtual meeting, is
that these messages, though shown as an ordered exchange, could
theoretically come in any order at any time.

Cheers,
Charles

---

From: Andy Pepperell <[email-masked]>
Date: Thu, 25 Aug 2011 17:46:36 +0100

Thanks Charles! To follow up:

 >>[Roni]
understand what will be conveyed in the three messages and how will we 
use the information.
 >> The first question I had was how this relates to SIP. At which stage 
of the SIP call will the consumer advertize its capabilities?
 >[Charles]
to SIP.

Yes, that's been our approach so far...

 >>[Roni]
at any time or do we see a different message to request a mode change.
 >[Charles]

While for the purposes of of producing robust implementations messages 
would need to be handled "in any order at any time", within the model as 
proposed there are some constraints - specifically, a media stream 
provider must not send a media capture advertisement until it's seen at 
least one consumer capability advertisement, and a consumer would not be 
able to send a stream configuration message until it's seen at least one 
media capture advertisement from the provider.

Andy

On 24/08/2011 21:09, Charles Eckel (eckelcu) wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 25 Aug 2011 09:58:07 -0700

Hi Andy,

One more question inline to make sure I have it straight.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andrew Pepperell (apeppere)
> Sent: Thursday, August 25, 2011 9:47 AM
> To: [email-masked]
> Subject: Re: [clue] Questions on basic message flow in the framework
> 

At call establishment, the message flow must be:

Consumer                     Provider
--------------------------------------
(1) Consumer capability advertisement -->
<-- (2) Provider media capture advertisement
(3) Consumer configuration of provider streams -->

But after that, an updated version of (1) or (2) or (3) could be
sent/rcvd at any time, and it is okay for the provider to send an
updated (2) without first receiving an updated (1), etc.
Is that correct?

Thanks,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Aug 2011 13:06:30 -0400

> media capture advertisement from the provider.

While I think a mechanism may end up imposing some limitations such as 
this, I see no reason to impose such restrictions a priori.

	Thanks,
	Paul

---

From: Andy Pepperell <[email-masked]>
Date: Thu, 25 Aug 2011 18:16:34 +0100

Hi Charles,

 >updated (2) without first receiving an updated (1), etc.

That's the scheme in the framework, yes. It may be that new information 
in a consumer capability advertisement (1) causes a new media capture 
advertisement (2) to need to be sent, or a different stimulus might 
cause a new (2) to be needed (e.g. connection / disconnection of a 
presentation source).

Regards,

Andy

---

From: Andy Pepperell <[email-masked]>
Date: Thu, 25 Aug 2011 18:22:15 +0100

Hi Paul,

I see this as more than a mere "restriction"; specifically, if a device 
is intending to use the consumer capability advertisement to determine 
its media capture advertisement (for instance, by acting on the list of 
attributes that are understood by the consumer) then it seems much 
better to require at least one of these to be sent rather than making it 
optional and forcing vendors to potentially introduce a timeout scheme 
where their devices wait around for a while to see if they do receive a 
message and, if not, give up after a certain time interval (which would 
no doubt be inconsistent between different manufacturers).

Regards,

Andy

---

From: Roni Even <[email-masked]>
Date: Thu, 25 Aug 2011 22:00:32 +0300

Hi,
During the initial discussion on this work one of the issues was if we are
talking about one or two stage signaling. As far as I remember we talked
about one stage signaling, is this still the case or do we still keep it
open. This was way I asked about the mapping to SIP and why I think we need
to consider it early to verify if the proposed message flow works with one
stage signaling.
Regards
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andy Pepperell
> Sent: Thursday, August 25, 2011 7:47 PM
> To: [email-masked]

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Thu, 25 Aug 2011 12:08:14 -0700

One option would be to establish CLUE through SIP, and then these
messages are CLUE messages, not SIP messages.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Roni Even
> Sent: Thursday, August 25, 2011 12:01 PM
> To: Andrew Pepperell (apeppere); [email-masked]
> Of
> >  >My understanding, based on the presentation in the virtual
meeting,
> > is
> > would need to be handled "in any order at any time", within the
model
> > as
> > least one consumer capability advertisement, and a consumer would
not
> > be
> > >> In the interim meeting I mentioned that I that I support the
model
> > but
> > >> that will support parameters at the capture scene level. Trying
to
> > see
> > > latter may make sense as well and should not be excluded. The
> extent
> > to
> > > My understanding, based on the presentation in the virtual
meeting,
> > is

---

From: Roni Even <[email-masked]>
Date: Thu, 25 Aug 2011 22:48:13 +0300

Hi,
This will mean two stage, the initial SIP exchange will require a valid SDP
for backward interoperability that will open one video, one video and CLUE
channels and only afterwards the full telepresence sessions will be added.
We can say that systems that support CLUE will wait for the exchange in the
CLUE channel to establish media which is a delay.
If we use multi body in the SIP message, we will still need to discuss how
to have the three message exchange in an offer answer dialog.

The way we chose will also affect my third question about using the messages
after the initial media channels are running. This is why I was asking about
maybe we need mode change messages.

Roni

> From: Allyn Romanow (allyn) [mailto:[email-masked]]
> Sent: Thursday, August 25, 2011 10:08 PM
> To: Roni Even; Andrew Pepperell (apeppere); [email-masked]
> Subject: RE: [clue] Questions on basic message flow in the framework
> 
> > During the initial discussion on this work one of the issues was if
> we
> > are
> > open. This was way I asked about the mapping to SIP and why I think
> we
> > need
> > to consider it early to verify if the proposed message flow works
> with
> > one
> > stage signaling.
> > Regards
> > Roni
> >
> > > provider must not send a media capture advertisement until it's
> seen
> > at
> > > able to send a stream configuration message until it's seen at
> least
> > > one

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2011 10:13:37 -0400

> maybe we need mode change messages.

There are many ways to accomplish this.

Is your concern the call setup delay while more messages are exchanged? 
Or is it other aspects of user experience, such as establishing one 
video stream before the others?

Delay due to extra message exchange can be hidden so that the user 
experience isn't diminished (much). E.g. the extra message(s) can be 
exchanged while "ringing" (on calling side) and before alerting 
commences (on called side).

For instance, there could be multiple O/A exchanges, with preconditions 
used to delay the alerting. There could then also be exchanges over a 
"clue" stream between the first o/a and the last one resolving the 
preconditions.

I don't think its necessary to decide on this mechanism yet.

	Thanks
	Paul

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 26 Aug 2011 11:43:13 -0400

On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat <[email-masked]>wrote:

> Is your concern the call setup delay while more messages are exchanged? Or
> is it other aspects of user experience, such as establishing one video
> stream before the others?
>
> exchanged while "ringing" (on calling side) and before alerting commences
> (on called side).
>
>
This needs to be looked at but may be acceptable at call setup, which always
seems to take a few seconds.

I am also worried about changes _during the call_, where a few seconds delay
could be bad.

Here is an example (I am going to try and capture the worries I expressed in
QC, and at the interim).

A session starts, with two endpoints separated by (say) 150 msec one way .
There is

Consumer capability advertisement |----------------------------->

Media Capture Advertisement       <-----------------------------|

Consumer config of provider       |----------------------------->
streams

That takes roughly 450 msec + a little, which seems OK.

1.) Won't in practice the provider send a SDP file to the consumer, which in
practice the consumer should receive and parse (if only as an error check),
so won't that add ANOTHER round trip ? So, won't that take 600 msec plus a
little, which is less OK ? And, won't that also mean that,
if there is a 1% packet loss, there will be a (1 - (0.99)^4 =)  4% chance of
a problem with these handshakes ? And won't a drop on any of these 4
messages mean a considerably longer setup delay ?

And, then

2.) Suppose, at some point in the session, there is a network blip and
inbound becomes congested. The provider needs to throttle back. The consumer
detects this, says "I need to advertise less bandwidth," sends a
corresponding CCA via UDP. The provider receives this, and sends a new MCA.

This gets lost in the congestion. Even if three in a row are sent, they
might all be lost, as the link is congested.

So, then there is a timer set. Tick, tick, tick. The consumer will send more
CCAs (presumably) once the timer times out, but nothing comes back. The
consumer can talk to the provider, but it doesn't know it, and it isn't
allowed to except through
this three way, so the situation never gets resolved. Meanwhile, up at Layer
8, the company CEO is getting pissed off. (And, in some parallel universe,
IESG ADs are asking questions about congestion control.) Even a 1 second
timer would mean that the time to recover from _one_ control packet loss
could be 1.5 seconds, which is not good.

This says to me that either

- providers SHOULD include information about adapting to congestion in the
first handshake, so that the consumer can send an appropriate
config message as needed

or

- consumers  should be able to send a "squelch" message to the provider,
saying "reduce bandwidth to me now," and let the provider puzzle it out.
This could take the form of (say) a not to exceed bandwidth in the config
message; a subsequent config could be the same except for a lowered  NTE
bandwidth. Obviously, in a really severe problem, you might want to set that
to zero.

or both.

All of this seems fairly fundamental to me, the sort of thing that needs to
be addressed if we are going to use this 3-way handshake.

Regards
Marshall

> used to delay the alerting. There could then also be exchanges over a "clue"
> stream between the first o/a and the last one resolving the preconditions.
>
>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>
>>>> Behalf
>>>
>>>> Of
>>>>
>>>>> Andy Pepperell
>>>>> Subject: Re: [clue] Questions on basic message flow in the
>>>>>
>>>> framework
>>>
>>>>
>>>>>  >>  I was looking at the use cases of 3 to 3 and 3 to 1 and tried
>>>>>
>>>> to
>>>
>>>> understand what will be conveyed in the three messages and how will
>>>>>
>>>> we
>>>>
>>>>> use the information.
>>>>> at any time or do we see a different message to request a mode
>>>>>
>>>> change.
>>>>
>>>>>  >[Charles]
>>>>> While for the purposes of of producing robust implementations
>>>>>
>>>> messages
>>>>
>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>
>>>>>> Behalf
>>>>
>>>>> Of Roni Even
>>>>>>
>>>>>>> that I would like to add. At the meeting it was clear to me that
>>>>>>>
>>>>>> there
>>>>>
>>>>>>> The first question I had was how this relates to SIP. At which
>>>>>>>
>>>>>> stage
>>>>
>>>>>> I think it is best to focus on the framework a bit more before
>>>>>>
>>>>> mapping
>>>>>
>>>>>> to SIP.
>>>>>>
>>>>>>  In the second part, I was then looking at a  telepresence system
>>>>>>>
>>>>>> that
>>>>>
>>>>>>> distance between the screens including the frames is 6". The
>>>>>>>
>>>>>> system
>>>>
>>>>>>> the center of a screen. The system is facing a room with three
>>>>>>>
>>>>>> rows
>>>>
>>>>>>> camera is capable of capturing a third of the room but the
>>>>>>>
>>>>>> default
>>>
>>>>>>> overlap with the others. The cameras support zoom and pan (local
>>>>>>>
>>>>>> from
>>>>>
>>>>>> the application).
>>>>>>
>>>>>>> support an internal 4-way multipoint call, means that it can
>>>>>>>
>>>>>> receive
>>>>
>>>>>>> capability advertisement and according to Andy's slides the
>>>>>>>
>>>>>> message
>>>>
>>>>>>> Is the reason for the consumer capability advertisement to allow
>>>>>>>
>>>>>> the
>>>>
>>>>>>> media capability advertisement, or is it to allow the provider
>>>>>>>
>>>>>> to
>>>
>>>>>>> streams he is sending based on the information provided. This
>>>>>>>
>>>>>> will
>>>
>>>>>>> parameters can be used. The slides show that the information is
>>>>>>>
>>>>>> used
>>>>
>>>>> for the capability
>>>>>>
>>>>>>> advertisements.
>>>>>>>
>>>>>> I viewed it as being primarily for the former, but using it for
>>>>>>
>>>>> the
>>>
>>>>>> which the provider actually uses the information is
>>>>>>
>>>>> implementation
>>>
>>>> dependent.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> The third question I had was if these three messages can be
>>>>>>>
>>>>>> repeated
>>>>
>>>>>>>  ______________________________**_________________
>>>>>> clue mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>>
>>>>>
>>>>> ______________________________**_________________
>>>>> clue mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>>
>>>>
>>>> ______________________________**_________________
>>>> clue mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>>>
>>>
>> ______________________________**_________________
>> clue mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>>
>>
> ______________________________**_________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/clue<https://www.ietf.org/mailman/listinfo/clue>
>

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Aug 2011 19:37:16 +0300

Hi,

It is not a three message flow but four as far as I understand in order to
achieve a two way communication.

The caller will send his Consumer capability advertisement (as a consumer)
and an SDP for non CLUE interoperability.

The called party will send Consumer capability advertisement and his Media
Capture Advertisement

The calling party will send Media Capture Advertisement  and can send
Consumer config of provider  streams ( what it wants to receive)

The called party will send Consumer config of provider  streams.

I think we need all these messages but should be aware of what it means.

In the past we thought about having initial communication with partial
streams. And get all streams after the full exchange. Maybe we can have it
as an option that can be part of the offer/answer.

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marshall Eubanks
Sent: Friday, August 26, 2011 6:43 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [clue] Questions on basic message flow in the framework

On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat <[email-masked]>
wrote:

Hi,

streams 

And, then 

config message as needed

or 

or both. 

Regards

Marshall

For instance, there could be multiple O/A exchanges, with preconditions used
to delay the alerting. There could then also be exchanges over a "clue"
stream between the first o/a and the last one resolving the preconditions.

       Thanks
       Paul

Roni

-----Original Message-----

Of

Roni Even

Hi,

we

are
talking about one or two stage signaling. As far as I remember we
talked
about one stage signaling, is this still the case or do we still keep
it
open. This was way I asked about the mapping to SIP and why I think

we

need

with

one
stage signaling.
Regards
Roni

-----Original Message-----

Behalf

Of

Andy Pepperell

framework

to

we

use the information.
stage
mapping
to SIP.

repeated

change.

meeting,

is

messages

model

as

seen

at

not

be

least

one

Andy

Hi Roni,

Please see inline.

-----Original Message-----

Behalf

Of Roni Even

Hi,

model

but

there

to

see

questions.

stage

mapping

to SIP.

that

system

rows

default

from

the application).

receive

message

the

to

will

used

for the capability

advertisements.

the

extent

to

implementation

dependent.

repeated

meeting,

is

Cheers,
Charles

Thanks

Roni Even

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Aug 2011 13:25:59 -0400

On 8/26/11 11:43 AM, Marshall Eubanks wrote:
>
>
> On Fri, Aug 26, 2011 at 10:13 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Is your concern the call setup delay while more messages are
>     exchanged? Or is it other aspects of user experience, such as
>     establishing one video stream before the others?
>
> This needs to be looked at but may be acceptable at call setup, which
> always seems to take a few seconds.
>
> I am also worried about changes _during the call_, where a few seconds
> delay could be bad.
>
> Here is an example (I am going to try and capture the worries I
> expressed in QC, and at the interim).
>
> A session starts, with two endpoints separated by (say) 150 msec one way
> . There is
>
> 1.) Won't in practice the provider send a SDP file to the consumer,
> which in practice the consumer should receive and parse (if only as an
> error check), so won't that add ANOTHER round trip ? So, won't that take
> 600 msec plus a little, which is less OK ? And, won't that also mean that,
> if there is a 1% packet loss, there will be a (1 - (0.99)^4 =)  4%
> chance of a problem with these handshakes ? And won't a drop on any of
> these 4 messages mean a considerably longer setup delay ?

I think it is still unclear if the above messages precede the O/A, are 
carried in some of the same messages as the O/A, or are actually 
embedded in the O/A SDP. So its as yet unclear whether there would be 3, 
4, 5, or more messages.

The impact of message drop will also depend on the specific mechanisms, 
but certainly there will be *some* impact.

(But note that we may well be doing ICE as well, which can require many 
more messages.)

> inbound becomes congested. The provider needs to throttle back. The
> consumer detects this, says "I need to advertise less bandwidth,"
> sends a corresponding CCA via UDP. The provider receives this, and sends
> a new MCA.

Do you think CLUE-specific signaling is the proper way to deal with 
that? Its not a problem that is unique to CLUE. Perhaps it would be 
better to use adaptive rate codecs for this. They could presumably 
respond more quickly.

	Thanks,
	Paul

> So, then there is a timer set. Tick, tick, tick. The consumer will send
> more CCAs (presumably) once the timer times out, but nothing comes back.
> The consumer can talk to the provider, but it doesn't know it, and it
> isn't allowed to except through
> this three way, so the situation never gets resolved. Meanwhile, up at
> Layer 8, the company CEO is getting pissed off. (And, in some parallel
> universe, IESG ADs are asking questions about congestion control.) Even
> a 1 second timer would mean that the time to recover from _one_ control
> packet loss could be 1.5 seconds, which is not good.
>
> - providers SHOULD include information about adapting to congestion in
> the first handshake, so that the consumer can send an appropriate
> config message as needed
>
> or
>
> This could take the form of (say) a not to exceed bandwidth in the
> config message; a subsequent config could be the same except for a
> lowered  NTE bandwidth. Obviously, in a really severe problem, you might
> want to set that to zero.
>
> or both.
>
> All of this seems fairly fundamental to me, the sort of thing that needs
> to be addressed if we are going to use this 3-way handshake.
>
> Regards
> Marshall
>
>     For instance, there could be multiple O/A exchanges, with
>     preconditions used to delay the alerting. There could then also be
>     exchanges over a "clue" stream between the first o/a and the last
>     one resolving the preconditions.
>
>             From: Allyn Romanow (allyn) [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             <mailto:[email-masked]>
>                 From: [email-masked]
>                 <mailto:[email-masked]>
>                 [mailto:[email-masked]
>                 <mailto:[email-masked]>] On Behalf
>
>             Of
>
>                 Roni Even
>                 <mailto:[email-masked]>
>                     From: [email-masked]
>                     <mailto:[email-masked]>
>                     [mailto:[email-masked]
>                     <mailto:[email-masked]>] On
>
>             Behalf
>
>                 Of
>
>                     Andy Pepperell
>                     To: [email-masked] <mailto:[email-masked]>
>                             From: [email-masked]
>                             <mailto:[email-masked]>
>                             [mailto:[email-masked]
>                             <mailto:[email-masked]>] On
>
>                 Behalf
>
>                         Of Roni Even
>
>                             To: [email-masked] <mailto:[email-masked]>
>                         _________________________________________________
>                         clue mailing list
>                         [email-masked] <mailto:[email-masked]>
>                         https://www.ietf.org/mailman/__listinfo/clue
>                         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>                     _________________________________________________
>                     clue mailing list
>                     [email-masked] <mailto:[email-masked]>
>                     https://www.ietf.org/mailman/__listinfo/clue
>                     <https://www.ietf.org/mailman/listinfo/clue>
>
>
>                 _________________________________________________
>                 clue mailing list
>                 [email-masked] <mailto:[email-masked]>
>                 https://www.ietf.org/mailman/__listinfo/clue
>                 <https://www.ietf.org/mailman/listinfo/clue>
>
>
>         _________________________________________________
>         clue mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/clue
>         <https://www.ietf.org/mailman/listinfo/clue>
>
>
>     _________________________________________________
>     clue mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/clue
>     <https://www.ietf.org/mailman/listinfo/clue>
>
>