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

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.

-----

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.

-----

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.

-----

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

-----

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

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

-----

> 6. IPR and Copyright statement. Needs to be updated using RFC 
> 3667 and 
> 3668. Also please provide a heading for the IPR section.

A very reasonable suggestion.

-----

> 7. Also as this document is intended for informative, you can't have 
> normative references.

Good point, we should revert back to the 02 style (all references as "References" - none normative).

-----

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?

Cheers, Rod.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic