[Rmt] RE: draft-ietf-rmt-flute-revised-01

[<[e-mail]>]

Hi Alfred

Thanks for the exhaustive comments! Almost all will be taken on as is, and I have made responses in-line below ("Yep" means "excellent point - thanks - we'll include that". "Yep" is so much easier to type :)

Also, thanks for using the structured and labelled comments and proposed text - that's made the job understanding and integrating your suggestions significantly easier.

Cheers, Rod.

PS Also CC'd to RMT so I don't have any complex synchronisation of comment discussions to perform!

PPS No normative changes are made so 01 is still ready for technical working group review but definitely 02 is now needed for nits and AD+IESG review.


>(1) Section 1, end of 'memo structure' paragraph (bottom of page 3)
>
>   [...]
>   delivery session.  The second appendix gives an example of File
>   Delivery Table.
>
>should better say:
>                                                             vvv
>|  delivery session.  The second appendix gives an example of a File
>   Delivery Table.

Yep. We should insert the word "Instance" after "Table" too.

>(2) Section 1.1.3., on page 5 says:
>
>   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)
>   [17].
>
>I would prefer to say:
>
>   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 Source-Specific Multicast 
>(SSM) [17].

Yep. And "or" -> "and"

>You also might consider the ID-s:
>  "Overview of the Internet Multicast Addressing Architecture",
>    <draft-ietf-mboned-addrarch-03.txt>,
>  "Source-Specific Multicast for IP",
>    <draft-ietf-ssm-arch-07.txt>,
>  "Using IGMPv3 and MLDv2 For Source-Specific Multicast",
>    <draft-holbrook-idmr-igmpv3-ssm-08.txt>,
>and the IGMPv3 and MLDv2 RFCs (RFC 3376 / RFC 3810) which 
>might be used as additional/alternative Informative References.

I'll open this one for wider discussion. (I have no strong opinion, but 2 weak opposing ones: I-D/work-in-progress references are to be avoided; the wider list of useful references for background the better).

>(3) Section 3, above the bulleted list on page 6, says:
>
>   As an example, let us consider a 5200 byte file referred to by
>   "http://www.example.com/docs/file.txt".  Using the example, the
>   following properties describe the properties that need to 
>be conveyed
>   by the file delivery protocol.
>
>The last sentence might well be shortened, avoiding word 
>replication and thus improving the readability, to:
>
>                                    [...].  Using the example, the
>|  following properties need to be conveyed by the file delivery
>   protocol.

Yep.

>(4) Section 3.1, on mid-page 7, states:
>
>   If the sender is not assigned a permanent IP address accessible to
>   receivers, but instead, packets that can be received by receivers
>   containing a temporary IP address for packets sent by the sender,
>   then the TSI is scoped by this temporary IP address of the 
>sender for
>   the duration of the session.  [...]
>
>It should better say:
>
>   If the sender is not assigned a permanent IP address accessible to
>   receivers, but instead, packets that can be received by receivers
>|  contain a temporary IP address for packets sent by the sender,
>   then ...
>
>or:
>
>   If the sender is not assigned a permanent IP address accessible to
>|  receivers, but instead, packets can be received by receivers
>   containing a temporary IP address for packets sent by the sender,
>   then ...
>
>or even:
>
>   If the sender is not assigned a permanent IP address accessible to
>|  receivers, but instead, packets arriving at the receivers carry a  
>| temporary (source) IP address assigned to the sender,
>   then ...

Yep - this last one without the brackets.

>(5) In Section 3.2:
>
>exchange:
>
>   Attributes related to the delivery of file:
>--
>|  Attributes related to the delivery of the file:
>
>and in the list below:

"the file" -> "a file" (soft form of "each file"), likewise the next line introducing the list wants this change.

>   Attributes related to the file itself:
>
>either
>       s/of file/of the file/    (5x)
>or
>       s/of file//               (5x)

I don't really understand. Also - see my previous comment.

>Finally, the last paragraph of section 3.2,
>
>   Since FDT database is an abstract concept, the structure and the
>   maintaining of the FDT database are left to individual
>   implementations and are thus out of scope of this specification.
>
>might better say:
>
>|  Since the FDT database is an abstract concept, the 
>structure and the  
>| maintaining of that database are left to individual implementations
>   and are thus out of scope of this specification.
>
>or:
>
>|  Since 'FDT database' is an abstract concept, the structure and the  
>| maintaining of that database are left to individual implementations
>   and are thus out of scope of this specification.

Good point - use this one:

   Since an FDT database is an abstract concept, its structure and 
   maintenance are left to individual
   implementations and are thus out of scope of this specification.

>(6) Section 3.3  [bulk update!  :-)]
>
>   *  An FDT Instance MAY appear in any part of the file delivery
>      session and packets for an FDT Instance MAY be interleaved with
>      packets for other files or other FDT Instances within a session.
>--               ^^^^^^^
>   *  An FDT Instance MAY appear in any part of the file delivery
>      session and packets for an FDT Instance MAY be interleaved with
>|     packets for files or other FDT Instances within a session.

Yep

>There is no context of file[s], hence no *other* files as well!
>
>Subsequently, exchange:
>
>   *  FDT Instance is identified by the use of a new fixed length LCT
>      Header Extension EXT_FDT (defined later in this section).  Each
>      FDT Instance is uniquely identified within the file delivery
>      session by its FDT Instance ID.  Any ALC/LCT packet carrying FDT
>      Instance (indicated by TOI = 0) MUST include EXT_FDT.
>--    vvvv
>|  *  The FDT Instance is identified by the use of a new fixed length
>      LCT Header Extension EXT_FDT (defined later in this section).
>      Each FDT Instance is uniquely identified within the file delivery
>|     session by its FDT Instance ID.  Any ALC/LCT packet carrying an
>      FDT Instance (indicated by TOI = 0) MUST include EXT_FDT.

Yep with first "The" -> "An"

>   *  It is RECOMMENDED that FDT Instance that contains the file
>      description entry for a file is sent prior to the sending of the
>      described file within a file delivery session.
>--                          vvvv
>   *  It is RECOMMENDED that an FDT Instance that contains the file
>      description entry for a file is sent prior to the sending of the
>      described file within a file delivery session.
>or perhaps even better:
>|  *  It is RECOMMENDED that, within a file delivery session, an FDT
>|     Instance that contains the file description entry for a file is
>|     sent prior to the described file.

Yep - the 2nd one

>   *  Within a file delivery session, any TOI > 0 MAY be described more
>      than once.  An example: previous FDT Instance 0 describes TOI of
>      value '3'.  Now, subsequent FDT Instances can either keep TOI '3'
>      unmodified on the table, not include it, or complement the
>      description.  However, subsequent FDT Instances MUST NOT change
>      the parameters already described for a specific TOI.
>--
>   *  Within a file delivery session, any TOI > 0 MAY be described more
>|     than once.  An example: A given FDT Instance describes a 
>TOI value
>|     of '3'.  Now, subsequent FDT Instances can either keep TOI '3'
>      unmodified on the table, not include it, or complement the
>      description.  However, subsequent FDT Instances MUST NOT change
>      the parameters already described for a specific TOI.

Yep

>'Instance 0' is unnecessarily concrete, given that the 
>subsequent instances are not specified (and need no being specified)!
>
>Finally, the block,
>
>   *  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) [5]
>      time value.  These 32 bits provide an unsigned integer
>      representing the time in seconds relative to 0 hours 1 January
>      1900.  [...]
>
>should be amended, correcting a sad legacy under-specification 
>in the NTP (and SNTP) RFCs, to say:
>
>   *  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) [5]
>      time value.  These 32 bits provide an unsigned integer
>|     representing the time in seconds relative to 0 hours UTC, 1 
>| January
>      1900.  [...]
>                                                          ^^^^^

Yep

>(7) Section 3.4 :
>
>The 1st paragraph,
>
>   FDT Instances are carried in ALC packets with TOI = 0 and with an
>   additional REQUIRED LCT Header extension called the FDT Instance
>   Header.  The FDT Instance Header (EXT_FDT) contains the FDT Instance
>   ID that uniquely identifies FDT Instances within a file delivery
>   session.  [...]
>
>should better say:
>
>   FDT Instances are carried in ALC packets with TOI = 0 and with an
>   additional REQUIRED LCT Header extension called the FDT Instance
>   Header.  The FDT Instance Header (EXT_FDT) contains the FDT Instance
>|  ID that uniquely identifies the FDT Instance within a file delivery
>   session.  [...]
>                              ^^^^^           ^^

Yep

>In the 2nd paragraph,
>
>      s/A FDT Instance/An FDT Instance/
>
>In Figure 1, a more pleasant and 'closed' appearance might be 
>achieved (still emphasizing the distinction between header and 
>variable length paylod) by changing
>
>   [...]
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       FEC Payload ID                          |
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                  FLUTE Payload: Encoding Symbol(s)
>   ~             (for FDT Instance in a FDT packet)                ~
>
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>to
>
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       FEC Payload ID                          |
>   |                                                               |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   :              FLUTE Payload: Encoding Symbol(s)                :
>   ~             (for FDT Instance in a FDT packet)                ~
>   :                                                               :
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Yep - I don't see why not :)

>Doing so might also help avoid a spurious page break insertion 
>during reformatting as an RFC  :-)
>
>
>(8) Section 3.4.1 :
>
>   FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI specific
>   LCT header extension [3].  The Header Extension Type (HET) for the
>   extension is 192.  Its format is defined below:
>-- vvvv
>|  The FDT Instance Header (EXT_FDT) is a new fixed length, ALC PI
>   specific LCT header extension [3].  The Header Extension Type (HET)
>|  for this extension is 192.  Its format is defined below:
>         ^^^

Yep

>and, below Figure 2,
>
>   Version of FLUTE (V), 4 bits:
>
>   This document specifies FLUTE version 1.  Hence in any ALC packet
>   that carries FDT Instance and that belongs to the file delivery
>   session as specified in this specification MUST set this field to
>   '1'.
>
>might better say:
>
>   Version of FLUTE (V), 4 bits:
>
>   This document specifies FLUTE version 1.  Hence in any ALC packet
>|  that carries an FDT Instance and that belongs to a file delivery
>   session ...
>               ^^^^                                ^^^

Yep

>In the last paragraph of the Section,
>
>         [...].  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.
>
>.... it might be considered to say
>    'Mandating receiver behavior ... is out of scope ...'
>instead, or even omit the 'Mandatory' entirely, just saying
>    'Receiver behavior for ...'.

Yep: "Mandatory receiver" -> "Receiver"

>(9) Section 3.4.2 :
>
>'"FDT-Instance"' is the XML term, plain text perhaps should 
>just say 'FDT Instance' (without enclosing double quotes) ; I 
>recommend to NOT use the hybrid '"FDT Instance"'.  Hence, the 
>second paragraph,
>
>   The FDT Instance is an XML structure that has a single root element
>   "FDT-Instance".  The "FDT-Instance" element MUST contain "Expires"
>   attribute, which tells the expiry time of the FDT Instance.  In
>   addition, the "FDT-Instance" element MAY contain the "Complete"
>   attribute (boolean), which, when TRUE, signals that this "FDT
>   Instance" includes the set of "File" entries that exhausts both the
>   set of files delivered so far and also the set of files to be
>   delivered in the session.  This implies that no new data will be
>   provided in future FDT Instances within this session (i.e., that
>   either FDT Instances with higher ID numbers will not be used or if
>   they are used, will only provide identical file parameters to those
>   already given in this and previous FDT Instances).  The "Complete"
>   attribute is therefore used to provide a complete list of 
>files in an
>   entire FLUTE session (a "complete FDT").
>
>should be modified to say:
>
>   The FDT Instance is an XML structure that has a single root element
>|  "FDT-Instance".  The "FDT-Instance" element MUST contain an 
>"Expires"
>   attribute, which tells the expiry time of the FDT Instance.  In
>   addition, the "FDT-Instance" element MAY contain the "Complete"
>|  attribute (boolean), which, when TRUE, signals that this 
>FDT Instance
>   includes the set of "File" entries that exhausts both the 
><further line reformating suppressed>
>   set of files delivered so far and also the set of files to be
>   delivered in the session.  This implies that no new data will be
>   provided in future FDT Instances within this session (i.e., that
>   either FDT Instances with higher ID numbers will not be used or if
>   they are used, will only provide identical file parameters to those
>   already given in this and previous FDT Instances).  The "Complete"
>|  attribute is therefore used to signal a complete list of files in an
>   entire FLUTE session (a "complete FDT").

Yep

>The latter correction accomodates the fact that it is not that 
>attribute that does not 'provide complete list', it just 
>indicates its presence.
>(You might use 'to indicate' as an substiture for 'to signal', 
>as well.)
>
>Subsequently, near the bottom of page 13,
>
>                                               [...].  Each entry is
>   represented by element "File" which is a child element of the FDT
>   Instance structure.
>--               vvvv
>                                               [...].  Each entry is
>|  represented by an element "File" which is a child element of the FDT
>   Instance structure.

Yep

>and in the paragraph spanning pages 13 and 14, I recommend to 
>adjust the terminology to the usual IMF and MIME terminology:
>
>   The attributes of "File" element in the XML structure represent the
>   attributes given to the file that is delivered in the file delivery
>   session.  The value of the XML attribute name corresponds to MIME
>   field name and the XML attribute value corresponds to the value of
>   the MIME field body.  Each "File" element MUST contain at least two
>   attributes "TOI" and "Content-Location".  "TOI" MUST be assigned a
>   valid TOI value as described in section 3.3 above.  "Content-
>   Location" MUST be assigned a valid URI as defined in [6].  The
>   semantics for any two "File" elements declaring the same "Content-
>   Location" but differing "TOI" is that the element appearing in the
>   FDT Instance with the greater FDT Instance ID is considered to
>   declare newer instance (e.g. version) of the same "File".
>--                  vvv
>|  The attributes of a "File" element in the XML structure 
>represent the
>   attributes given to the file that is delivered in the file delivery
>|  session.  The XML attribute name corresponds to the MIME 
>header field  
>| name and the XML attribute value corresponds to the value of 
>the MIME  
>| header field.  Each "File" element MUST contain at least two
>   attributes "TOI" and "Content-Location".  "TOI" MUST be assigned a
>   valid TOI value as described in section 3.3 above.  "Content-
>   Location" MUST be assigned a valid URI as defined in [6].  The
>   semantics for any two "File" elements declaring the same "Content-
>   Location" but differing "TOI" is that the element appearing in the
>   FDT Instance with the greater FDT Instance ID is considered to
>|  declare a newer instance (e.g. version) of the same "File".
>          ^^^

Yep - I'll recheck "MIME field body" and "MIME header field" definitions to make sure I know what I'm doing first :)

>In subsequent the bulleted paragraphs, I recommend to always
>
>      s/for the purpose as defined/for that purpose, as defined/

OK - see below...

>(Another, even more stringent re-wording for the full 
>sentences is proposed below.) Thus, the first two bulleted paragraphs,
>
>   *  Where the MIME type is described, the attribute "Content-Type"
>      MUST be used for the purpose as defined in [6].
>
>   *  Where the length is described, the attribute 
>"Content-Length" MUST
>      be used for the purpose as defined in [6].  The transfer 
>length is
>      defined to be the length of the object transported in bytes.  It
>      is often important to convey the transfer length to receivers,
>      because the source block structure needs to be known for the FEC
>      decoder to be applied to recover source blocks of the file, and
>      the transfer length is often needed to properly determine the
>      source block structure of the file.  [...]
>
>incorporating a significant text simplification, might better say:
>
>   *  Where the MIME type is described, the attribute "Content-Type"
>|     MUST be used for that purpose, as defined in [6].

OK - I'll do a poll on interpretations :)

>   *  Where the length is described, the attribute 
>"Content-Length" MUST
>|     be used for that purpose, as defined in [6].  The transfer length
>      is defined to be the length of the object transported in bytes.
>      It is often important to convey the transfer length to receivers,
>|     because the FEC decoder needs to know the source block structure
>|     to recover source blocks of the file, and to determine that, it
>|     often needs the transfer length.  [...]

Same poll on "purpose, as defined" :)

OK for 2nd change with "that," -> "this"

>The next two bulleted paragraphs,
>
>   *  Where the content encoding scheme is described, the attribute
>      "Content-Encoding" MUST be used for the purpose as 
>defined in [6].
>
>   *  Where the MD5 message digest is described, the attribute 
>"Content-
>      MD5" MUST be used for the purpose as defined in [6].
>
>become
>
>   *  Where the content encoding scheme is described, the attribute
>|     "Content-Encoding" MUST be used for that purpose, as defined in
>      [6].
>
>   *  Where the MD5 message digest is described, the attribute 
>"Content-
>|     MD5" MUST be used for that purpose, as defined in [6].
>
>Alternatively (as promised above), you might even consider to say:
>
>|  *  To describe the content encoding scheme, the attribute "Content-
>|     Encoding" MUST be used, as defined in [6].
>
>|  *  To describe the MD5 message digest, the attribute "Content-MD5"
>|     MUST be used, as defined in [6].

I don't like "the sound" of these changes - other opinions? (I'll come back to this in a few days and work out whether it's my "correct" or my "colloquial" English that is ringing the alarm bells)

>and apply similar changes to the two paragraphs above.
>
>On page 15, just above the XSD (Figure 3), the lines:
>
>   *  The FEC Object Transmission Information attributes as 
>described in
>      section 5.2.
>
>   The following specifies the XML Schema [7][8] for FDT Instance:
>
>migth be enhanced to say:
>                                                         vvv
>|  *  The FEC Object Transmission Information attributes are described
>      in section 5.2.

I'll read again later - initial though is that the original is better as it's in the context of a list ("the list thing, where it's elaborated" rather than "the list thing is elaborated"). In this sense the last sentence before this list could be changed thus:

"following are specifically pointed out." -> "following are specifically pointed out:" ("." -> ":")

>|  The following specifies the XML Schema [7][8] for the FDT Instance:
>                                                    ^^^^^

Rather "for FDT Instance" -> "for FDT Instances"

>Finally, on page 17 (below Figure 3), substitute
>
>   Any valid FDT Instance must use the above XML Schema.  This way FDT
>   provides extensibility to support private attributes within the file
>   description entries.  Those could be, for example, the attributes
>   related to the delivery of the file (timing, packet transmission
>   rate, etc.).
>--                                                                vvvv
>|  Any valid FDT Instance must use the above XML Schema.  This way the
>   FDT provides extensibility to support private attributes within the
>|  file description entries.  Those could be, for example, attributes
>   related to the delivery of the file (timing, packet transmission
>   rate, etc.).
>
>Note: '*the* attributes related to the delivery ...' would 
>purport that what follows is an exhaustive list of such 
>attributes -- which, in fact, it perhaps isn't.

Yep

This also reminds me of another comment we need to process: check the capitalisation of "MUST", "SHOULD", "MAY".

>(10) Section 3.4.3
>
>   The FDT Instance itself MAY be content encoded, for example
>   compressed.  This specification defines FDT Instance 
>Content Encoding
>   Header (EXT_CENC).  EXT_CENC is a new fixed length, ALC PI specific
>   LCT header extension [3].  The Header Extension Type (HET) for the
>   extension is 193.  If the FDT Instance is content encoded, the
>   EXT_CENC MUST be used to signal the content encoding type.  In that
>   case, EXT_CENC header extension MUST be used in all ALC packets
>   carrying the same FDT Instance ID.  Consequently, when EXT_CENC
>   header is used, it MUST be used together with a proper FDT Instance
>   Header (EXT_FDT).  [...]
>--
>   The FDT Instance itself MAY be content encoded, for example
>|  compressed.  This specification defines an FDT Instance Content
>   Encoding Header (EXT_CENC).  EXT_CENC is a new fixed length, ALC PI
>   specific LCT header extension [3].  The Header Extension Type (HET)
>|  for this extension is 193.  If the FDT Instance is content 
>encoded,  
>| an EXT_CENC MUST be used to signal the content encoding type.  In  
>| that case, an EXT_CENC header extension MUST be used in all ALC  
>| packets carrying the same FDT Instance ID.  Consequently, when an
>   EXT_CENC header is used, it MUST be used together with a proper FDT
>   Instance Header (EXT_FDT).  [...]

Yep with "an" -> "the" in the 2nd line (implies one SHOULD NOT define an alternative CENC HE"

However, I need to also recheck "Consequently, when an EXT_CENC header is used, it MUST be used together with a proper FDT Instance Header (EXT_FDT)." Out of context this says "never use EXT_CENC without EXT_FDT". Within FLUTE I think this is exactly what we meant - or more precisely "only use CENC HE for FDT Instances; use the FDT instances to signal file content encoding - thus use EXT_CENC as if it were part of EXT_FDT". Natually non-FLUTE usage would differ.

And to make matters worse, now we've shifted the generic blocking algoritm and the EXT_FTI, it also makes sense to shift the EXT_CENC spec to ALC or LCT since it is definitely not only useful for FLUTE. Anyother thing to come back to!

>(11) Section 3.5
>
>   The delivered files are carried as transport objects 
>(identified with
>   TOIs) in the file delivery session.  All these objects, 
>including the
>   FDT Instances, MAY be multiplexed in any order and in parallel with
>   each other within a session, i.e., packets for one file MAY be
>   interleaved with packets for other files or other FDT Instances
>   within a session.
>
>.... again talks about 'other FDT Instances' where there's no 
>basic one; hence, I recommend to say:
>
>   The delivered files are carried as transport objects 
>(identified with
>   TOIs) in the file delivery session.  All these objects, 
>including the
>   FDT Instances, MAY be multiplexed in any order and in parallel with
>   each other within a session, i.e., packets for one file MAY be
>|  interleaved with packets for other files or FDT Instances within a
>   session.

Yep

>(12) Section 5
>
>Bulk update of the first 3 paragraphs (spanning pages 19/20):
>
>   FLUTE inherits the use of FEC building block [4] from ALC.  When
>   using FLUTE for file delivery over ALC the FEC Object Transmission
>   Information MUST be delivered in-band within the file delivery
>   session.  There are two methods to achieve this: the use of ALC
>   specific LCT extension header EXT_FTI [3] and the use of FDT.  The
>   latter method is specified in this section.
>--
>|  FLUTE inherits the use of the FEC building block [4] from ALC.  When
>   using FLUTE for file delivery over ALC the FEC Object Transmission
>   Information MUST be delivered in-band within the file delivery
>|  session.  There are two methods to achieve this: the use of 
>the ALC  
>| specific LCT extension header EXT_FTI [3] and the use of the FDT.
>   The latter method is specified in this section.

Yep

>   The receiver of file delivery session MUST support delivery of FEC
>   Object Transmission Information using the EXT_FTI for the FDT
>   Instances carried using TOI value 0.  For the TOI values 
>other than 0
>   the receiver MUST support both methods: the use of EXT_FTI and the
>   use of FDT.
>--
>|  The receiver of the file delivery session MUST support delivery of
>   FEC Object Transmission Information using the EXT_FTI for the FDT
>   Instances carried using TOI value 0.  For the TOI values 
>other than 0
>   the receiver MUST support both methods: the use of EXT_FTI and the
>|  use of the FDT.

Yep - "use of the EXT_FTI and of the FDT" would be best.

>   The FEC Object Transmission Information that needs to be 
>delivered to
>   receivers MUST be exactly the same whether it is delivered using
>   EXT_FTI or using FDT (or both).  The FEC Object Transmission
>   Information that MUST be delivered to receivers is defined 
>by the FEC
>   Scheme.  This section describes the delivery using FDT.
>--
>   The FEC Object Transmission Information that needs to be 
>delivered to
>|  receivers MUST be exactly the same whether it is delivered 
>using an  
>| EXT_FTI or using the FDT (or both).  The FEC Object Transmission
>   Information that MUST be delivered to receivers is defined 
>by the FEC
>|  Scheme.  This section describes the delivery using the FDT.

Yep

>The 4th bulleted paragraph on page 20,
>
>   *  "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent
>      with the field "Maximum Source Block Length" of EXT_FTI for FEC
>      Encoding IDs 0, 128 and 130, and semantically equivalent with the
>      field "Maximum Source Block Length" of EXT_FTI for FEC 
>Encoding ID
>      129.
>
>restates the same fact for 'FEC Encoding IDs 0, 128 and 130' 
>and once again, using identical words, for 'FEC Encoding ID 129'.
>A unified approach to tell that all is much shorter:
>
>   *  "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent
>|     with the field "Maximum Source Block Length" of the 
>EXT_FTI for FEC
>|     Encoding IDs 0, 128, 129, and 130.

Just to ensure the difference between 129 (16 bit) and the others (32 bit) is not overlooked:

   *  "FEC-OTI-Maximum-Source-Block-Length" is semantically equivalent to the each EXT_FTI "Maximum Source Block Length" field defition for FEC Encoding IDs 0, 128, 129, and 130.

>(13) Section 6
>
>The three bulleted items (the first one on p. 21, the latter on p. 22),
>
>   *  FEC Encoding ID and FEC Instance ID when the default FEC Encoding
>      ID 0 is not used for the delivery of FDT;
>
>   *  Content Encoding format if optional content encoding of FDT
>      Instance is used, e.g., compression;
>
>   *  Some information that tells receiver, in the first 
>place, that the
>      session contains files that are of interest.
>
>should be improved to say:
>
>   *  FEC Encoding ID and FEC Instance ID, when the default 
>FEC Encoding
>|     ID 0 is not used for the delivery of FDTs;
>
>|  *  Content Encoding format, if optional content encoding of the FDT
>      Instance is used, e.g., compression;
>
>|  *  Some information that tells the receiver, in the first 
>place, that
>      the session contains files that are of interest.

Yep

>(14) Section 7
>
>.... begins stating:
>
>   The security considerations that apply to, and are described in, ALC
>   [2], LCT [3] and FEC [4] also apply to FLUTE.  [...]
>
>RFC-Ed policy requires, and some other recommendations as well, to say:
>
>   The security considerations that apply to, and are described in, ALC
>|  [2], LCT [3], and FEC [4] also apply to FLUTE.  [...]
>               ^

Yep

>The 3rd paragraph on page 23 refers to TESLA using ref. [16].
>You might consider introducing references to RFC 4082 and RFC 
>4383 as well.

Another one to open up for discussion

>The 3rd paragraph on page 24 says:
>
>   A receiver with an incorrect or corrupted implementation of the
>   multiple rate congestion control building block may affect health of
>   the network in the path between the sender and the receiver, and may
>   also affect the reception rates of other receivers joined to the
>   session.  [...]
>
>It might better say:
>
>   A receiver with an incorrect or corrupted implementation of the
>|  multiple rate congestion control building block may affect 
>the health
>   of the network in the path between the sender and the receiver, and
>   may also affect the reception rates of other receivers joined to the
>   session.  [...]

Yep

>(15) Section 9
>
>Cf. item (9) above!
>Therefore,
>
>   1. Registration Request for XML Schema of FDT Instance
>      (urn:ietf:params:xml:schema:fdt).
>--
>|  1. Registration Request for the XML Schema "FDT-Instance"
>      (urn:ietf:params:xml:schema:fdt).

Yep

>and
>
>8.1.  Registration Request for XML Schema of FDT Instance
>--
>8.1.  Registration Request for XML Schema FDT-Instance

Yep

>   Document [25] defines an IANA maintained registry of XML documents
>   used within IETF protocols.  The following is the registration
>   request for the FDT XML schema.
>--
>   Document [25] defines an IANA maintained registry of XML documents
>   used within IETF protocols.  The following is the registration
>|  request for the FDT-Instance XML schema.
>
>.... but see below! ...
>
>   URI: urn:ietf:params:xml:schema:fdt
>
>   Registrant Contact: Toni Paila (toni.paila (at) nokia.com)
>
>   XML: The XML Schema specified in Section 3.4.2
>
>Such wording is perfect within the full context of the [to-be-]RFC.
>But please consider: The IANA will have to extract the 
>registration and put it into the registry.  You make it 
>necessary that it edits the text to make it comprehensible and 
>selfconsistent. If that is not done, or not done properly, 
>you'll get a silly result in the registry (look for examples 
>-- there are incountable many!) Thus, if you want to have 
>better / almost full control over the final text in the IANA 
>registry, offload the IANA, avoid editing errors, and save 
>readers of badly comprehensible registrations, please use 
>wording that -- after RFC-Ed processing -- does not need to be 
>changed any more by the IANA, and yet is complete and well 
>understandable in the standalone context of the registry!
>
>Long said, short done:  Use, e.g.,
>
>   XML: The XML Schema specified in Section 3.4.2 of RFC xxxx 
>[Note to RFC Editor:
> Please substitute RFC number for 'xxxx' when assigned!]
>
>For the same reason,  "Document [25] defines ..."  makes no 
>more sense when the registration template becomes extracted 
>from the RFC.
>Preferably, it should say, "RFC 3688 [25] defines ..." That 
>remains comprehensible after extraction of the registration template.
>
>Various parts of sections 8.2 .. 8.3.1 should be reworked with 
>the above explanation in mind.

Yep - will need a little more editting (note to myslef for ticking the todo boxes :)

>(16) Section 11
>
>On page 28:
>
>   Section 5 is modified so that EXT_FTI and the FEC issues 
>are replaced
>   by a reference to LCT specification.  We count on revised LCT
>   specification to specify the EXT_FTI.
>--
>   Section 5 is modified so that EXT_FTI and the FEC issues 
>are replaced
>   by a reference to the LCT specification.  We count on a revised LCT
>   specification to specify the EXT_FTI.

Yep (I can see it even without the "|" :)

>and:
>   Reworked Section 8 - IANA Considerations.  Now it contains 
>three IANA
>   registration requests:
>
>   *  Registration Request for XML Schema of FDT Instance
>      (urn:ietf:params:xml:schema:fdt)
>--
>   *  Registration Request for XML Schema "FDT-Instance"
>      (urn:ietf:params:xml:schema:fdt)

Yep

>(17) Section 12.2
>
>[20], RFC 2633, since a long time has been obsoleted by RFC 3851.
>
>[22], RFC 2048, has recently been obsoleted as well; it has 
>been replaced by a set of two RFCs; RFC 4288 is the proper one 
>that should be referenced.
>Unfortunately, the BCP index, rfcxx00.txt, and other RFC 
>metadata files got confused by such an 'overlay' of two RFCs 
>for a single BCP, and the current entries are really ugly!

Will check. (As far as I remember we intentionally included [23] as useful text is missing from the documents that obsolete it, but no other obsoleted references should be in there)

>(18)  Appendix A
>
>   6. If the recovered object was an FDT Instance with FDT Instance ID
>      'N', the receiver parses the payload of the instance 'N' of FDT
>      and updates its FDT database accordingly.  The receiver 
>identifies
>      FDT Instances within a file delivery session by the 
>EXT_FDT header
>      extension.  Any object that is delivered using EXT_FDT header
>      extension is an FDT Instance, uniquely identified by the FDT
>      Instance ID.  Note that TOI '0' is exclusively reserved for FDT
>      delivery.
>--
>   6. If the recovered object was an FDT Instance with FDT Instance ID
>|     'N', the receiver parses the payload of the FDT instance 'N' and
>      updates its FDT database accordingly.  The receiver 
>identifies FDT
>      Instances within a file delivery session by the EXT_FDT header
>|     extension.  Any object that is delivered using an EXT_FDT header
>      extension is an FDT Instance, uniquely identified by the FDT
>      Instance ID.  Note that TOI '0' is exclusively reserved for FDT
>      delivery.

Yep - also "FDT instance" -> "FDT Instance"

>   7. If the object recovered is not an FDT Instance but a file, the
>      receiver looks up its FDT database to get the properties 
>described
>      in the database, and assigns file with the given properties.  The
>      receiver also checks that received content length 
>matches with the
>      description in the database.  Optionally, if MD5 
>checksum has been
>      used, the receiver checks that calculated MD5 matches with the
>      description in the FDT database.
>--
>   7. If the object recovered is not an FDT Instance but a file, the
>      receiver looks up its FDT database to get the properties 
>described
>|     in the database, and assigns the file with the given properties.
>|     The receiver also checks that the received content's 
>length matches
>|     the description in the database.  Optionally, if an MD5 checksum
>|     has been used, the receiver checks that calculated MD5 
>matches the
>|     description in the FDT database.

Yep - "received content's length" -> "length of the received content" (I'm being pedantic about avoiding "'" in formal text if easy :)

>(19)  --- general concern ---  (without any hope of change)
>
>It's a pity that new specifications still make use of the aged MD5.
>The cryptographical deficiencies are well known, and the NIST 
>even has begun to phase out SHA-1 right now!
>
>Arguably, the full cryptographic strength is not strictly 
>required in this context, but there is at least one strong, 
>related argument:
>
>New applications of MD5 will cause keeping that code in 
>libraries and - because implemented - being offered as an 
>option for where it should better not be used any more, 
>increasing the probability that too weak cryptography will be 
>used over and over again!

Well we recognised some of this and actual support for MD5 is opntional (only recignising the field in the FDT Instance is mandatory). The schema is extensible making it easy to add an alternative and even depreciate use fo MD5 (removing it from the schema would be backwards compatible too). If you have a simple alternitiev that's preferably alrady mature, with mutiple open source implemenattions and isn't IPR encombered, please suggest it to RMT!!! (Then the authors will have their own debate and maybe there's hope).


(again) Thanks for the exhaustive editorial review! Cheers, Rod.

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