It is noted that "micro" payments are not possible for high-value products that need to be delivered quickly. The question of whether there is a protocol for doing repeated payments is raised, and it is clarified that currently, paying the same payment request twice is not possible as it invites anyone in the middle to take the funds. With 1.1, the payment hashes will be changed to make this possible. Regarding the payment route going down, it is clarified that it only happens during the actual payment and not everything related to that payment request. If any party goes down after receiving the offer but before either failing or returning the preimage, the payer has to wait, unsure if they'll try to redeem the offer or not. The refund address is also discussed, and it is noted that nobody along the route can see it. However, there needs to be some way for the payee to tell the payer it wants a refund address, hence a flag in BOLT 11.The purpose of the d and h tagged fields in BOLT 11 is discussed, and it is clarified that 'p' is the payment-specific variable. There is also a mentioning of the n field in BOLT 11, which is used if key recovery is not possible.