Here are a few comments below that may help further improve the paper. I - Approach and presentation - The statement 'optimal trajectory is found at boundary of the set of feasible trajectories' doesn't have a reference. I am not sure this is true in general, but even in some specific context an intuitive example or a reference is necessary. - The first time \alpha appears it is refereed to as the acquisition function. Some more explanation as to what is an acquisition function would benefit readability for a wider audience. - There is some ambiguity in the overall approach as to what happens online vs offline. Is the approach augmenting the dataset to do incremental learning in an online setting or is the model learned batch style and then deployed to find trajectories, for example, for the real robot. If there is incremental learning is the variational inference performed every time a new data point is added? - There are a lot of variables and I found myself often going back and forth trying to find their definition. Sometimes the notation maybe inconsistent, for example, l has superscripts and subscripts and have been used interchangeably or their distinction wasn't made clear. - Trajectory plots are hard to interpret. For instance, Fig 3 is quite small and the distinction in color is hard to see to understand the altitude. Maybe a perspective 3D view would be more helpful or the trajectory with the quadrotor on it at waypoints in various orientations would help ground it. II - On experiments and practical details - Going back to the online vs offline ambiguity is it unclear if the learned model is deployed in settings similar to the training data i.e. the boundaries between training and testing is unclear. Given this, how well does the method generalize to problems it has not seen before? - Result in IVA referring to Fig. 2 is 2%. Maybe this is a typo and it is closer to 20%? - In Fig. 4 the lower bound on improvement is about 5%. Why was the improvement significantly less here? Any way to know how improvement relates to the problem defined by the desired set of waypoints? - What were the computational times of the approach? - It wasn't clear how someone would choose the fidelity levels or even define how many are needed for an application. Also how does the approach scale with increasing number of fidelity classes. III - Limitations The authors should consider adding a limitations section where the following could be discussed: - Is the approach real-time or is the trajectory computed offline and then followed by tracking? - How is state uncertainty handled? - How would obstacles be handled? - The real world flights show the quadrotor moving through free space, how is the tolerance to the desired waypoint verified? With respect to the drone racing challenges mentioned in the introduction typically the quadrotors are required to pass through a set of floating gates.

Overall, the paper exposes clearly its objective. It is well written and the contribution is relevant. My first point is that it could make a better job a motivating the need to reach exactly the optimum (there are plenty of good reasons for this, but they are not mentioned here). My second point is that the paper lacks an important discussion about the cases where the feasibility constraints are wrongly approximated. In such cases the consequences would of course be rather dramatic, and it seems important to obtain some estimation of how likely this is to occur with respect to formulation (6). This brings back to the question of "do we really want the optimum" for uncertain hardware control ? I am not saying that identifying the feasibility constraint is not relevant, but the study should somehow discuss how confident the information is.