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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 08 Mar 2004 06:26:07 +0100

Hi,

I a have some comments to this document that currently are in WG last call.

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.

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.

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

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?

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. 
And if a piece of security is required lacks solution, should we then 
shelf IMG?

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

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

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: [email-masked]
Date: Thu, 25 Mar 2004 16:45:39 +0200

Hi Magnus

Thanks for the additional comments. On the subject of intermittent connectivity you are "a bit worried that different persons will have significant different interpretation of what derivative requirements these open requirements results in".

Can you explain the problem a little please? (I assume it is associated with "The IMG system SHOULD allow for hosts with intermittent connectivity").

As a guess at the derivative requirements you mention, my understanding of the base requirement is: permanent connectivity should not be assumed for all terminals of all IMG deployments, the IMG system should not break if some delivery protocols enable intermitted delivery (for intermittent connectivity), it is up to the appropriate delivery protocols and data model to provide service for hosts with intermittent connectivity when a deployment needs this feature.

On one hand I would be happy changing SHOULD to MUST, although on the other hand I am happy with the implied requirements I would understand from the base requirement (and just stating the base requirement is a lot less verbose). If I'm, having a woods and trees lack of vision, please give me an idea of some problematic implied requirements.

Ultimately, I need an idea of whether...

   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.

...is sufficient within the scope of an Informational Requirements document in you opinion, and if there are specific improvements that are necessary.

Alternatively an extended version could be:

   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.
   Please note, these are some anticipated implications of this 
   requirement: permanent connectivity is not assumed for all 
   terminals of all IMG deployments, the IMG system will not break 
   if some delivery protocols enable intermitted delivery (for 
   intermittent connectivity), it is the task of an appropriate 
   delivery protocol(s) and metadata fragmentation to provide 
   consistent service for hosts with intermittent connectivity 
   when a deployment needs this feature.

(The related thread text is copied below).

Cheers, Rod.

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