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

[Mark Watson <[e-mail]>]

Magnus, all,

Regarding the Security Considerations and your comment on Section 7, I have
some questions for the group:

1) should we just update the text here in LCT to align with ALC ? Or, in
fact, should that text be in only one of the documents with a reference from
the other ?

In the latter case, the text should probably be in LCT with a reference from
ALC. If there is anything truly ALC-specific it can stay in ALC.

2) Regarding the TESLA in RMT work, I understand this is a draft right now.
Do we need a reference from ALC/LCT to that ?

3) The work in MSEC is called TESLA for ALC and NORM: is it specific to ALC
or would it apply equally to anything built on LCT ?

I propose to address the remaining comments as noted inline below.

...Mark




On 1/23/09 6:59 AM, "Magnus Westerlund" <[e-mail]>
wrote:

> Hi,
> 
> 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.

Ok.

> 
> 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?

Yes.

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

Ok.

> 
> 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-lc
> t-revised-07.txt
> 
> Then you would have seen that you have references to 3 obsoleted RFCs:
> RFC 1889, RFC 2327, and RFC 2423.

I don't think these were nits when the document was submitted ;-) I'll
address them.

> 
> 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.
> 

ok: "...but are not required to be able to parse their content."

> 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."
>

Ok, I'll move that para to immediately below the figure.

> 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?

In due course there may be a DVB specification which includes this
information in the DVB XML metadata, but I don't think that is available
yet. I agree that arbitrarily referencing generic data format specifications
has little value, though. So I propose to change this text to:

"The session description could be in a form such as SDP as defined in
RFC4566, or another format appropriate to a particular application"


> 
> 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.
> 

See above.

> 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.
> 

Ok.

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

I believe the bleeding-edge version of xml2rfc will take care of this for
me.

> 
> 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]
> ----------------------------------------------------------------------