Subject: Re: [Rmt] AD review of draft-ietf-rmt-bb-lct-revised-07
From: Mark Watson <[email-masked]>
To: Magnus Westerlund <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 09 Feb 2009 16:26:52 -0800
List-Id: Reliable Multicast Transport <rmt.ietf.org>

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" <[email-masked]>
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  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
> ----------------------------------------------------------------------

Date: Tue, 10 Feb 2009 16:41:26 +0100
From: Vincent Roca <[email-masked]>
To: Mark Watson <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Rmt] AD review of draft-ietf-rmt-bb-lct-revised-07

Hello Mark,

A few answers concerning TESLA (points 2 and 3 in your email):

2- Yes this is a draft. It passed a first WGLC in september, two
   updated versions have been submitted then, and a second WGLC should
   be issued soon. If you need an RFC, you can cite RFC 4082:
	Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
	Multicast Source Authentication Transform Introduction

3- You're right, it is not specific to ALC but applies to any PI built
   on top of LCT. We decided to mention only the currently existing
   PIs for simplicity purposes (IMHO, many people get already confused
   by FLUTE versus ALC, no need to add another acronym/layer).

Cheers,

  Vincent

Mark Watson wrote:
> 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" <[email-masked]>
> 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  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>> ----------------------------------------------------------------------
> 
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmt

Date: Tue, 10 Feb 2009 09:01:20 -0800
From: Mark Watson <[email-masked]>
To: Vincent Roca <[email-masked]>
Cc: Magnus Westerlund <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Rmt] AD review of draft-ietf-rmt-bb-lct-revised-07

On the last point, since ALC is the more 'well-known' layer, and since LCT
cannot be used 'stand-alone' would it be acceptable in the LCT draft to just
state the security issues that must be addressed by any PI based on LCT and
refer to ALC for an example ? This would avoid either duplicating the text
or confusing people by moving the existing text from ALC to LCT.

...Mark 

On 2/10/09 7:41 AM, "Vincent Roca" <[email-masked]> wrote:

> Hello Mark,
> 
> A few answers concerning TESLA (points 2 and 3 in your email):
> 
> 2- Yes this is a draft. It passed a first WGLC in september, two
>    updated versions have been submitted then, and a second WGLC should
>    be issued soon. If you need an RFC, you can cite RFC 4082:
> Timed Efficient Stream Loss-Tolerant Authentication (TESLA):
> Multicast Source Authentication Transform Introduction
> 
> 3- You're right, it is not specific to ALC but applies to any PI built
>    on top of LCT. We decided to mention only the currently existing
>    PIs for simplicity purposes (IMHO, many people get already confused
>    by FLUTE versus ALC, no need to add another acronym/layer).
> 
> Cheers,
> 
>   Vincent
> 
> 
> Mark Watson wrote:
>> 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" <[email-masked]>
>> 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  +46 10 7148287
>>> Färögatan 6                | Mobile +46 73 0949079
>>> SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> Rmt mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rmt

Date: Mon, 16 Feb 2009 14:13:34 +0100
From: Magnus Westerlund <[email-masked]>
To: Mark Watson <[email-masked]>
Cc: [email-masked], Vincent Roca <[email-masked]>, [email-masked]
Subject: Re: [Rmt] AD review of draft-ietf-rmt-bb-lct-revised-07

Mark Watson skrev:
> On the last point, since ALC is the more 'well-known' layer, and since LCT
> cannot be used 'stand-alone' would it be acceptable in the LCT draft to just
> state the security issues that must be addressed by any PI based on LCT and
> refer to ALC for an example ? This would avoid either duplicating the text
> or confusing people by moving the existing text from ALC to LCT.

I think that clear requirements is the most important. However, some
informational references to existing solutions is to me highly
beneficial because they explain that the requirements are not unsolvable.

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: [email-masked]
----------------------------------------------------------------------

Date: Fri, 27 Feb 2009 16:48:27 +0100
From: Magnus Westerlund <[email-masked]>
To: [email-masked], [email-masked]
Subject: [Rmt] AD comments on draft-ietf-rmt-pi-norm-revised-08

Hi,

I have reviewed the NORM PI and have some comments that I like to see
addressed before IETF last call.

1. Document obsoletes RFC 3940? If yes, include in header, abstract and
introduction that fact.

2. Section 4.1:

Sequence number description is a bit cryptic. If I understand it
correctly each and every norm node has one sequence number space in its
sender role (if sender), and another in the receiver role (if receiver).

3. Section 4.1:

   The "source_id" field is a 32-bit value identifying the node that
   sent the message.  A participant's NORM node identifier (NormNodeId)
   can be set according to application needs but unique identifiers must
   be assigned within a single NormSession.  In some cases, use of the
   host IP address or a hash of it can suffice, but alternative
   methodologies for assignment and potential collision resolution of
   node identifiers within a multicast session need to be considered.
   For example, the "source identifier" mechanism defined in the Real-
   Time Protocol (RTP) specification [RFC3550] may be applicable to use
   for NORM node identifiers.  At this point in time, the protocol makes
   no assumptions about how these unique identifiers are actually
   assigned.

I think this is awfully vague for being a fully specified protocol on
the standards track. Doesn't the implementation experience have at least
one mechanism that can be default to use?

4. Page 26:
 "Example: EXT_FTI Header Extension Format for &quot;fec_id&quot; = 129"

Use of the wrong symbols in source seems to have produced some escaping.

5. Page 28:
"Values of "stream_control_code" that are not
   understood SHOULD be ignored."

   What can one possibly do if one doesn't understand them? Are there a
reason to build implementations that doesn't ignore them?

6. 4.2.3.4:

"If NORM is operated in a private network with
   congestion control operation disabled, the "NORM_CMD(CC)" message is
   then used for GRTT measurement only and may optionally be sent less
   frequently than with congestion control operation."

I think "private network" isn't the right naming of what the network
where one can turn off congestion control. "operated in a network where
resources are explicitly dedicated to the NORM session and therefore
congestion control operation is disabled ..."

7. 4.2.3.5:

"cc_loss" = decimal_loss_fraction * 65535.0

Does the rounding of this value matter when converting to the 16-bit
value. Most platforms that just strips the value would be equivalent to
a floor. Does it matter if ceiling or round would be used instead?

8. Section 5.1:

Congestion control operation SHALL be
   observed at all times when operating in the general Internet.

   I would like to strengthen this statement to say: at all times when
not operating using dedicated resources, like in the general Internet.

9. Section 5.5.2:

   This congestion control scheme is REQUIRED for operation
   within the general Internet unless the NORM implementation is adapted
   to use another IETF-sanctioned reliable multicast congestion control
   mechanism (e.g., PGMCC [PgmccPaper]).

The above sentence implies that PGMCC is an approved RFC document. I
would propose to remove the complete parenthesis.

10. Section 5.5.2:

 The details of PLR
   selection are not discussed in this document.

I think this and the paragraph can be misleading to that there are no
support to build the CLR + PLR list. The protocol does have a mechanism
for receiver to raise their hand and say: Hey, I may belong on this list.

11. Section 6:

The same security considerations that apply to the NORM, TFMCC, and
   FEC Building Blocks also apply to the NORM protocol.

   Please include reference indicators here.

12. Section 6.1:

The current RTP spec is RFC 3550 and not RFC 1889.

13. Section 7.1 & 11.1

RFC 2434 has been replace by RFC 5226

14. Section 11.1 and 1

   This document is a product of the IETF RMT WG and follows the
   guidelines provided in [RFC3269].

This is in my view an informative reference. So please move the
reference to the informative part.

15. ID Nits that needs to be fixed:

  = The document seems to lack the recommended RFC 2119 boilerplate,
even if
     it appears to use RFC 2119 keywords -- however, there's a paragraph
with
     a matching beginning. Boilerplate error?

     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
  = Using lowercase 'not' together with uppercase 'MUST', 'SHALL',
'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.
Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is
what you
     mean).

     Found 'SHALL not' in this paragraph:

     The "NORM_CMD(SQUELCH)" command is transmitted in response to
     outdated or invalid "NORM_NACK" content received by the sender. Invalid
     "NORM_NACK" content consists of repair requests for NormObjects for
which
     the sender is unable or unwilling to provide repair.  This includes
     repair requests for outdated objects, aborted objects, or those objects
     which the sender previously transmitted marked with the
     "NORM_FLAG_UNRELIABLE" flag.  This command indicates to receivers what
     content is available for repair, thus serving as a description of the
     sender's current "repair window".  Receivers SHALL not generate repair
     requests for content identified as invalid by a "NORM_CMD(SQUELCH)".

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: [email-masked]
----------------------------------------------------------------------