| Newsgroups |
gmane.ietf.rmt |
| Message-ID |
<[email protected]> |
In principle I don't have any objection. In practice, any CC has to be
for a purpose so I had thought that within the CC would be the right
place - likewise (although we don't have a mountain of CC proposals), it
didn't seem sensible to put specific CC block into FLUTE as future ones
can not be anticipated (we took out some of the specific FEC stuff
already).
If consensus is to do this in a PI, then shouldn't be in ALC and FLUTE
merely inherits? (Same amount of effort, but then the spec is correctly
available to any other ALC-PI based protocols).
(I'm not pedantic about any of this, though recent history hasn't shown
much frantic activity in the FLUTE camp to address another round of
security analysis and if a better place for a CC-binding is ALC that, at
least, wouldn't stretch the FLUTE update further).
Anyone else got a view?
Cheers, Rod.
>-----Original Message-----
>From: ext Magnus Westerlund [mailto:[email protected]]
>Sent: 06 December, 2006 16:47
>To: Walsh Rod (Nokia-NRC/Tampere)
>Cc: [email protected]
>Subject: Re: [Rmt] congestion control in FLUTE
>
>[email protected] skrev:
>> FLUTE's approach is inherited from ALC - i.e. this needs
>doing for ALC
>> and then FLUTE inherits the solution. I would have thought it
>> absolutely should not be further described in FLUTE (possibly not in
>> ALC either) according to the RMT building block approach. Is
>that about right?
>>
>
>Hi Rod,
>
>I don't agree. Flute is in my eyes an protocol instantiation
>and is thus the right place to describe these things.
>
>cheers
>
>Magnus Westerlund
>
>IETF Transport Area Director & TSVWG Chair
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVA/A
>----------------------------------------------------------------------
>Ericsson AB | Phone +46 8 4048287
>Torshamsgatan 23 | Fax +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: [email protected]
>----------------------------------------------------------------------
>