Subject: [Rmt] Changes made in FEC BB 07 and FEC INFO 03

From: "Michael Luby" <[email-masked]>
Date: Mon, 16 Sep 2002 08:41:19 -0700

RMTers,
Here are the list of changes in the revised I-Ds FEC BB 07 and FEC INFO 03
that was just posted and announced to the RMT working group mailing list.

I've taken into account all of Allison Mankin's comments
(included below with what actions were taken).
Mike

----------------------------------------------------------------------------
Allison's comments and my comments on actions taken (my comments start with
***)
----------------------------------------------------------------------------

--------------------
info-fec:
--------------------

Abstract:

New rules means too short and can't use FEC
*** Rewrote all abstracts of all drafts to make more informative and give
the scale of what is contained in each document, removed all references and
abbreviations in all abstracts for all drafts.

Use informational boilerplate
*** Will do this when the informational RFC submission is made.

Fix ipr words, otherwise looks fine
*** Added IPR statement as specified in RFC 2026 sec 10.4(D) to FEC INFO and
FEC BB

--------------------
bb-fec:
--------------------

Abstract

Rewrite so it gives title of companion doc (no references
allowed) and doesn't say "(FEC)" and FEC - new style rules for
abstracts.
*** Rewrote all abstracts of all drafts to make more informative and give
the scale of what is contained in each document, removed all references and
abbreviations in all abstracts for all drafts.

Points like the ones below probably mean you need to define how you
are using the term "format"

- -  Below mis-written?  It reads as if the Payload ID has a format,
   other than the number.
*** FEC Payload ID does have a format, it is generally composed of several
fields, and the fields and their formats is one of the things that one needs
to define when specifying a new FEC Encoding ID.  The FEC Payload ID is in
every packet that contains encoding symbols (FEC data).  This is made much
more explicit in the document, and forward references to Sec. 5 where this
is all laid out are made, and an example is given.

     These documents MUST also specify a format for the FEC Payload ID and

- - What does this mean?

         An already reserved FEC
    Encoding ID value MUST be reused if it is associated with the same
    format of FEC Payload ID

*** This was rewritten and clarified a bit.  What it means is that if you
use a new FEC codec and there is an existing FEC Encoding ID such that its
associated FEC Payload ID uses the same fields with the same lengths then
the new FEC coded must use the same FEC Encoding ID.  This is to force
sharing of FEC Encoding IDs for Under-Specified FEC schemes, i.e., all those
that use the same fields and lengths in their FEC Payload ID should use the
same FEC Encoding ID, but different FEC Instance IDs.

Security Considerations

- - Below is both not specific about the risk and not specific about
  the solution at the same time:

   Thus, it
   is RECOMMENDED that the receiver authenticate the session description,
   for example by using either the ESP (with enabled authentication
   service) [5] or AH [4] protocols of IPSEC [3] to ensure the authenticity
   of the session description.

 Since how the session description is conveyed is out of scope, who
 knows if IPsec is the right way to avoid tampering with it or how you
 would use IPsec for the purpose?  It should be written with at a
 different pitch, something like:

   It is RECOMMENDED that the receiver arrange to avoid tampering
   with the session description by arranging for receiving it with
   strong assurance of source authentication and, especially,
   data integrity, so that the FEC information is not destroyed
   and the data rendered useless.
*** The language about the risks in all the drafts in the Security section
was updated on the issue of an incorrect session description being accepted
by the receiver.  The risks are slightly different for FEC BB then say for
ALC PI, i.e., the risks for FEC BB are essentially accepting corrupted data,
but for ALC PI and LCT BB it is this and also potentially network
disruption.  More generic language about how to overcome these risks of
accepting an invalid session description was adopted in all drafts similar
to what is recommended above, removing mention of ESP, AH and IPSEC.

IANA Considerations

- - Write it more specifically as instructions:

    Ask IANA to establish onr (or two?) new registry, the
    RMT FEC Encoding ID and RMT FEC Encoding Name (is it
    sub-registry of part of the ID registry?)
*** This was significantly expanded and made more concrete and specific,
thanks in large part to Lorenzo.
Section 8.1 was specifically added to address this, adopting some of the
conventions of allocating name-space by IANA as specified in other RFCs.

- - Why is the Name called a Name if it is a numeric
  index?  What is the actual set of fields that will be
  in an ID registry line?  What in the Name line?  128 and
  129 are registered by this draft, but is any Name registered,
  or that will happen later by the FCFS?
*** FEC Encoding Name was changed to FEC Instance ID (because it is an ID,
not a name), and thus the FEC Encoding ID completely specifies a
Fully-Specified FEC scheme whereas FEC Encoding ID and FEC Instance ID
completely specify an Under-Specified FEC scheme.

Refs

What about citing RFC 3269? -- in introduction say conforms to:
*** At the end of all drafts except the FEC INFO draft a sentence was added
that says that the drafts follows the general guidelines described in
RFC 3269 "Author Guidelines for Reliable Multicast Transport (RMT) Building
Blocks and Protocol Instantiation documents"

Boilerplate

Does this one need the 2026 10.4(d) too?2
*** Added IPR statement as specified in RFC 2026 sec 10.4(D) to FEC INFO and
FEC BB

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