Hi all, here are the raw notes taken by Micheal (very detailed, thanks again Micheal!). Please take a look and point out any inaccuracies.
Rich has already started a separate thread to address the only remaining open point. Please comment on that as well, so that authors can produce a final WG version of the document soon. Enrico ******************************** ALTO interim meeting June 19, 2013, 17:00-18:00 CET Notetaker: Michael Scharf Agenda (Enrico Marocco) ------ draft-ietf-alto-protococol (Richard Alimi) -------------------------- * Changes in -16 * Slide 4: Item 1: IRD declaration * Slide 5: Item 2: Update frequency Enrico: Discuss this now or at the end of the presentation? Richard Yang: Recommend one method or leave it open? Richard A.: Leave it on HTTP. Benefits is that we don't have to track HTTP. Enrico: I tend to agree with Richard A., going with HTTP is generally recommended. Richard Y.: We should recommend that ALTO server should have cache control. HTTP doesn't mandate this. Enrico: Any objection to using HTTP? <NONE> * Slide 6: Item 2: Update frequency Sebastian Kiesel: What is the meaning of the first sentence? It has no normative language. Do we need it? Richard A.: We can just drop the first part of the sentence. Enrico: Any objections? <NONE> * Slide 7: Item 3: Equivalence of Server Data Richard Y.: I want to back what Richard A said. Richard A.: Redirection from custom.alto.example.com to alto.example.com not possible. Richard Y.: Let's go to the next slide before discussing solutions. * Slide 8: Solution to item 3 Richard Y.: Seems to be more flexible solution. *** NOTE: audio outage of several seconds for the note-taker *** Richard A.: Can we simplify this to not affect the IRD? For instance, only use the second proposal on slide 8? Richard Y.: This would work, too. Richard A.: What is the benefit of adding it to IRD? Richard Y.: Metadata is only in one place. Enrico: Does everybody understand the problem and the two solutions? Michael: I don't understand the options. I haven't followed this issue before, but if you want to hear opinions, I can't really comment based on what was presented here. Richard Y.: Idea 1 is to use the URI? Idea 2 is to encode URI in cost map metadata. Michael: I understand the problem, and it seems to be an important problem, but I don't fully get the tradeoff between the solutions. Richard A.: Explanation of slide 8 and 9 Enrico: I suggest that the authors agree on a solution and post it on the mailing list. Michael: Yes, the solution 2 seems OK, but some written explanation of the rationale would help. Richard A.: I then suggest to use the second solution without IRD entry. * Slide 9: Proposed Tentative Timeline Richard A.: When to schedule the WGLC? Enrico: Best practice is not to span the IETF week. Recall that this blocks all other drafts, including adoption of the discovery drafts, extensions, etc. Enrico: I suggest that the authors send a note to the list with the (only) remaining entry. Spencer Dawkins: I agree on your statement of avoiding a WGLC during the IETF week. * Security discussion Richard Y.: Security issues. Do we want to spend some minutes on the discussion between Jan and Sebastian? Sebastian: I don't have much to add to what we discussed on the list. We have given the security section a new layout and I am happy with it. Jan found some minor issues, some bugs and some are probably beyond a standards track document. We should probably await the SECDIR review. Jan: I agree with Sebastian. I read it and the section is very good. I just posted some thoughts, which are minor issues. Sebastian: The issue is that there are three kinds of risks and only two counter-measures. Jan: I agree with Sebastian. The purpose of the section is to give implementors an understanding of the security issues. But, again, the text is actually fine. Enrico: Thanks to Sebastian and Jan, this is very useful. The whole document improved a lot since Orlando. Enrico: Further comments? Sebastian: Beginning of the document - "solution benefits" is uncommon. Do we want to have this? This is a small question I still have in mind. Richard Y.: You want to remove Section 1.2? Sebastian: Maybe the whole introduction could be reworked, to shorten it? Something like "This is the protocol that solves the problem explained in ...". But it is just a comment, I don't have a strong feeling. Richard A.: I prefer documents that are somewhat self-contained. Sebastian: I will go through the introduction and check if there are contradictions. Jan: I just realized that the document refers to the problem statement RFC only in the terminology section. It should probably be mentioned in the introduction, too. Sebastian: Reading this document, it is not clear to me that this is the outcome of the ALTO WG and result of a problem analysis etc. Jan: This is somehow a matter of taste. A short re-cap may be fine. What it definitively missing is a better reference to the problem statement draft. Sebastian: I back that. The problem statement and requirement documents should be refered. I will check the text for consistency with them. Enrico: I agree. Checking for consistency is good to do now. There is a chance that there will be further comments on the introduction during the publishing process. We must be prepared to react to IESG reviews on that in any case. Sebastian: Actually, my proposal could help here. Enrico: It is a matter of taste, but there may be strong opinions in the IESG. Richard Y.: Clarification questions: Are we allowed to submit drafts on extensions for the upcoming IETF? Enrico: I will check with my co-chair and the ADs. My thinking is that the milestone is completing the WGLC of the protocol document. Richard Y.: People want to talk about ALTO extensions. Enrico: Understood, but the document was due 2 years ago. But we see light at the end of the tunnel. End of meeting
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
