Subject: Re: [Rmt] FLUTE 06

From: Mark Handley <[email-masked]>
Date: Mon, 17 Nov 2003 10:33:11 +0000

I skim-read the first 11 or so pages.  Comments below - they're
detail, not substantial.  I'm not going to find time to read the rest
for at least a few days.

My personal recommendation given the other time constraints is to
issue a WG last call on this TODAY.  I don't think there's any benefit
from waiting.  BUT to also assign two reviewers who weren't involved
in writing the document to give it a detailed review during last call.
My guess from the reading the first third of the document is that it's
OK technically, but needs clarification in places.  I think this
clarification is important, even for Experimental, if other standards
organizations are going to be referencing this.

Cheers,
	Mark

>          FLUTE - File Delivery over Unidirectional Transport
>                      draft-ietf-rmt-flute-06.txt
...
>3. File delivery
...
>   *  Location of the file, expressed as either absolute or relative
>      URI. In the above example: "www.ex.com/docs/file.txt"

Is this really a "location", or a globally unique identifier?  What are
the indended semantics of this location?

>   *  File name (usually, this can be concluded from the URI). In the
>      above example: "file.txt"
>
>   *  File type, expressed as MIME media type (usually, this can also be
>      concluded from the extension of the file name). In the above
>      example: "text/plain"

What happens when the extension and MIME type mismatch?

>   *  File size, expressed in bytes. In the above example: "5200"

This is before content encoding isn't it?
...

>3.1 File delivery session
...
>   *  The TOI field MUST be included in ALC packets sent within a FLUTE
>      session, with the exception that ALC packets sent in a FLUTE
>      session with the Close session (A) flag set to 1 (signaling the
>      end of the session) and containing no payload MAY not include the
                                                     ^^^^^^^^^^^^^^^
suggest "MAY omit" to avoid confusion with MAY NOT include

>      TOI. See Section 5.1 of RFC 3451 [4] for the LCT definition of the
>      Close session flag, and see Section 4.2 of RFC 3450 [3] for an
>      example of its use within an ALC packet.

>3.2 File Delivery Table
>
>   The File Delivery Table (FDT) provides a means to describe various
>   attributes associated with files that are to be delivered within the
>   file delivery session. The following lists are examples of such
>   attributes, and are not intended to be mutually exclusive.
                                            
Do you mean this is not meant to be an exhaustive list?

...

>   Within the file delivery session the FDT is delivered as FDT
>   Instances. An FDT Instance contains one or more file description
>   entries of the FDT. 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. In minimum the FDT Instance contains a single file
                      ^^^^^^^^^^
Odd terminology.  Suggest "At a miminum..."  Also elsewhere in the document.

>   description entry. In maximum the FDT Instance contains the complete
>   FDT of the file delivery session.
...

>3.3 Dynamics of FDT Instances within file delivery session
...
>   *  An FDT Instance MAY appear in any part of the file delivery
>      session and even multiplexed with other files or other FDT
>      Instances.

I don't understand what this means with regard to "multiplexed with
other files".

>   *  An FDT Instance is valid until its expiration time. The expiration
>      time is expressed within the FDT Instance payload as a 32 bit data
>      field. The value of the data field represents the 32 most
>      significant bits of a 64 bit Network Time Protocol (NTP) [6] time
>      value. Wrap-around of the 32 bit time is to be handled according
>      to NTP.

>From RFC 1305:

"NTP timestamps are represented as a 64-bit unsigned fixed- point
number, in seconds relative to 0h on 1 January 1900. The integer part
is in the first 32 bits and the fraction part in the last 32 bits."

You could comment that "32 most significant bits" gives an unsigned
integer representing the time in seconds relative to 0h on 1 January
1900.

>From RFC 1305:

"Note that since some time in 1968 the most significant bit (bit 0 of the
integer part) has been set and that the 64-bit field will overflow some
time in 2036. Should NTP be in use in 2036, some external means will be
necessary to qualify time relative to 1900 and time relative to 2036
(and other multiples of 136 years)."

So RFC 1305 doesn't seem to handle wraparound.

>   *  The receiver behaviour upon expiration of the FDT Instance is out
>      of scope of this specification.

Why include an expiry and not define the expiration behavour?

>   Generally, a receiver needs to receive an FDT Instance describing a
>   file before it is able to recover the file itself. In this sense FDT
>   Instances are of higher priority than files. Thus, it is RECOMMENDED
>   that FTD Instances describing a file be sent with at least as much
         ^^^
FDT
...

>3.4 Structure of FDT Instance
...
>   FDT Instance ID, 20 bits:
>
>   For each file delivery session the numbering of FDT Instances starts
>   from '0' and is incremented by exactly one for each subsequent FDT
>   Instance. After reaching the maximum value (2^20-1), the numbering
>   starts again from '0'. When wraparound from 2^20-1 to 0 occurs, 0 is
>   considered higher than 2^20-1. Receiver handling of wraparound and
>   other special situations (for example, missing FDT Instance IDs
>   resulting in longer increments than one) is left out of this
>   specification to individual implementations of FLUTE.

What byte order is this in?

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Lorenzo Vicisano <[email-masked]>
Date: Mon, 17 Nov 2003 10:42:51 -0800

Mark,

> issue a WG last call on this TODAY.  I don't think there's any benefit

I'll be issuing last-call in a few hours, unless someone in this
list objects.

> in writing the document to give it a detailed review during last call.

The call for reviewers is open.

	Lorenzo

---

From: Allison Mankin <[email-masked]>
Date: Mon, 17 Nov 2003 19:21:46 -0800

All,

I support the Chairs' decision for the WGLC of FLUTE 06 that has been
issued today.   I agreed with their assessment of the circumstances and of
the discussions in Minneapolis.  

Another review or two such as Mark's will mean that the steps after WGLC
can be prompt as well.

Allison (as AD for RMT)