Re: [Rmt] About Flute-revised open points

"David Harrington" <ietfdbh@comcast.net> Wed, 13 April 2011 07:47 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: rmt@ietfc.amsl.com
Delivered-To: rmt@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2991EE06B9 for <rmt@ietfc.amsl.com>; Wed, 13 Apr 2011 00:47:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sD7tcwUktYbi for <rmt@ietfc.amsl.com>; Wed, 13 Apr 2011 00:47:43 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfc.amsl.com (Postfix) with ESMTP id 569FFE0674 for <rmt@ietf.org>; Wed, 13 Apr 2011 00:47:43 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id Wvmq1g0030bG4ec5EvnkCv; Wed, 13 Apr 2011 07:47:44 +0000
Received: from davidPC ([188.20.103.10]) by omta03.westchester.pa.mail.comcast.net with comcast id WvnF1g00B0DTzuc3PvnT4G; Wed, 13 Apr 2011 07:47:42 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: <Rod.Walsh@nokia.com>, <brian.adamson@nrl.navy.mil>, <magnus.westerlund@ericsson.com>
References: <1302348585.4017.17.camel@Nokia-N900>
In-Reply-To: <1302348585.4017.17.camel@Nokia-N900>
Date: Wed, 13 Apr 2011 09:47:09 +0200
Message-ID: <C32238CBE79A491CAF9E23E5C5F1C8AC@davidPC>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F0_01CBF9BF.D1EFBB10"
X-Mailer: Microsoft Office Outlook 11
X-MIMEOLE: Produced By Microsoft MimeOLE V6.1.7600.16543
Thread-Index: Acv2qXVsJF/69JTzS0O60yc5Eki+fgDAtz7A
Cc: rmt@ietf.org
Subject: Re: [Rmt] About Flute-revised open points
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 13 Apr 2011 07:47:45 -0000

Hi,
 
I think it makes no difference whether it is byte-to-long or
long-to-byte.
If one implementation sends a long value to an implementation that
supports only byte, they do not interoperate.
Both ends need to agree or you lose interoperability.
If the specs differ, then you need a mechanism to determine which set
of rules are followed - a version#
 
dbh
 
 
  _____  

From: rmt-bounces@ietf.org [mailto:rmt-bounces@ietf.org] On Behalf Of
Rod.Walsh@nokia.com
Sent: Saturday, April 09, 2011 1:30 PM
To: brian.adamson@nrl.navy.mil; magnus.westerlund@ericsson.com
Cc: rmt@ietf.org
Subject: Re: [Rmt] About Flute-revised open points



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 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 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 
> > > 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 
> > > 
>
----------------------------------------------------------------------

> > > _______________________________________________ 
> > > Rmt mailing list 
> > > Rmt@ietf.org 
> > > https://www.ietf.org/mailman/listinfo/rmt 
> > > 
> > > 
> > 
> > 
> 
> <Attachment>  ATT00001..txt 
> 
> 
> 

<Attachment>  ATT00001..txt