Excellent. All agreed.
/Miguel
On 22/10/2012 16:58, Vincent Roca wrote:
Dear Miguel,
Thanks a lot for your comments.
Document: draft-ietf-fecframe-simple-rs-04
Reviewer: Miguel Garcia <[email protected]>
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".
I understand. Done.
NEW:
The FEC Framework Configuration Information (or FFCI) includes
information that must be communicated between the sender and
receiver(s) [RFC6363].
- 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].
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].
- 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.
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
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
