Others may find the diff at https://github.com/lsst/LDM-612/compare/tickets/RFC-592...tickets/RFC-654 helpful; I know I did.

(The use of \newtext and \oldtext means that the resulting PDF has color-coded changes.)

The changes in LDM-612 and the new LDM-723 look fine to me.

I would encourage the broker evaluation, as part of its consideration of technical resources (LDM-612 §4.6) to consider specifically 1) the ability of the proposer to support integration activities both during Commissioning/Early Operations and later during the course of the survey if/when technical aspects of the broker interface are modified and 2) the ability of the proposer to handle downstream customer inquiries and issues independently of LSST.

Thanks Kian-Tat Lim I added 2 bullets in LDM-723: 

2.5.4: 

• Describe plans to support integration activities, both during LSST Commissioning and Early Operations, and later during the course of the survey if or when technical aspects of the broker interface are modified.

2.5.6

• Describe plans and processes to handle downstream user enquiries and issues independently of LSST

Comments on LDM-612:

community_brokers.tex, line 81: is there any plan to recompete broker slots during operations? How long will the project guarantee to provide an alert stream to the selected brokers for? Will brokers be monitored for quality of service during the operational era? All of these things can be specified by an MOU with the selected brokers, but it would seem fair to at least set some expectations here.  (Please ignore, I found an answer to this one)

community_brokers.tex, line 100: what if no viable proposal for such a broker is received?

community_brokers.tex, line 191: LSO-011 hasn't been published, is still marked as draft, and the preferred version on Docushare (which isn't linked to) is meaningless. I think it's fine to cite it, but it would be wise to add a disclaimer here that it is not normative (“some possible data release scenarios are described....”).

components.tex, line 10: I believe that the standard term is “alternate standard visit” (rather than “alternative”; see LSR-REQ-0120, although I note the DM glossary is wrong). And I think this is a perfectly respectable term which doesn't deserve scare quotes!

components.tex, line 73: the text at this line is not new, but the comment re “five full streams” a couple of lines below is. I think (but am on a cell phone, so can't easily check) that the baseline is “five full streams”, and “10 Gbps” is just an implementation detail.

data_rights.tex, line 3: LDO-13 is still very much in draft, and, indeed, the version cited is stamped “DRAFT; NOT YET APPROVED”. Please retain the “which is in development at this writing” caveat (or add something equivalent).

Comments on LDM-723:

• “Bandwidth” is singular; don't say “Bandwidth for at least five full streams are required to be supported”.
• Will the project act as a “matchmaker” between “direct stream access” and “downstream” brokers? (Otherwise, the incentives for brokers which aren't requesting direct stream access to actually bother submitting proposals seem pretty minimal.)
• I'll note that reviewing and selecting brokers during the summer — when folks will typically have vacations, and we'll be dealing with two major reviews and the Project & Community Workshop — may be challenging. However, I imagine this schedule is set by the SAC, so I don't expect my worries to count for much!

I pushed changes addressing most of John Swinbank's comments. The ones I didn't address in the text:

If no viable broker offering public access is proposed? Seems unlikely given the LOIs, and part of the impetus for this line is to create incentives for such proposals.

I agree that the motivation for downstream brokers to submit proposals is less obvious, but the SAC has requested it. The hope is that writing the proposal call this way will prompt some pre-coordination among the broker teams. Proposals from downstream brokers can therefore strengthen the proposals of direct-access brokers they have made agreements with.

The project has largely driven the schedule to date. Historically having the SAC face-to-face meeting at the PCW has served as a good opportunity to make progress.

Finally I'll note that I made some minor updates addressing https://jira.lsstcorp.org/browse/DM-20561 that I had omitted earlier. This was just a note in LDM-723 that proposals are private, and some rewording of alert packet sizing that I incorporated with John Swinbank's comments.

Given the urgency, the lack of opportunity for the DM-CCB to meet, and the fact that Wil O'Mullane is out, I'm unilaterally recommending this RFC on behalf of the DM-CCB.