Vincent Roca | 4 Dec 12:10 2009
Picon

Re: AD evaluation comments on draft-ietf-rmt-flute-revised-06

Magnus,

I've started going through your comments. I haven't finished yet, but
I'd like to see opinions about the following two topics:

> >> >> 2. I have basically the same comment on this document as on
> >> >> ALC PI about mandatory to implement security solutions.
> >> >>
> > >
> > > [Toni] Unfortunately I have not followed that closely the review on ALC. Could you please state the
needed change you want to see in FLUTE RFC?
>
> Okay, the general issue comes from BCP 61 (RFC 3365) and I think the
> sentence from the end of section 6 is the most relevant:
>
>    The solution is that we MUST implement strong security in all
>    protocols to provide for the all too frequent day when the protocol
>    comes into widespread use in the global Internet.
>
> To achieve this and have interoperability also in the strong security
> mechanism the ground rule is to mandate implementation of at least one
> mechanism, cipher suite, etc to achieve that interoperability.
>
> The current security consideration section does a great job of
> discussing the threats and possible solution. But it doesn't mandate
> which solutions MUST be implemented.
>
> So the question to you and the WG is can we do this for FLUTE? I know
> this is not straight forward and certain deployments has different needs
> and use of security.
(Continue reading)

Magnus Westerlund | 8 Dec 10:54 2009
Picon

Re: AD evaluation comments on draft-ietf-rmt-flute-revised-06

Vincent Roca skrev:
> Magnus,
> 
> I've started going through your comments. I haven't finished yet, but
> I'd like to see opinions about the following two topics:
> 
> 
>>>>>> 2. I have basically the same comment on this document as on
>>>>>> ALC PI about mandatory to implement security solutions.
>>>>>>
>>>> [Toni] Unfortunately I have not followed that closely the review on ALC. Could you please state the
needed change you want to see in FLUTE RFC?
>> Okay, the general issue comes from BCP 61 (RFC 3365) and I think the
>> sentence from the end of section 6 is the most relevant:
>>
>>    The solution is that we MUST implement strong security in all
>>    protocols to provide for the all too frequent day when the protocol
>>    comes into widespread use in the global Internet.
>>
>> To achieve this and have interoperability also in the strong security
>> mechanism the ground rule is to mandate implementation of at least one
>> mechanism, cipher suite, etc to achieve that interoperability.
>>
>> The current security consideration section does a great job of
>> discussing the threats and possible solution. But it doesn't mandate
>> which solutions MUST be implemented.
>>
>> So the question to you and the WG is can we do this for FLUTE? I know
>> this is not straight forward and certain deployments has different needs
>> and use of security.
(Continue reading)

Luby, Michael | 8 Dec 23:38 2009

Re: Rmt Digest, Vol 65, Issue 2

Some comments at the end below. (Start with *** (MGL).)


On 12/8/09 12:00 PM, "rmt-request <at> ietf.org" <rmt-request <at> ietf.org> wrote:

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/rmt

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send Rmt mailing list submissions to
        rmt <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rmt
or, via email, send a message with subject or body 'help' to
        rmt-request <at> ietf.org

You can reach the person managing the list at
        rmt-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rmt digest..."


Today's Topics:

   1. Re: AD evaluation comments on draft-ietf-rmt-flute-revised-06
      (Magnus Westerlund)


----------------------------------------------------------------------

Message: 1
Date: Tue, 08 Dec 2009 10:54:53 +0100
From: Magnus Westerlund <magnus.westerlund <at> ericsson.com>
Subject: Re: [Rmt] AD evaluation comments on
        draft-ietf-rmt-flute-revised-06
To: Vincent Roca <vincent.roca <at> inrialpes.fr>
Cc: toni.paila <at> nokia.com, "rmt <at> ietf.org" <rmt <at> ietf.org>
Message-ID: <4B1E226D.3090504 <at> ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1

Vincent Roca skrev:
> Magnus,
>
> I've started going through your comments. I haven't finished yet, but
> I'd like to see opinions about the following two topics:
>
>
>>>>>> 2. I have basically the same comment on this document as on
>>>>>> ALC PI about mandatory to implement security solutions.
>>>>>>
>>>> [Toni] Unfortunately I have not followed that closely the review on ALC. Could you please state the needed change you want to see in FLUTE RFC?
>> Okay, the general issue comes from BCP 61 (RFC 3365) and I think the
>> sentence from the end of section 6 is the most relevant:
>>
>>    The solution is that we MUST implement strong security in all
>>    protocols to provide for the all too frequent day when the protocol
>>    comes into widespread use in the global Internet.
>>
>> To achieve this and have interoperability also in the strong security
>> mechanism the ground rule is to mandate implementation of at least one
>> mechanism, cipher suite, etc to achieve that interoperability.
>>
>> The current security consideration section does a great job of
>> discussing the threats and possible solution. But it doesn't mandate
>> which solutions MUST be implemented.
>>
>> So the question to you and the WG is can we do this for FLUTE? I know
>> this is not straight forward and certain deployments has different needs
>> and use of security.
>
> [VR] Since FLUTE relies on ALC/LCT, and since ALC has a "MANDATORY to
> implement" requirement for IPsec (just like NORM), I think the natural
> answer is "do what ALC mandates".
> I'll kept the security risk analysis almost as such and will add a new
> section to clarify this.
>
> However it should be noted that ALC (NORM as well) restricts the use of
> IPsec to the case of SSM. There is no mandatory to implement solution
> for the case of ASM. Since ALC only considers the case of a single sender,
> there's a good match with SSM. So I suggest to leave it like that (and it
> didn't prevent NORM to be published as an RFC).

Yes, I think that is a good suggestion.

>
>
>>>>>> 6. Section 3.4.1:
>>>>>>   Mandatory receiver behavior for handling FDT Instance
>>>>>>   ID wraparound and other special situations (for example, missing FDT
>>>>>>   Instance IDs resulting in larger increments than one) is outside the
>>>>>>   scope of this specification and left to individual
>>>>>> implementations of
>>>>>>   FLUTE.
>>>>>>
>>>>>> Why isn't this specified. Seem to be important for interoperable usage.
>>>>>> Seems to be a fine thing to gloss over in an experimental, but
>>>>>> not in a proposed standard.
>>>>>>
>>>> [Toni] The text states that what actions the special situation causes in the receiver is up to receiver. In a same way your web browser will typically show a different error message than my trying to access http://ww.w3.org. I see one valid
> implementation trying to recover from situation by staying longer in the session and trying to deduce what happened. Meanwhile I see another implementation possibly using out of band methods (if available) for the same. In other words, error recovery or
> concealment or similar is not in the scope of the spec.
>> Hmm, I will let it slide. Let see if anyone else in IESG bites on this,
>> clearly not impossible. As it from my perspective looks like where error
>> conditions could be avoided by specifying the correct behavior.
>
> [VR] I agree with Toni W.R.T. the problem of FDT Instance ID wraparound
> when the two FDT Instances are non expired. It's clearly an erroneous
> situation and how to address it is out-of-scope.
>
> There's just an (easy to fix) issue in sections 3.1 and 3.3 that say:
>      "Each File Delivery Table Instance is uniquely
>       identified by an FDT Instance ID."
> which contradicts the possibility of wraparound. I think that saying:
>      "Each non-expired..."
> solves it.
>
>
> Now I don't agree with Toni W.R.T. the case of missing FDT Instance ID
> (or IDs). IMHO this is not a special situation but a *common situation*.
> That's typically what terminals with intermittent connections experience.
> I suggest to make the support of this situation MANDATORY.
>
> There are implications here, since FDT Instance management is rather
> flexible, see Section 3.2:
>   "Any FDT Instance can be equal to, a subset of, a
>    superset of, or complement any other FDT Instance.  A certain FDT
>    Instance may be repeated several times during a session, even after
>    subsequent FDT Instances (with higher FDT Instance ID numbers) have
>    been transmitted."
> So if FDT Instances complement one another rather, there could be problems.
> More precisely, imagine FDT Instance 1 describes objects A and B. Then
> object C is added. If the sender chooses to describe only object C in
> FDT Instance 2 (i.e. FDT Instances 1 and 2 complement each other) and
> not to transmit FDT Instance 1 any more (it's authorized), a receiver that
> missed FDT Instance 1 will not be able to process objects A and B, even
> if he received enough encoding symbols for them.
> Admitedly, it does not break the receiver, so it's safe, but it remains
> largely sub-optimal.
>
> So, IMHO, we should also clarify that a FLUTE sender SHOULD NOT assume
> receivers will receive all FDT Instances, i.e. it is RECOMMENDED that
> FDT Instances be managed in such a way to make the FLUTE session robust
> in front of FDT Instance losses. One possibility is to use only
> self-sufficient FDT Instances, another one is to repeat all FDT Instances
> that complement each other at a given moment.
>
> Having said that, I don't know if such a recommendation is in line with
> current FLUTE deployment guidelines (e.g. in DVB-IPDC) ? Any comment or
> additional piece of information here?

Vincent, I think your recommendations are good. However, also I am
lacking information about thus. However, I don't see that a
recommendation will create any serious issue for our users. They can
either accept it or explain why their usage should ignore the
recommendation.

*** (MGL) To clarify, what I suggest is to say that “... a FLUTE sender SHOULD assume receivers will not receive all packets pertaining to FDT instances, i.e., it is RECOMMENDED that FDT instances be managed in such a way that a receiver will be able to recover at least one FDT instance describing a file delivered within the FLUTE session with as much or greater reliability as the receiver is able to receive enough packets containing encoding symbols for the file to recover the file.  As an example, one way to satisfy this recommendation is to repeat FDT instances describing the file often enough. As another example, another way to satisfy this recommendation is to use an FEC code for an FDT instance describing the file and send encoding symbols for the FDT instance often enough.”  BTW, I didn’t understand what it meant to be “self-sufficient”, nor what it meant to “repeat all FDT instances that complement each other at a given moment”.  I’m guessing that “self-sufficient” means an FDT instance that describes all files being delivered at that time?  And, “repeat all FDT instances that complement each other at a given moment” means something like repeat all FDT instances that are relevant to a particular receiver at a given moment?  (But I’m not sure if complement is used here in the same sense as how complement is used elsewhere in the draft, and it seems like it is different as the other sense of complement doesn’t make sense here.)  Anyway, perhaps these examples could be fleshed out a bit?

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
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 <at> ericsson.com
----------------------------------------------------------------------


------------------------------

_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt


End of Rmt Digest, Vol 65, Issue 2
**********************************

_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Lorenzo Vicisano | 17 Dec 01:40 2009
Picon

ReaptorG (draft-luby-rmt-bb-fec-raptorg-object-01) as WG Item

All,

draft-luby-rmt-bb-fec-raptorg-object-01 was discussed at the last WG meeting
as a potential WG draft. See the newly uploaded meeting minutes for
more context.

If you have comments on making this a WG work item, please reply to this email.

   thanks,
   Lorenzo Vicisano
Internet-Drafts | 23 Dec 19:00 2009
Picon

I-D Action:draft-ietf-rmt-flute-revised-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title           : FLUTE - File Delivery over Unidirectional Transport
	Author(s)       : T. Paila, et al.
	Filename        : draft-ietf-rmt-flute-revised-08.txt
	Pages           : 40
	Date            : 2009-12-23

This document defines FLUTE, a protocol for the unidirectional
delivery of files over the Internet, which is particularly suited to
multicast networks.  The specification builds on Asynchronous Layered
Coding, the base protocol designed for massively scalable multicast
distribution.  This document obsoletes RFC3926.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 26, 2010.

Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-revised-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-rmt-flute-revised-08.txt): message/external-body, 70 bytes
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title           : FLUTE - File Delivery over Unidirectional Transport
	Author(s)       : T. Paila, et al.
	Filename        : draft-ietf-rmt-flute-revised-08.txt
	Pages           : 40
	Date            : 2009-12-23

This document defines FLUTE, a protocol for the unidirectional
delivery of files over the Internet, which is particularly suited to
multicast networks.  The specification builds on Asynchronous Layered
Coding, the base protocol designed for massively scalable multicast
distribution.  This document obsoletes RFC3926.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 26, 2010.

Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-revised-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Vincent Roca | 23 Dec 19:10 2009
Picon

Updated version of FLUTE-revised

Magnus, Mike and everybody,

I've just submitted version -08 of FLUTE revised:

http://tools.ietf.org/html/draft-ietf-rmt-flute-revised

Please find below answers to the comments you sent to the list on 
September 1st
WRT version -06. I removed the comments already addressed by Toni in 
version -07.
I have also attached comments already sent on the list beginning of 
December with
Mike answer to this email. Comments are of course welcome.

Regards,

Vincent

 > >> >> 4. Section 1. As the ALC PI isn't suitable for general
 > >> >> deployment using unicast, flute can't really either. The
 > >> >> congestion control is the issue.
 > >> >>
 > > >
 > > > [Toni] Reviewing section 1 and sub sections of section 1 I think 
this item is stated.
 > > >
 > > > Especially:
 > > > "FLUTE can be used with both multicast and unicast delivery, but it's
 > > > primary application is for unidirectional multicast file delivery.
 > > > FLUTE requires connectivity between a sender and receivers but does
 > > > not require connectivity from receivers to a sender. FLUTE
 > > > inherently works with all types of networks, including LANs, WANs,
 > > > Intranets, the Internet, asymmetric networks, wireless networks, and
 > > > satellite networks.
 > > >
 > > > FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
 > > > is IP version specific. FLUTE works with both multicast models: Any-
 > > > Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM)
 > > > [16].
 > > >
 > > > FLUTE is applicable for both Internet use, with a suitable congestion
 > > > control building block, and provisioned/controlled systems, such as
 > > > delivery over wireless broadcast radio systems."
 > > >
 > > > Do you think I should change section 1 somehow? If so, how?
 >
 > In some sense the information are there, but it is not made particularly
 > clear that unicast delivery over Internet is lacking a good congestion
 > control mechanism to my knowledge. Currently the only thing that I can
 > think of is using Webrc or at least reception monitoring and then a
 > separate control protocol to stop the streams.
 >
 > In general the massive scaling properties are colliding with unicast.
 >
 > Thus could we make this clear in Section 1.1.4?

[VR] I've added a paragraph in section 1.1.4, as suggested. New text:
"FLUTE can also be used for point-to-point (unicast) communications.
At a minimum, implementions of ALC MUST support the WEBRC [27]
multiple rate congestion control scheme [2]. However, since WEBRC
has been designed for massively scalable multicast flows, it is not
clear how appropriate it is to the particular case of unicast flows.
Using a separate point-to-point congestion control scheme is another
alternative. How to do do that is outside the scope of the present
document."

 > >> >> 5. Section 3.3, there is a reference to the NTP time format.
 > >> >> NTP v4 has been to IESG but are not approved yet. Are there a
 > >> >> point of actually referencing the clarified formats in that
 > >> >> doc? That also have a clarified discussion about epochs that
 > >> >> helps handling the wrap around.
 > >> >>
 > > >
 > > > [Toni] How would you change the current statement "Handling of 
wraparound of the 32 bit time i
s outside the scope of NTP and FLUTE."
 > > > I cannot come up with any other more accurate statement for this 
part of the spec.
 >
 > Well, the new NTP spec does discuss epochs. And if you have a local
 > clock, then you can actually know which epoch it currently are and apply
 > that. That seems the most reasonable handling of this wrap around.
 >
 > Maybe an informal pointer about the handling of epoch to
 > draft-ietf-ntp-ntpv4-proto. Section 6 seems to be the main 
interesting one.

[VR] Good point (I was not aware of the era/epoch concept of NTPv4). New 
text:
"These 32 bits provide an unsigned integer
representing the time in seconds relative to 0 hours 1 January
1900 in case of the prime epoch (era 0) [20]. The handling of
time wraparound (to happen in 2036) requires to consider the
associated epoch. In any case, both a sender and a receiver can
easily determine to which (136 year) epoch the FDT Instance
expiration time value pertains to."
However, with this new sentence, I have the feeling NTPv4 needs to be
in the Normative References section, i.e. we create a dependancy with
NTPv4 (for the moment only NTPv3 is normative, NTPv4 is informative)...

 > >> >> 7. Section 3.4.2:
 > >> >>
 > >> >> Why is only HTTP URLs valid in the location header? In
 > >> >> addition why was HTTP URLs used? There is after all an
 > >> >> explicit transport mechanism implied by that. Some
 > >> >> clarification on that relation would be good.
 > >> >>
 > > >
 > > > [Toni] At the time of design it was found that "Content-Location" 
serves the purpose best. I s
ee no problem allowing any generic URL. Would you be so kind and provide 
me normative reference for
generic URL? Would http://www.rfc-editor.org/rfc/std/std66.txt do?
 > > >
 >
 > Actually by referencing HTTP (RFC 2616) you actually get that generic
 > URI are allowed in the header. So from a syntax perspective this appears
 > to be fine. So actually I might have misinterpreted the spec myself here.
 >
 > I still find the relation between the URI space used in the
 > Content-Location header and FLUTE a bit unclear. I wished this was clear
 > explained, but I will not demand that you improve this.

[VR] I havn't done anything. Please tell me if I should.

 > >> >> 10. Section 6:
 > >> >>
 > >> >> Shouldn't this text discuss the need for configuring the
 > >> >> congestion control mechanism also? The security parameters
 > >> >> needs discussion also.
 > >> >>
 > > >
 > > > [Toni] The congestion control parameters to be used depend on the 
congestion control block to
be used. Same goes for security. I suggest adding two bullets in the 
list of non-exhaustive list of
optional items:
 > > > * Definition and configuration of congestion control mechanism 
for the session
 > > > * Security parameters relevant for the session
 > > >
 > > > Is this OK?
 > > >
 >
 > I think this is a good addition to the text.
 >
 > However, the implementation of WEBRC is mandated by ALC PI which FLUTE
 > depends on. I guess this means that we might have to get the
 > mehta-flute-sdp draft back from the RFC-editor to make sure that
 > congestion control and the necessary security parameters are included in
 > the FLUTE SDP solution.

[VR] I havn't done anything here since Toni already modified -07
accordingly.

 > >> >> 11. Section 8.2: Chairs, have the update of the media type
 > >> >> registrations been reviewed on the ietf-types list?
 > >> >>
 > > >
 > > > [Toni] Any progress report from the Chairs on this item?
 >
 > I don't think this new version has been sent to the ietf-types list for
 > review. Chairs, please do that as soon as

[VR] Brian/Lorenzo, any news here?

 > >> >> 12. Section 8.2: The template hasn't been updated. The change
 > >> >> controller is a split item and should be saying "IETF".
 > >> >>
 > > >
 > > > [Toni] Would the right line be as follows: " Author/Change 
controller: IETF"
 >
 > "Change controller: IETF" would be correct. It is allowed to split this
 > line into two items:
 >
 > Author: Draft authors names
 > Change controller: IETF

[VR] Since Author/Change controller: IETF is fine, I didn't change anything.

 > >> >> 13. Section 8.3.1: It seems to be some confusion about the
 > >> >> usage of URN for purpose of describing where the name spaces
 > >> >> are. I think this needs to be clarified. Can the authors and
 > >> >> the chairs please try to resolve this with the IANA?
 > >> >>
 > > >
 > > > [Toni] I will contact IANA.
 >
 > > >
 >
 > I think this is a good addition to the text.
 >
 > However, the implementation of WEBRC is mandated by ALC PI which FLUTE
 > depends on. I guess this means that we might have to get the
 > mehta-flute-sdp draft back from the RFC-editor to make sure that
 > congestion control and the necessary security parameters are included in
 > the FLUTE SDP solution.

[VR] I havn't done anything here since Toni already modified -07
accordingly.

 > >> >> 11. Section 8.2: Chairs, have the update of the media type
 > >> >> registrations been reviewed on the ietf-types list?
 > >> >>
 > > >
 > > > [Toni] Any progress report from the Chairs on this item?
 >
 > I don't think this new version has been sent to the ietf-types list for
 > review. Chairs, please do that as soon as

[VR] Brian/Lorenzo, any news here?

 > >> >> 12. Section 8.2: The template hasn't been updated. The change
 > >> >> controller is a split item and should be saying "IETF".
 > >> >>
 > > >
 > > > [Toni] Would the right line be as follows: " Author/Change 
controller: IETF"
 >
 > "Change controller: IETF" would be correct. It is allowed to split this
 > line into two items:
 >
 > Author: Draft authors names
 > Change controller: IETF

[VR] Since Author/Change controller: IETF is fine, I didn't change anything.

 > >> >> 13. Section 8.3.1: It seems to be some confusion about the
 > >> >> usage of URN for purpose of describing where the name spaces
 > >> >> are. I think this needs to be clarified. Can the authors and
 > >> >> the chairs please try to resolve this with the IANA?
 > >> >>
 > > >
 > > > [Toni] I will contact IANA.
 >
 > Good, please add the chairs and me into the loop.

[VR] Based on this discussion and the comments you and Mark sent on
Sept 3rd, I remove any reference to URN in this section.

[VR] Finally, I moved Rami Lehtonen to the end of the author list since he
did not contribute (at least significantly) to this revised version AFAIK.
I've also updated Mike's address.

[VR] Concerning the security aspects, I've modified section 7 and added
section 7.5. "Minimum Security Recommendations", (in line with ALC
recommendations). I also moved from SHA-1 to SHA-256 to be in line
with IETF general recommendations.

 >>>>>>> 6. Section 3.4.1:
 >>>>>>> Mandatory receiver behavior for handling FDT Instance
 >>>>>>> ID wraparound and other special situations (for example, 
missing FDT
 >>>>>>> Instance IDs resulting in larger increments than one) is 
outside the
 >>>>>>> scope of this specification and left to individual
 >>>>>>> implementations of
 >>>>>>> FLUTE.
 >>>>>>>
 >>>>>>> Why isn't this specified. Seem to be important for 
interoperable usage.
 >>>>>>> Seems to be a fine thing to gloss over in an experimental, but
 >>>>>>> not in a proposed standard.
 >>>>>>>
 >>>>> [Toni] The text states that what actions the special situation 
causes in the receiver is up to
receiver. In a same way your web browser will typically show a different 
error message than my tryi
ng to access http://ww.w3.org. I see one valid
 >> implementation trying to recover from situation by staying longer in 
the session and trying to de
duce what happened. Meanwhile I see another implementation possibly 
using out of band methods (if av
ailable) for the same. In other words, error recovery or
 >> concealment or similar is not in the scope of the spec.
 >>> Hmm, I will let it slide. Let see if anyone else in IESG bites on this,
 >>> clearly not impossible. As it from my perspective looks like where 
error
 >>> conditions could be avoided by specifying the correct behavior.
 >>
 >> [VR] I agree with Toni W.R.T. the problem of FDT Instance ID wraparound
 >> when the two FDT Instances are non expired. It's clearly an erroneous
 >> situation and how to address it is out-of-scope.
 >>
 >> There's just an (easy to fix) issue in sections 3.1 and 3.3 that say:
 >> "Each File Delivery Table Instance is uniquely
 >> identified by an FDT Instance ID."
 >> which contradicts the possibility of wraparound. I think that saying:
 >> "Each non-expired..."
 >> solves it.
 >>
 >>
 >> Now I don't agree with Toni W.R.T. the case of missing FDT Instance ID
 >> (or IDs). IMHO this is not a special situation but a *common situation*.
 >> That's typically what terminals with intermittent connections 
experience.
 >> I suggest to make the support of this situation MANDATORY.
 >>
 >> There are implications here, since FDT Instance management is rather
 >> flexible, see Section 3.2:
 >> "Any FDT Instance can be equal to, a subset of, a
 >> superset of, or complement any other FDT Instance. A certain FDT
 >> Instance may be repeated several times during a session, even after
 >> subsequent FDT Instances (with higher FDT Instance ID numbers) have
 >> been transmitted."
 >> So if FDT Instances complement one another rather, there could be 
problems.
 >> More precisely, imagine FDT Instance 1 describes objects A and B. Then
 >> object C is added. If the sender chooses to describe only object C in
 >> FDT Instance 2 (i.e. FDT Instances 1 and 2 complement each other) and
 >> not to transmit FDT Instance 1 any more (it's authorized), a 
receiver that
 >> missed FDT Instance 1 will not be able to process objects A and B, even
 >> if he received enough encoding symbols for them.
 >> Admitedly, it does not break the receiver, so it's safe, but it remains
 >> largely sub-optimal.
 >>
 >> So, IMHO, we should also clarify that a FLUTE sender SHOULD NOT assume
 >> receivers will receive all FDT Instances, i.e. it is RECOMMENDED that
 >> FDT Instances be managed in such a way to make the FLUTE session robust
 >> in front of FDT Instance losses. One possibility is to use only
 >> self-sufficient FDT Instances, another one is to repeat all FDT 
Instances
 >> that complement each other at a given moment.
 >>
 >> Having said that, I don't know if such a recommendation is in line with
 >> current FLUTE deployment guidelines (e.g. in DVB-IPDC) ? Any comment or
 >> additional piece of information here?
 >
 >Vincent, I think your recommendations are good. However, also I am
 >lacking information about thus. However, I don't see that a
 >recommendation will create any serious issue for our users. They can
 >either accept it or explain why their usage should ignore the
 >recommendation.
 >
 >*** (MGL) To clarify, what I suggest is to say that “... a FLUTE 
sender SHOULD assume receivers will
 > not receive all packets pertaining to FDT instances, i.e., it is 
RECOMMENDED that FDT instances be
 > managed in such a way that a receiver will be able to recover at 
least one FDT instance describing
 > a file delivered within the FLUTE session with as much or greater 
reliability as the receiver is able
 > to receive enough packets containing encoding symbols for the file to 
recover the file. As an example,
 > one way to satisfy this recommendation is to repeat FDT instances 
describing the file often enough. As
 > another example, another way to satisfy this recommendation is to use 
an FEC code for an FDT instance
 > describing the file and send encoding symbols for the FDT instance 
often enough.” BTW, I
 > didn’t understand what it meant to be “self-sufficient”, nor what it 
meant to “repeat all FDT instances
 > that complement each other at a given moment”. I’m guessing that 
“self-sufficient” means an FDT
 > instance that describes all files being delivered at that time? And, 
“repeat all FDT instances th
 > at complement each other at a given moment” means something like 
repeat all FDT instances that are
 > relevant to a particular receiver at a given moment? (But I’m not 
sure if complement is used here in
 > the same sense as how complement is used elsewhere in the draft, and 
it seems like it is different
 > as the other sense of complement doesn’t make sense here.) Anyway, 
perhaps these examples could be
 > fleshed out a bit?

[VR] Thanks Mike for the text proposal. It is indeed what I had in mind 
(but did
not express sufficiently well). What I did is the following:

1/ I've modified section 3.3 where the issue of sending FDT reliably was 
already
discussed. I now distinguish two complementary aspects: (1) the reliable
transmission of an FDT Instance (through repetition and/or FEC encoding),
and (2) the way the FDT is delivered as FDT Instances which also impacts
reliability.

2/ I've modified section 3.4.1 to correct what should be considered as 
erroneous
situations. I've also corrected an incoherency since it was said that:
"A new FDT Instance reusing a previous FDT Instance ID number, due to
wraparound, may not implicitly expire the previous FDT Instance with
the same ID."
(note the use of "may") whereas it was previously said that after wraparound
only expired FDT Instances can be considered while choosing an FDT 
Instance ID.
Please see the -08 version or the diff for the details. The 
modifications I've
done are not insignificant. For instance, FDT Instance ID wraparound 
handling
MUST be supported.
Vincent Roca | 23 Dec 19:15 2009
Picon

revised FCAST I-D

Everybody,

I've also submitted a revised FCAST I-D, as a WG Item document
(it still needs to be approved as a -00 document, so it's not yet publicly
available).

The main differences WRT previous version concern the security
section. I've updated this section to add a "Minimum Security
Recommendations" similar to that of FLUTE, and in line with both
ALC and NORM recommendations.
It's now ready for an official WGLC.

Cheers,

    Vincent
Internet-Drafts | 24 Dec 22:30 2009
Picon

I-D Action:draft-ietf-rmt-fcast-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title           : FCAST: Scalable Object Delivery for the ALC and NORM Protocols
	Author(s)       : V. Roca, B. Adamson
	Filename        : draft-ietf-rmt-fcast-00.txt
	Pages           : 32
	Date            : 2009-12-23

This document introduces the FCAST object (e.g., file) delivery
application on top of the ALC and NORM reliable multicast protocols.
FCAST is a highly scalable application that provides a reliable
object delivery service.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 26, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-fcast-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
Attachment (draft-ietf-rmt-fcast-00.txt): message/external-body, 70 bytes
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Luby, Michael | 28 Dec 22:23 2009

Suggested wording changes to FLUTE

Vincent, RMT,
I suggest replacing the second to last paragraph of Section 3.3 to the attached.  (There were some grammar errors, and some ambiguities, that I think the replacement text cleans up.)  Also, my affiliation at the end was changed to Qualcomm, but the affiliation on the top right header of the first page still reads Digital Fountain and this should also be changed.
Regards, Mike


On 12/23/09 12:00 PM, "rmt-request <at> ietf.org" <rmt-request <at> ietf.org> wrote:

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/rmt

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send Rmt mailing list submissions to
        rmt <at> ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/rmt
or, via email, send a message with subject or body 'help' to
        rmt-request <at> ietf.org

You can reach the person managing the list at
        rmt-owner <at> ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Rmt digest..."


Today's Topics:

   1. I-D Action:draft-ietf-rmt-flute-revised-08.txt
      (Internet-Drafts <at> ietf.org)
   2. Updated version of FLUTE-revised (Vincent Roca)
   3. revised FCAST I-D (Vincent Roca)


----------------------------------------------------------------------

Message: 1
Date: Wed, 23 Dec 2009 10:00:02 -0800 (PST)
From: Internet-Drafts <at> ietf.org
Subject: [Rmt] I-D Action:draft-ietf-rmt-flute-revised-08.txt
To: i-d-announce <at> ietf.org
Cc: rmt <at> ietf.org
Message-ID: <20091223180002.729A83A6A24 <at> core3.amsl.com>
Content-Type: text/plain; charset="us-ascii"



------------------------------

Message: 2
Date: Wed, 23 Dec 2009 19:10:34 +0100
From: Vincent Roca <vincent.roca <at> inrialpes.fr>
Subject: [Rmt] Updated version of FLUTE-revised
To: "rmt <at> ietf.org" <rmt <at> ietf.org>
Message-ID: <4B325D1A.30502 <at> inrialpes.fr>
Content-Type: text/plain; charset=windows-1252; format=flowed

Magnus, Mike and everybody,

I've just submitted version -08 of FLUTE revised:

http://tools.ietf.org/html/draft-ietf-rmt-flute-revised

Please find below answers to the comments you sent to the list on
September 1st
WRT version -06. I removed the comments already addressed by Toni in
version -07.
I have also attached comments already sent on the list beginning of
December with
Mike answer to this email. Comments are of course welcome.

Regards,

Vincent

 > >> >> 4. Section 1. As the ALC PI isn't suitable for general
 > >> >> deployment using unicast, flute can't really either. The
 > >> >> congestion control is the issue.
 > >> >>
 > > >
 > > > [Toni] Reviewing section 1 and sub sections of section 1 I think
this item is stated.
 > > >
 > > > Especially:
 > > > "FLUTE can be used with both multicast and unicast delivery, but it's
 > > > primary application is for unidirectional multicast file delivery.
 > > > FLUTE requires connectivity between a sender and receivers but does
 > > > not require connectivity from receivers to a sender. FLUTE
 > > > inherently works with all types of networks, including LANs, WANs,
 > > > Intranets, the Internet, asymmetric networks, wireless networks, and
 > > > satellite networks.
 > > >
 > > > FLUTE is compatible with both IPv4 or IPv6 as no part of the packet
 > > > is IP version specific. FLUTE works with both multicast models: Any-
 > > > Source Multicast (ASM) [15] and the Source-Specific Multicast (SSM)
 > > > [16].
 > > >
 > > > FLUTE is applicable for both Internet use, with a suitable congestion
 > > > control building block, and provisioned/controlled systems, such as
 > > > delivery over wireless broadcast radio systems."
 > > >
 > > > Do you think I should change section 1 somehow? If so, how?
 >
 > In some sense the information are there, but it is not made particularly
 > clear that unicast delivery over Internet is lacking a good congestion
 > control mechanism to my knowledge. Currently the only thing that I can
 > think of is using Webrc or at least reception monitoring and then a
 > separate control protocol to stop the streams.
 >
 > In general the massive scaling properties are colliding with unicast.
 >
 > Thus could we make this clear in Section 1.1.4?

[VR] I've added a paragraph in section 1.1.4, as suggested. New text:
"FLUTE can also be used for point-to-point (unicast) communications.
At a minimum, implementions of ALC MUST support the WEBRC [27]
multiple rate congestion control scheme [2]. However, since WEBRC
has been designed for massively scalable multicast flows, it is not
clear how appropriate it is to the particular case of unicast flows.
Using a separate point-to-point congestion control scheme is another
alternative. How to do do that is outside the scope of the present
document."


 > >> >> 5. Section 3.3, there is a reference to the NTP time format.
 > >> >> NTP v4 has been to IESG but are not approved yet. Are there a
 > >> >> point of actually referencing the clarified formats in that
 > >> >> doc? That also have a clarified discussion about epochs that
 > >> >> helps handling the wrap around.
 > >> >>
 > > >
 > > > [Toni] How would you change the current statement "Handling of
wraparound of the 32 bit time i
s outside the scope of NTP and FLUTE."
 > > > I cannot come up with any other more accurate statement for this
part of the spec.
 >
 > Well, the new NTP spec does discuss epochs. And if you have a local
 > clock, then you can actually know which epoch it currently are and apply
 > that. That seems the most reasonable handling of this wrap around.
 >
 > Maybe an informal pointer about the handling of epoch to
 > draft-ietf-ntp-ntpv4-proto. Section 6 seems to be the main
interesting one.

[VR] Good point (I was not aware of the era/epoch concept of NTPv4). New
text:
"These 32 bits provide an unsigned integer
representing the time in seconds relative to 0 hours 1 January
1900 in case of the prime epoch (era 0) [20]. The handling of
time wraparound (to happen in 2036) requires to consider the
associated epoch. In any case, both a sender and a receiver can
easily determine to which (136 year) epoch the FDT Instance
expiration time value pertains to."
However, with this new sentence, I have the feeling NTPv4 needs to be
in the Normative References section, i.e. we create a dependancy with
NTPv4 (for the moment only NTPv3 is normative, NTPv4 is informative)...


 > >> >> 7. Section 3.4.2:
 > >> >>
 > >> >> Why is only HTTP URLs valid in the location header? In
 > >> >> addition why was HTTP URLs used? There is after all an
 > >> >> explicit transport mechanism implied by that. Some
 > >> >> clarification on that relation would be good.
 > >> >>
 > > >
 > > > [Toni] At the time of design it was found that "Content-Location"
serves the purpose best. I s
ee no problem allowing any generic URL. Would you be so kind and provide
me normative reference for
generic URL? Would http://www.rfc-editor.org/rfc/std/std66.txt do?
 > > >
 >
 > Actually by referencing HTTP (RFC 2616) you actually get that generic
 > URI are allowed in the header. So from a syntax perspective this appears
 > to be fine. So actually I might have misinterpreted the spec myself here.
 >
 > I still find the relation between the URI space used in the
 > Content-Location header and FLUTE a bit unclear. I wished this was clear
 > explained, but I will not demand that you improve this.

[VR] I havn't done anything. Please tell me if I should.


 > >> >> 10. Section 6:
 > >> >>
 > >> >> Shouldn't this text discuss the need for configuring the
 > >> >> congestion control mechanism also? The security parameters
 > >> >> needs discussion also.
 > >> >>
 > > >
 > > > [Toni] The congestion control parameters to be used depend on the
congestion control block to
be used. Same goes for security. I suggest adding two bullets in the
list of non-exhaustive list of
optional items:
 > > > * Definition and configuration of congestion control mechanism
for the session
 > > > * Security parameters relevant for the session
 > > >
 > > > Is this OK?
 > > >
 >
 > I think this is a good addition to the text.
 >
 > However, the implementation of WEBRC is mandated by ALC PI which FLUTE
 > depends on. I guess this means that we might have to get the
 > mehta-flute-sdp draft back from the RFC-editor to make sure that
 > congestion control and the necessary security parameters are included in
 > the FLUTE SDP solution.

[VR] I havn't done anything here since Toni already modified -07
accordingly.


 > >> >> 11. Section 8.2: Chairs, have the update of the media type
 > >> >> registrations been reviewed on the ietf-types list?
 > >> >>
 > > >
 > > > [Toni] Any progress report from the Chairs on this item?
 >
 > I don't think this new version has been sent to the ietf-types list for
 > review. Chairs, please do that as soon as

[VR] Brian/Lorenzo, any news here?


 > >> >> 12. Section 8.2: The template hasn't been updated. The change
 > >> >> controller is a split item and should be saying "IETF".
 > >> >>
 > > >
 > > > [Toni] Would the right line be as follows: " Author/Change
controller: IETF"
 >
 > "Change controller: IETF" would be correct. It is allowed to split this
 > line into two items:
 >
 > Author: Draft authors names
 > Change controller: IETF

[VR] Since Author/Change controller: IETF is fine, I didn't change anything.


 > >> >> 13. Section 8.3.1: It seems to be some confusion about the
 > >> >> usage of URN for purpose of describing where the name spaces
 > >> >> are. I think this needs to be clarified. Can the authors and
 > >> >> the chairs please try to resolve this with the IANA?
 > >> >>
 > > >
 > > > [Toni] I will contact IANA.
 >
 > > >
 >
 > I think this is a good addition to the text.
 >
 > However, the implementation of WEBRC is mandated by ALC PI which FLUTE
 > depends on. I guess this means that we might have to get the
 > mehta-flute-sdp draft back from the RFC-editor to make sure that
 > congestion control and the necessary security parameters are included in
 > the FLUTE SDP solution.

[VR] I havn't done anything here since Toni already modified -07
accordingly.


 > >> >> 11. Section 8.2: Chairs, have the update of the media type
 > >> >> registrations been reviewed on the ietf-types list?
 > >> >>
 > > >
 > > > [Toni] Any progress report from the Chairs on this item?
 >
 > I don't think this new version has been sent to the ietf-types list for
 > review. Chairs, please do that as soon as

[VR] Brian/Lorenzo, any news here?


 > >> >> 12. Section 8.2: The template hasn't been updated. The change
 > >> >> controller is a split item and should be saying "IETF".
 > >> >>
 > > >
 > > > [Toni] Would the right line be as follows: " Author/Change
controller: IETF"
 >
 > "Change controller: IETF" would be correct. It is allowed to split this
 > line into two items:
 >
 > Author: Draft authors names
 > Change controller: IETF

[VR] Since Author/Change controller: IETF is fine, I didn't change anything.


 > >> >> 13. Section 8.3.1: It seems to be some confusion about the
 > >> >> usage of URN for purpose of describing where the name spaces
 > >> >> are. I think this needs to be clarified. Can the authors and
 > >> >> the chairs please try to resolve this with the IANA?
 > >> >>
 > > >
 > > > [Toni] I will contact IANA.
 >
 > Good, please add the chairs and me into the loop.

[VR] Based on this discussion and the comments you and Mark sent on
Sept 3rd, I remove any reference to URN in this section.


[VR] Finally, I moved Rami Lehtonen to the end of the author list since he
did not contribute (at least significantly) to this revised version AFAIK.
I've also updated Mike's address.


[VR] Concerning the security aspects, I've modified section 7 and added
section 7.5. "Minimum Security Recommendations", (in line with ALC
recommendations). I also moved from SHA-1 to SHA-256 to be in line
with IETF general recommendations.


 >>>>>>> 6. Section 3.4.1:
 >>>>>>> Mandatory receiver behavior for handling FDT Instance
 >>>>>>> ID wraparound and other special situations (for example,
missing FDT
 >>>>>>> Instance IDs resulting in larger increments than one) is
outside the
 >>>>>>> scope of this specification and left to individual
 >>>>>>> implementations of
 >>>>>>> FLUTE.
 >>>>>>>
 >>>>>>> Why isn't this specified. Seem to be important for
interoperable usage.
 >>>>>>> Seems to be a fine thing to gloss over in an experimental, but
 >>>>>>> not in a proposed standard.
 >>>>>>>
 >>>>> [Toni] The text states that what actions the special situation
causes in the receiver is up to
receiver. In a same way your web browser will typically show a different
error message than my tryi
ng to access http://ww.w3.org. I see one valid
 >> implementation trying to recover from situation by staying longer in
the session and trying to de
duce what happened. Meanwhile I see another implementation possibly
using out of band methods (if av
ailable) for the same. In other words, error recovery or
 >> concealment or similar is not in the scope of the spec.
 >>> Hmm, I will let it slide. Let see if anyone else in IESG bites on this,
 >>> clearly not impossible. As it from my perspective looks like where
error
 >>> conditions could be avoided by specifying the correct behavior.
 >>
 >> [VR] I agree with Toni W.R.T. the problem of FDT Instance ID wraparound
 >> when the two FDT Instances are non expired. It's clearly an erroneous
 >> situation and how to address it is out-of-scope.
 >>
 >> There's just an (easy to fix) issue in sections 3.1 and 3.3 that say:
 >> "Each File Delivery Table Instance is uniquely
 >> identified by an FDT Instance ID."
 >> which contradicts the possibility of wraparound. I think that saying:
 >> "Each non-expired..."
 >> solves it.
 >>
 >>
 >> Now I don't agree with Toni W.R.T. the case of missing FDT Instance ID
 >> (or IDs). IMHO this is not a special situation but a *common situation*.
 >> That's typically what terminals with intermittent connections
experience.
 >> I suggest to make the support of this situation MANDATORY.
 >>
 >> There are implications here, since FDT Instance management is rather
 >> flexible, see Section 3.2:
 >> "Any FDT Instance can be equal to, a subset of, a
 >> superset of, or complement any other FDT Instance. A certain FDT
 >> Instance may be repeated several times during a session, even after
 >> subsequent FDT Instances (with higher FDT Instance ID numbers) have
 >> been transmitted."
 >> So if FDT Instances complement one another rather, there could be
problems.
 >> More precisely, imagine FDT Instance 1 describes objects A and B. Then
 >> object C is added. If the sender chooses to describe only object C in
 >> FDT Instance 2 (i.e. FDT Instances 1 and 2 complement each other) and
 >> not to transmit FDT Instance 1 any more (it's authorized), a
receiver that
 >> missed FDT Instance 1 will not be able to process objects A and B, even
 >> if he received enough encoding symbols for them.
 >> Admitedly, it does not break the receiver, so it's safe, but it remains
 >> largely sub-optimal.
 >>
 >> So, IMHO, we should also clarify that a FLUTE sender SHOULD NOT assume
 >> receivers will receive all FDT Instances, i.e. it is RECOMMENDED that
 >> FDT Instances be managed in such a way to make the FLUTE session robust
 >> in front of FDT Instance losses. One possibility is to use only
 >> self-sufficient FDT Instances, another one is to repeat all FDT
Instances
 >> that complement each other at a given moment.
 >>
 >> Having said that, I don't know if such a recommendation is in line with
 >> current FLUTE deployment guidelines (e.g. in DVB-IPDC) ? Any comment or
 >> additional piece of information here?
 >
 >Vincent, I think your recommendations are good. However, also I am
 >lacking information about thus. However, I don't see that a
 >recommendation will create any serious issue for our users. They can
 >either accept it or explain why their usage should ignore the
 >recommendation.
 >
 >*** (MGL) To clarify, what I suggest is to say that ?... a FLUTE
sender SHOULD assume receivers will
 > not receive all packets pertaining to FDT instances, i.e., it is
RECOMMENDED that FDT instances be
 > managed in such a way that a receiver will be able to recover at
least one FDT instance describing
 > a file delivered within the FLUTE session with as much or greater
reliability as the receiver is able
 > to receive enough packets containing encoding symbols for the file to
recover the file. As an example,
 > one way to satisfy this recommendation is to repeat FDT instances
describing the file often enough. As
 > another example, another way to satisfy this recommendation is to use
an FEC code for an FDT instance
 > describing the file and send encoding symbols for the FDT instance
often enough.? BTW, I
 > didn?t understand what it meant to be ?self-sufficient?, nor what it
meant to ?repeat all FDT instances
 > that complement each other at a given moment?. I?m guessing that
?self-sufficient? means an FDT
 > instance that describes all files being delivered at that time? And,
?repeat all FDT instances th
 > at complement each other at a given moment? means something like
repeat all FDT instances that are
 > relevant to a particular receiver at a given moment? (But I?m not
sure if complement is used here in
 > the same sense as how complement is used elsewhere in the draft, and
it seems like it is different
 > as the other sense of complement doesn?t make sense here.) Anyway,
perhaps these examples could be
 > fleshed out a bit?

[VR] Thanks Mike for the text proposal. It is indeed what I had in mind
(but did
not express sufficiently well). What I did is the following:

1/ I've modified section 3.3 where the issue of sending FDT reliably was
already
discussed. I now distinguish two complementary aspects: (1) the reliable
transmission of an FDT Instance (through repetition and/or FEC encoding),
and (2) the way the FDT is delivered as FDT Instances which also impacts
reliability.

2/ I've modified section 3.4.1 to correct what should be considered as
erroneous
situations. I've also corrected an incoherency since it was said that:
"A new FDT Instance reusing a previous FDT Instance ID number, due to
wraparound, may not implicitly expire the previous FDT Instance with
the same ID."
(note the use of "may") whereas it was previously said that after wraparound
only expired FDT Instances can be considered while choosing an FDT
Instance ID.
Please see the -08 version or the diff for the details. The
modifications I've
done are not insignificant. For instance, FDT Instance ID wraparound
handling
MUST be supported.



------------------------------

Message: 3
Date: Wed, 23 Dec 2009 19:15:18 +0100
From: Vincent Roca <vincent.roca <at> inrialpes.fr>
Subject: [Rmt] revised FCAST I-D
To: "rmt <at> ietf.org" <rmt <at> ietf.org>
Message-ID: <4B325E36.9080501 <at> inrialpes.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Everybody,

I've also submitted a revised FCAST I-D, as a WG Item document
(it still needs to be approved as a -00 document, so it's not yet publicly
available).

The main differences WRT previous version concern the security
section. I've updated this section to add a "Minimum Security
Recommendations" similar to that of FLUTE, and in line with both
ALC and NORM recommendations.
It's now ready for an official WGLC.

Cheers,

    Vincent


------------------------------

_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt


End of Rmt Digest, Vol 65, Issue 5
**********************************

_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt
Luby, Michael | 29 Dec 03:43 2009

More info on suggested wording changes to FLUTE

It occurred to me that the wording changes to the second to last paragraph of Section 3.3 might not make it to the list as an attachment, so below is the suggested replacement text (slightly amended from the attachment):

The way FDT Instances are transmitted has a large impact on satisfying the recommendation above. When there is a single file transmitted in the session, one way to satisfy the recommendation above is to repeatedly transmit on a regular enough basis FDT Instances describing the file while the file is being transmitted. As another example, if an FDT Instance is longer than one packet payload in length, it is RECOMMENDED that an FEC code that provides protection against loss be used for delivering this FDT Instance. When there are multiple files in a session concurrently being transmitted to receivers, the way the FDT Instances are structured and transmitted also has a large impact.  As an example, a way to satisfy the recommendation above is to transmit an FDT Instance that describes all files currently being transmitted, and to transmit this FDT Instance reliably, using the same techniques as explained for the case when there is a single file transmitted in a session.  If instead the concurrently transmitted files are described in separate FDT Instances, another way to satisfy this recommendation is to transmit all the relevant FDT Instances reliably, using the same techniques as explained for the case when there is a single file transmitted in a session.



On 12/28/09 2:07 PM, "rmt-request <at> ietf.org" <rmt-request <at> ietf.org> wrote:

https://www.ietf.org/mailman/listinfo/rmt
_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www.ietf.org/mailman/listinfo/rmt

Gmane