[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Rmt] AD evaluation comments on draft-ietf-rmt-flute-revised-06
Hi,
I have reviewed the Flute spec and have some comments:
1. There are ID nits on the doc:
== Outdated reference: A later version (-06) exists of
draft-ietf-rmt-pi-alc-revised-03
== Outdated reference: A later version (-09) exists of
draft-ietf-rmt-bb-lct-revised-04
== Outdated reference: draft-ietf-rmt-fec-bb-revised has been published as
RFC 5052
-- Possible downref: Non-RFC (?) normative reference: ref. '7'
-- Possible downref: Non-RFC (?) normative reference: ref. '8'
** Obsolete normative reference: RFC 2279 (ref. '10') (Obsoleted by RFC
3629)
** Obsolete normative reference: RFC 2434 (ref. '11') (Obsoleted by RFC
5226)
-- Obsolete informational reference (is this intentional?): RFC 2327 (ref.
'14') (Obsoleted by RFC 4566)
-- Obsolete informational reference (is this intentional?): RFC 2633 (ref.
'19') (Obsoleted by RFC 3851)
-- Obsolete informational reference (is this intentional?): RFC 2048 (ref.
'21') (Obsoleted by RFC 4288, RFC 4289)
Use the check on the tools page to verify before submission that there
are no ones. The submission check covers only parts of all the nits.
2. I have basically the same comment on this document as on ALC PI about
mandatory to implement security solutions.
3. The document header, the abstract and the introduction needs to say
that this document will obsolete RFC 3926.
4. Section 1. As the ALC PI isn't suitable for general deployment using
unicast, flute can't really either. The congestion control is the issue.
5. Section 3.3, there is a reference to the NTP time format. NTP v4 has
been to IESG but are not approved yet. Are there a point of actually
referencing the clarified formats in that doc? That also have a
clarified discussion about epochs that helps handling the wrap around.
6. Section 3.4.1:
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.
Why isn't this specified. Seem to be important for interoperable usage.
Seems to be a fine thing to gloss over in an experimental, but not in a
proposed standard.
7. Section 3.4.2:
Why is only HTTP URLs valid in the location header? In addition why was
HTTP URLs used? There is after all an explicit transport mechanism
implied by that. Some clarification on that relation would be good.
8. section 3.4.3:
Shouldn't the reserve bits be ignore on reception also?
9. Section 4, page 20, bullet 2:
Missing reference to FEC encoding id 0.
10. Section 6:
Shouldn't this text discuss the need for configuring the congestion
control mechanism also? The security parameters needs discussion also.
11. Section 8.2: Chairs, have the update of the media type registrations
been reviewed on the ietf-types list?
12. Section 8.2: The template hasn't been updated. The change controller
is a split item and should be saying "IETF".
13. Section 8.3.1: It seems to be some confusion about the usage of URN
for purpose of describing where the name spaces are. I think this needs
to be clarified. Can the authors and the chairs please try to resolve
this with the IANA?
14. Section 12.2:
Are really reference 17 and 18 informative. You are binding them for a
particular usage.
Conclusion: A number of issues needs resolving. I am expecting a revised ID.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund at ericsson.com
----------------------------------------------------------------------