Re: [Rmt] About Flute-revised open points

<Rod.Walsh@nokia.com> Sat, 09 April 2011 11:28 UTC

Return-Path: <Rod.Walsh@nokia.com>
X-Original-To: rmt@core3.amsl.com
Delivered-To: rmt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58DCB28C0E8 for <rmt@core3.amsl.com>; Sat, 9 Apr 2011 04:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level:
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iHFgQ659cUR for <rmt@core3.amsl.com>; Sat, 9 Apr 2011 04:28:30 -0700 (PDT)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by core3.amsl.com (Postfix) with ESMTP id DBF5228C0DE for <rmt@ietf.org>; Sat, 9 Apr 2011 04:28:29 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p39BUCne030957; Sat, 9 Apr 2011 14:30:12 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Apr 2011 14:30:12 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Sat, 9 Apr 2011 13:29:59 +0200
From: <Rod.Walsh@nokia.com>
To: <brian.adamson@nrl.navy.mil>, <magnus.westerlund@ericsson.com>
Date: Sat, 9 Apr 2011 13:29:45 +0200
Thread-Topic: [Rmt] About Flute-revised open points
Thread-Index: Acv2qXVsJF/69JTzS0O60yc5Eki+fg==
Message-ID: <1302348585.4017.17.camel@Nokia-N900>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_1302348585401717camelNokiaN900_"
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Apr 2011 11:30:12.0194 (UTC) FILETIME=[7D479420:01CBF6A9]
X-Nokia-AV: Clean
Cc: rmt@ietf.org
Subject: Re: [Rmt] About Flute-revised open points
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Rod.Walsh@nokia.com
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Apr 2011 11:28:32 -0000

Error in previous message: long to byte change in xml is fine. (Other other way round could have been fatal). Cheers, Rod.

----- Original message -----
> Thanks for Dave's link, I'll check this out next week.
>
> Meanwhile...
>
> It seems like I am being painted a little like the outlier with last
> minute jitters. As Vincent kindly pointed out there are a few unresolved
> threads that have been running a long while. Mostly we simply haven't
> bothered to get them resolved. For each of those years. (And I must also
> personally appologise for not tracking LCT and ALC at each revision so
> as catch the greater than agreed impact on FLUTE before they went
> standards track. Of course we may well have had the same end result,
> just without the percenption of last minute issues). In spite of
> originally agreeing to maintain compatability where feasible, we're now
> stuck with some long term undiscolsed design decisions. Practically, we
> may have to embrace the unknown, but it's reasonable engineering to
> point out that our process has these black spots, whether communicated
> as last minute jitters or otherwise :)
>
> So as Magnus earlier suggested, I feel we need to be pragmatic with what
> we have. At the same time I feel we need a bit of design explanation
> where it exists as the rmt mailing list has been a close approximation
> to silent on these issues for most for this bis/revised era. (E.g. I
> hope I've overlooked the discussion or notification of non-backwards
> comatible changes prior to an updated ID appearing for LCT and ALC, and
> would be grateful to hear that this is so).
>
> Meanwhile, to Vincent's couple of points:
>
> 1. Yes, in RMT terms that's a recent email with responses awaiting
> conclusion, discussion or anything. The crux is what consitutes a
> compatibility breaking change (e.g. Graceful and non-harmful failure of
> an experimental implementation does not IMHO). And what is the list of
> these such changes? (Which I will turn to Dave's link for)
>
> 2. Yes, a disclosed design change. Again the critical thing is the
> comatibility (and the design logic). As far as I can tell there's just
> one fatal change (long to byte - for which I have not found any
> explanation). Otherwise and failures are graceful and happily compatible
> as said in the messages that were kindly linked by Vincent. I haven't
> had the opportunity to follow up the namespace specifics, but as Magnus
> originally pointed out, leaving 'example.com' was a goof - and thus
> obviously experimental FLUTE recievers are experienced at ignoring that
> part of the XML.
>
> For my part, I'll have a look at Dave's material in the near future and
> work with Jani to enhance the security provisions of FLUTE-SDP. Please
> point out if any of the other loose threads are pending a response from
> me.
>
> Cheers, Rod.
>
>
>
> ----- Original message -----
> > I agree with Magnus here.          I hope that Rod can review Vincent's
> > historical summary of the issues and provide consensus or comments to
> > help us resolve this.
> >
> >
> > Additionally, here is a link to the message that summarizes the
> > backwards incompatibility issues identified by Dave Harrington's AD
> > review of FLUTE:
> >
> >
> > http://www.ietf.org/mail-archive/web/rmt/current/msg01434.html
> >
> >
> >
> >
> >
> >
> >
> > best regards,
> >
> >
> >
> > Brian Adamson
> > brian.adamson@nrl.navy.mil<mailto:brian.adamson@nrl.navy.mil>
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mar 31, 2011, at 11:01 AM, Magnus Westerlund wrote:
> >
> > > Hi,
> > >
> > > I think this is a good example of what I expect in this discussion.
> I
> > > think that a number of the changes has good reasons to their
> changes
> > > and
> > > that we are not likely to reverse the WG documents text. For the
> > > record
> > > I don't really remember the reasons for the designs in this schema
> and
> > > what the underlying 3GPP reasons are.
> > >
> > > I have no rapid need for an updated flute so I am willing to let
> this
> > > discussion go on for a while. Especially letting people try to dig
> up
> > > any more motivations. But the fact is that the WG spent 5+ years in
> > > producing this document. There are reasons why it looks like it
> does.
> > > Reversing that decision at the last minute seems dangerous and
> likely
> > > to
> > > cause more issues than actually bumping the version number.
> > >
> > > Cheers
> > >
> > > Magnus
> > >
> >
> >
> > Everybody,
> >
> > A follow-up to our long discussion during the meeting:
> >
> > 1- Concerning Flute version, the email that convinced
> > me of the necessity to move to version 2 is the
> > following one, from Mike, sent on Feb 7, 2011:
> >
> > http://www.ietf.org/mail-archive/web/rmt/current/msg01511.html
> >
> > 2- Concerning XML extensibility, after searching a little
> > bit better in my archives, I finally found the initial reasons.
> > See the following 3 emails (from June 2005):
> >
> > * The initial email (from Rod) explaining why 3GPP proposed
> > another schema:
> > http://www.ietf.org/mail-archive/web/rmt/current/msg00404.html
> >
> > * The answer from Magnus, with the 3GPP schema:
> > http://www.ietf.org/mail-archive/web/rmt/current/msg00477.html
> >
> > * Finally Rod's promise (yes!!!) to include this schema:
> > http://www.ietf.org/mail-archive/web/rmt/current/msg00482.html
> >
> > That's for the history. The question now is what do we want
> > to do?
> >
> > Vincent
> >
> >
> > > _______________________________________________
> > > Rmt mailing list
> > > Rmt@ietf.org<mailto:Rmt@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/rmt
> > >
> >
> >
> > > --
> > >
> > > Magnus Westerlund
> > >
> > >
> ----------------------------------------------------------------------
> > > Multimedia Technologies, Ericsson Research EAB/TVM
> > >
> ----------------------------------------------------------------------
> > > Ericsson AB                                                          | Phone  +46 10 7148287
> > > Färögatan 6                                                          | Mobile +46 73 0949079
> > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com<mailto:magnus.westerlund@ericsson.com>
> > >
> ----------------------------------------------------------------------
> > > _______________________________________________
> > > Rmt mailing list
> > > Rmt@ietf.org<mailto:Rmt@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/rmt
> > >
> > >
> >
> >
>
> <Attachment>  ATT00001..txt
>
>
>

<Attachment>  ATT00001..txt