Re: [MMUSIC] Comments on draft-ietf-mmusic-img-req-03.txt

[Magnus Westerlund <[e-mail]>]

Hi Rod,

Comments inline.

[e-mail] wrote:
> Hi Magnus
> 
> Thanks for the review comments. Responses below...
> 
> (BTW, sorry if I missed some other responses - I'm on vacation and
> suffering badly intermittent connectivity)
> 
> -----
> 
> 
>>1. Section 2: The capitalized words MUST SHOULD, etc. used in this 
>>specification may not always be appropriate. This is due to that the 
>>definitions are more intended for technical specifications 
>>and putting 
>>requirements on implementations. It might be consider better if the 
>>document defines the words.
> 
> 
> Yes, this is a valid point. This is in the same vein as the Seoul
> plenary discussion on the applicability of RFC2119 ("should, shall,
> must..."). The RFC is intended for protocol implementation
> specifications, but since we don't have an RFC to give the power words
> for requirements we're aiming to use RFC2119 "in the spirit" of
> requirements. In this sense we didn't see any fundamental problem with
> capitalisations to emphasise the requirement in question. Anyhow, I'll
> have another look through to see if I spot any obvious inappropriate
> capitalization - if you saw some specific offending instances (or all
> instances :) please direct us to the paragraphs.

Okay, I haven't really found an inappropriate usage. However it has been 
to long since I read the exact statement of RFC 2119.


> 
> -----
> 
> The text in question is (for everyone else's benefit):
>    REQ DEL-1: The system MUST be scalable to large numbers of messages,
>    so that it does not fail to deliver up-to-date information under huge
>    numbers of transactions and massive quantities of IMG metadata.
> 
>>2. Section 5.2.1: Req DEL-1: I see some problems with writing 
>>a MUST in 
>>this context. I agree that scalability is desirable and is a clear 
>>design goal of any solution. The problem lays in the measuring of 
>>scalability. Absolute measurements of scalability is hard to 
>>establish. 
>>Also in certain environments one might not be able to create good 
>>scalability due to other factors in the system, for example extremely 
>>limited bandwidth. Thus I would suggest that this is 
>>reformulated into 
>>something that is more a statement of intention.
> 
> 
> I think this is a matter of wording - the meaning was correct but not
> expressed clearly enough. It was important for us to state a hard
> requirement, but clearly the "IMG solutions" may be useful outside the
> massively scalable context. How about this re-write...
> 
>    REQ DEL-1: The IMG system MUST be scalable to large numbers of 
>    messages, so as to allow design and use of delivery mechanisms 
>    that will not fail in delivering up-to-date information under 
>    huge numbers of transactions and massive quantities of IMG 
>    metadata.
> 
> ...which gives the requirement but makes it's applicability clearer: the
> IMG system design must be scalable even if it's deployment (and used
> delivery protocols) are not scalable (e.g. if massive scalability is not
> feasible in a certain scenario). On the other hand, it ensures that the
> design and use of scalable delivery protocols is not hindered.
> 

This sounds better.

> -----
> 
> The text in question is:
>    By contrast, intermittent connectivity make immediate distribution of
>    changes infeasible and so managing data consistency should be focused
>    on the timely delivery of data.
> 
>>3. Section 5.4.1: Last paragraph: I think that the intermittent 
>>connectivity actually should be formulated into a requirement:
>>
>>REQ: "The IMG system SHOULD allow for low cost 
>>uptodate/consistency checks."
> 
> 
> Good suggestion. For the mobile/cellular type cases "allowing
> intermittent connectivity" is somehow bound to "enabling low cost
> consistency messaging". For other cases intermittent connectivity is not
> related to cost of communications (e.g. limited HW-accelerated header
> filtering resources, or power-reduction by sending a connection idle, in
> broadcast receivers; or shutting down background Internet activity when
> a user is not active - for security). So how about this  rewrite of the
> last paragraph...
> 
>    REQ REL-3: The IMG system SHOULD allow for hosts with intermittent 
>    connectivity.
> 
>    The implication of intermittent connectivity is that immediate 
>    distribution of changes becomes infeasible and so managing data 
>    consistency should be focused on the timely delivery of data.
> 
> This would also require "REL-3" -> "REL-4" number re-alignment.
> 

Okay, if one knows enough one understand that intermittent connectivity 
will result in follow up claims. And this requirement is probably wider 
than what I thought of, which is good.

I am a bit worried that different persons will have significant 
different interpretation of what derivative requirements these open 
requirements results in.

> -----
> 
> 
>>4. Section 5.5, Req DES-4: "IMG metadata MUST be structured 
>>such that it 
>>is possible to deliver only part of an IMG sender's (and the global) 
>>complete IMG metadata knowledge."
>>
>>I think this is SHOULD rather than a MUST. The reason is for example 
>>that some may want to use already established metadata 
>>formats that does 
>>not fulfil the requirements. Should they not be allowed to 
>>use IMG due 
>>to that facT?
> 
> 
> The intention is that the whole body IMG metadata is structured such.
> So, although we aren't proposing redesign of SDP, we are proposing that
> different SDP descriptions (e.g. delivered as files) are part of a
> larger structured body of IMG metadata (and the same applies to "foo"
> metadata syntax). IOW, the requirement states less about the internal
> structuring of metadata and more about the ability of it to be mapped
> onto efficient delivery.
> 
> This wording should mean the same thing but read clearer. Sound good?
> 
>    REQ DES-4: IMG metadata MUST be structured to enable fragmentation 
>    for efficient delivery.
> 
>    This it is intended to ensure that and IMG sender with more than a 
>    trivial knowledge of metadata is able to deliver only part of its 
>    (and the global) complete IMG metadata knowledge. (For instance, a 
>    trivial quantity of knowledge could be a single SDP description). 
>    In general, the resolution of this fragmentation will be very much 
>    dependent on the optimal delivery of a deployment, although some 
>    metadata syntaxes will inherently effect the sensible lower limit 
>    for a single element/fragment.
> 

Much better.

> -----
> 
> 
>>5. The security requirements: Have you had any review of these, and 
>>there possibility to be fulfilled? I think it would be stupid 
>>to require 
>>security that is not possible to fulfil, how much it still is 
>>desirable. 
> 
> 
> True. Please pinpoint any requirements which are infeasible. Although we
> have been through these security requirements many time, a fresh set of
> eyes could easily spot things aren't clear enough. (And bear in mind -
> like the massive scalability requirement - these are requirements
> intended for the design of the IMG system and not a firewall to other
> uses of IMGs)
> 

When I meant review of the security requirements I meant having them 
reviewed by the security area directorate.

> 
>>And if a piece of security is required lacks solution, should we then 
>>shelf IMG?
> 
> 
> The aim is to publish these requirements as Informational RFC. So
> ultimately these requirements provide security considerations (since
> standards track normative requirements referenced from subsequent
> protocol specifications would be an untested idea in the IETF - I guess
> someone can prove me wrong :).
> As far as I am aware, an Informational RFC is in no position to shelve a
> protocol, no matter a framework. However, they will provide a strong
> metric in evaluating protocol proposals, so those which offer security
> solutions which are appropriate for there use would be the strongest
> candidates.
> 
> So the short answer would have been "no".

Okay, as long as one takes the security requirement serious. Therefore I 
think it is important to get security expert review already now. Thus 
one can get an impression on the feasibility of the solution.

> 
[snip]
> -----
> 
> Basically, all the changes I'm proposing are clarifications (including
> the 5.4.1 "commentary" -> "requirement + commentary") or NITs. So
> Magnus, would you agree with me that these changes would be enough
> without a new last call?
> 

I don't know, I would like to see a diff of the updated document before 
saying that. Also I would be much more confident about this WG last call 
if the security directorate has signed off it as being okay.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]


This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic