Re: GenART LC review of draft-ietf-rmt-fcast-07

[Vincent Roca <vincent.roca@xxxxxxxx>]

Dear Roni,

Thanks a lot for your comments. Here are my answers.

Document: draft-ietf-rmt-fcast-07

Reviewer: Roni Even

Review Date:2013–1–15

IETF LC End Date: 2013-1–22

IESG Telechat date:

 

Summary: This draft is almost ready for publication as Standard track RFC.

 

 

Major issues:

 

Minor issues:

 

1.       I had some problem when reading the document about what is mandatory to support. The distinction between what is  required to be  supported and used is mentioned in section 5. Also section 3.3 discusses what compliant implementation is, but section 5 provides the full information. I think that it will be better to move section 5 before or at the beginning of section 3 or as part of  3.3.  no need to have the information twice.

I agree. The new 3.3 section now explains the concepts, and the "mandatory to implement" things are moved to

the "Requirements for Compliant Implementations" section.

This "compliant implementations" section is moved at the end of section 3 as suggested by Joseph Yee.

The new ToC is therefore:

   2.  FCAST Data Formats

   3.  FCAST Principles
   4.  Requirements for Compliant Implementations

2.       In section 3.3 “The support of GZIP encoding, or any other solution, remains optional.” I think that support is mandatory.

You're right and there is also some confusion here between the GZIP use in MDEnc, and the GZIP use in

Content-Encoding. It makes no sense to say GZIP is mandatory in MDEnc, and optional in Content-Encoding.

This is now clarified in the "compliant implementations" section.

NEW item in "compliant implementations" section:

   | Content-Encoding       | MUST be supported.  All FCAST            |

   |                        | implementations MUST support GZIP        |

   |                        | encoding [RFC1952]                       |

Additionally, I've moved text from Section 2.2 about Content-Length and

Content-Encoding (that includes lengthy discussion on GZIP usage)

to Section 3.3. There's now a single place to explain concepts with all

the details.

OLD item in 2.2:

   o  Content-Encoding: it specifies the optional encoding of the object

      list, performed by FCAST.  For instance:

           Content-Encoding: gzip

      indicates that the Object List field has been encoded with GZIP

      [RFC1952].  If there is no Content-Encoding entry, the receiver

      MUST assume that the Object List field is plain text (default).

      The support of GZIP encoding, in addition to the plain text form,

      is REQUIRED.  The Content-Encoding entry MAY be used to indicate

      other encoding types to support non-standard FCAST implementation

      or future extended specifications.

NEW item in 2.2:

   o  Content-Encoding: it specifies the optional encoding of the object

      list, performed by FCAST.

OLD item in 3.3:

   o  Content-Encoding: a string that contains the optional encoding of

      the object performed by FCAST.  If there is no Content-Encoding

      entry, the receiver MUST assume that the object is not encoded

      (default).  The support of GZIP encoding, or any other solution,

      remains optional.

NEW item in 3.3:

   o  Content-Encoding: a string that contains the optional encoding of

      the object performed by FCAST.  For instance:

           Content-Encoding: gzip

      indicates that the Object List field has been encoded with GZIP

      [RFC1952].  If there is no Content-Encoding entry, the receiver

      MUST assume that FCAST did not perform any encoding to the object

      (default).

While doing that I realized that the Fcast-CID-Complete and Fcast-CID-ID

were not mentioned at all in the "compliant implementations" section. This

is now corrected as follows:

NEW item in "compliant implementations" section:

   CID-specific Meta-data items (Section 2.2):

       +-----------------------+-------------------+

       | Feature               | Status            |

       +-----------------------+-------------------+

       | Fcast-CID-Complete    | MUST be supported |

       | Fcast-CID-ID          | MUST be supported |

       +-----------------------+-------------------+

 Nits/editorial comments:

The following 4 comments have been resolved.

1. In section 5.1 at the end of first table “in-bound” should be “in-band”
2. In section 6 in the paragraph after the bullet points “possibly possibly”
3. In section 7 “This specification requires IANA to create two new registries” I think there are three new registries.
4. In section 7.1 second paragraph “registry registry”

Thanks a lot for your comments.

Cheers,

   Vincent