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

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.

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

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