T5.
Comment: The sentence "(or the number of layers subscribed for a
layered
multicast session)" suggests that this payload specification can be
used
for layered multicast. We don't think this payload specification is
capable for layered multicast
The wording is consistent with other RFCs that also don't
explicitly define how layered multicast will work. See for
example RFC 4175 (Uncompressed Video). It uses the same
wording, without any explanation for how layered multicast
would actually work with that payload format.
I think the "Congestion Control" section is similar to the
"Security Considerations" section, in that it tries to
describe how to handle unlikely scenarios. (In some RTP
payload format specs, the treatment of congestion control is
actually included in the Security Considerations section
itself.) The intent is that the section should provide clear
normative language for the appropriate behavior (in this case,
unsubscribing to a multicast group), but detailed discussions
about implementations are out of scope, in my opinion.
As you mentioned in option #2, using this payload format with
layered multicast is not completely impossible. It could be
done in conjunction with some other RTP payload format or with
some new RTP header extension. I think that is enough
justification for keeping the sentence in there, just in case
someone will attempt it in the future.
But it is simply out of scope to go in to specific details
about how layered multicast can or cannot be implemented.