Subject: [Gen-art] Gen-ART review of draft-ietf-fecframe-simple-rs-04

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 17 Oct 2012 16:21:29 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Please resolve these comments along with any other comments you may receive.

Document: draft-ietf-fecframe-simple-rs-04
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2012-10-17
IETF LC End Date: 2012-10-22

Summary: The document is ready for publication as a standards track RFC, 
but has some Nits that should be addressed.

Major issues: none

Minor issues: none

Nits/editorial comments:

- Section 5.1.1 starts with this sentence:

    The FEC Framework Configuration Information (or FFCI) includes
    information that MUST be communicated between the sender and
    receiver(s).

This is not a normative "MUST" that you are specifying. You are merely 
describing how another specification has a normative MUST, but it is not 
of this document. Therefore, this "MUST" should be replaced by a "need" 
or perhaps a "must".

- Section 5.1.1.1 reads:

    When SDP is used to communicate the FFCI, this FEC Encoding ID is
    carried in the 'encoding-id' parameter.

Two points here:
a) I am missing a normative MUST, such as "this FEC Encoding ID MUST be 
carried..."
b) I guess it would not be such a bad idea to complete the sentence with 
the attribute name in SDP and normative reference that defines the 
attribute and the parameter.

Proposal:

    When SDP is used to communicate the FFCI, this FEC Encoding ID MUST be
    carried in the 'encoding-id' parameter of the  'fec-repair-flow'
    attribute specified in RFC 6364 [RFC6364].

- Similarly in Section 5.1.1.2:

If you agree with this changes, you should do similar changes to Section 
5.1.1.2, the text beginning with "When SDP is used..." Notice also that 
the example following this text in Section 5.1.1.2 is misleading because 
it does not contain a single SDP line, which is generally considered the 
atomic representation element in examples, but just a fraction of it. I 
suggest to extend the example to the full a=fec-repair-flow line.

- Section 8, IANA. Isn't the name of the registry "Reliable Multicast 
Transport (RMT) FEC Encoding IDs and FEC Instance IDs"? Or am I looking 
at the wrong registry? I think that the "FEC Framework (FECFRAME) FEC 
Encoding IDs is one of the registries included under that umbrella of RMT 
FEC Encoding IDs. As a reader, I would like to be able to find the right 
registry without doubt.

/Miguel
-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Vincent Roca <[email-masked]>
Date: Mon, 22 Oct 2012 16:58:24 +0200

Dear Miguel,

Thanks a lot for your comments.

> Summary: The document is ready for publication as a standards track RFC, but has some Nits that should be addressed.
> 
> Major issues: none
> 
> Minor issues: none
> 
> Nits/editorial comments:
> 
> This is not a normative "MUST" that you are specifying. You are merely describing how another specification has a normative MUST, but it is not of this document. Therefore, this "MUST" should be replaced by a "need" or perhaps a "must".

I understand. Done.

NEW:
   The FEC Framework Configuration Information (or FFCI) includes
   information that must be communicated between the sender and
   receiver(s) [RFC6363].

> a) I am missing a normative MUST, such as "this FEC Encoding ID MUST be carried..."
> b) I guess it would not be such a bad idea to complete the sentence with the attribute name in SDP and normative reference that defines the attribute and the parameter.
> 
> Proposal:
> 

Excellent. This paragraph now reads:

NEW:
   When SDP is used to communicate the FFCI, this FEC Encoding ID MUST
   be carried in the 'encoding-id' parameter of the 'fec-repair-flow'
   attribute specified in RFC 6364 [RFC6364].

> If you agree with this changes, you should do similar changes to Section 5.1.1.2, the text beginning with "When SDP is used..." Notice also that the example following this text in Section 5.1.1.2 is misleading because it does not contain a single SDP line, which is generally considered the atomic representation element in examples, but just a fraction of it. I suggest to extend the example to the full a=fec-repair-flow line.

Done. And the associated example also illustrates the use of encoding-id=...

NEW:
   When SDP is used to communicate the FFCI, this FEC scheme-specific 
   information MUST be carried in the 'fssi' parameter of the 'fec-
   repair-flow' attribute, in textual representation as specified in RFC
   6364 [RFC6364].  For instance:
    
   a=fec-repair-flow: encoding-id=XXX; fssi=E:1400,S:0,m:8 

> - Section 8, IANA. Isn't the name of the registry "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs"? Or am I looking at the wrong registry? I think that the "FEC Framework (FECFRAME) FEC Encoding IDs is one of the registries included under that umbrella of RMT FEC Encoding IDs. As a reader, I would like to be able to find the right registry without doubt.

Yes, it is one of the registries of the "Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance IDs" registry.
It's a bit complex (well, historical in fact). I have clarified.

NEW:
   Values of FEC Encoding IDs are subject to IANA registration.
   [RFC6363] defines general guidelines on IANA considerations.  In
   particular it defines the "FEC Framework (FECFRAME) FEC Encoding IDs"
   subregistry of the "Reliable Multicast Transport (RMT) FEC Encoding
   IDs and FEC Instance IDs" registry, whose values are granted on an
   IETF Consensus basis.

Thanks a lot.
Cheers,

    Vincent, on behalf of the authors

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 23 Oct 2012 07:45:48 +0200

Excellent. All agreed.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain