[Rmt] AD review of draft-ietf-rmt-bb-lct-revised-07

[Magnus Westerlund <[e-mail]>]

I have reviewed the LCT builidng block and have the following comment.

1. Section 3, page 7: "Some possible
   multiple rate congestion control protocols are described in
   [VIC1998], [BYE2000], and [LUB2002].  A possible single rate
   congestion control protocol is described in [RIZ2000]."

To my knowledge WEBRC (RFC 3738) is the only actually standardized (as
experimental) that is suitable for the scalability LCT is intended for.
Can we please include a reference and indicate that this actually is the
currently recommended. References to any other potential solution is okay.

2. Section 4.1, page 11:
"the Source-
   Specific Multicast (SSM) model as defined in [HOL2001]."

RFC 4607 is available and specifies SSM. Isn't that a more suitable
reference?

3. Section 4.3:
Also here I think the references and discussion should be updated to
what is actually available.

4. You clearly forgotten to check the ID-nits on this document:
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rmt-bb-lct-revised-07.txt

Then you would have seen that you have references to 3 obsoleted RFCs:
RFC 1889, RFC 2327, and RFC 2423.

It also indicates that you are missing the actual entry in the reference
section for RFC 1305.

5. Section 5.2.1:
"   All senders and receivers implementing LCT MUST support the EXT_NOP
   Header Extension and MUST recognize EXT_AUTH and EXT_TIME, but MAY
   NOT be able to parse their content."

MAY NOT is not defined in RFC 2119. Please rephrase.

6. Section 5.2.2:

"     When the SCT-Low flag is set, the associated 32 bit time value
      provides an unsigned integer representing a multiple of 1/2^^32 of
      a second, in order to allow sub-second precision.  When the SCT-
      Low flag is set, the SCT-High flag MUST be set too.  In the
      particular case where NTP is used, these 32 bits provide the 32
      least significant bits of a 64 bit NTP timestamp."

I found the above text a bit confusing about when including SCT-LOW. It
says that also SCT-HIGH must be set. I didn't get that means multiple
32-bit entries until reading at the end. Maybe the following text should
be moved earlier in the section?

"  Several "time value" fields MAY be present in a given EXT_TIME Header
   Extension, as specified in the "Use-field".  When several "time
   value" fields are present, they MUST appear in the order specified by
   the associated flag position in the "Use-field": first SCT-High (if
   present), then SCT-Low (if present), then ERT (if present), then SLC
   (if present).  Receivers SHOULD ignore additional fields within the
   EXT_TIME Header Extension which they do not support."

7. Section 6.1:

"  The session description could be in a form such as SDP as defined in
   [RFC2327], or XML metadata as defined in [RFC3023], or HTTP/Mime
   headers as defined in [RFC2616], etc."

Aren't there more concreate examples of XML formats for this usage then
referencing RFC 3023?

8. Section 7, and possible in other places as well. This document talks
about authentication mechanism as very needed. But you haven't included
any references to the ones we actually have been discussing or even
developed for usage with RMT. I think some up to date references here
would be good. Maybe even recommendations?

9. Section 8.

Please update the reference to TESLA to the TESLA based mechanism for RMT.

10. Section 9.1:
In RFC 5226 that obsoletes RFC 2434 the IETF consensus policy does not
exist, instead the corresponding one is IETF Review.

When submitting an updated draft, please remember RFC 5378 and the
issues with it.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
Rmt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rmt