==================================
Comments on the TDR from Nurcan Ozturk:
==================================
3.1 (Ease of use) Functionality to clone existing tasks will be helpful in the new 
data reduction framework where we will be running similar NTUPtoNTUP jobs for 
groups.

4.2. In the new model "Reconstruction" output will be the Root-readable AOD 
and the group production will just be NTUPtoNTUP trf's running on these new 
AOD's that those tasks can then just be added to the live Meta-Tasks.

4.5.3 This is often the case for MC samples for group production, so augmentation 
will be useful functionality.

5.3.4 We will need scout jobs in the data reduction framework to produce 
output file size, processing time to estimate resource requirements.

5.3.5 This will be very useful as it is very manually handled in the current group 
production.

5.4.2 How to notify groups when datasets are repaired? Will the dq2 consistency 
service send a notification as it does for the lost files currently? Groups (at least 
one group we know) use the tid dataset to make their group containers, this should 
be discouraged, in AMI/dq2?

5.6.1 submitting state is missing in the diagram.

============================================
Comments on the TDR from Rob Henderson:
============================================
The language of the document is often at a level of abstraction which I
find hard to understand at the level of the user. I have read it through
and where I feel I have sufficiently understood it and have a comment I
include it below.

3.1 (Ease of use section) I think many of the points that I would like to
make are very sketchily described here. I think they should be made more
concretely, but I think if templates etc mean what I think it means its
exactly what I would want.  However I would like to emphasise that we
should be able to build tables for even large lists of tasks however
defined with large or small numbers of fields.

5.3.1 (file splitting) this sounds fine but my impression was that the
events per job parameter did not map into this in a simple way which lead
to much confusion. I strongly feel that if I am right about this this
needs to be fixed.

5.3.5 (splitting and reassignment) I am not sure if this is proposed but
it would be good if group production could be able to to split jobs that
hit limits and reassign where clearly the site is having problems.
Currently I find I have to send emails describing the situation when we
could actually fix the problem in the same time.

5.4.2 (Lost file recovery)  Could we be given direct control of datasets
without having to discover which taskid created it and aborting that?
It seems to be saying it knows how the lost file was originally created so
can automatically or under instruction just recover the file (however
sometimes the input data might have been deleted?).

5.6.1 (Task status) Currently a job will show as pending but as far as I am
aware there is no way of seeing (for us anyway) why although the reason
must be known. If a job is in such a state it could show the condition
code or reason why it has made that decision through a simple link.

Disk full procedures. I realise that this could create problems but if
user disk could only ever be >90% full for a limited period would that not
get round the problems when output has nowhere to go.

I hope these comments are vaugely sensible but I know that I have not
fully comprehended the document but possibly because it is not fully
defined.