[alto] Raw interim minutes

[Enrico Marocco <[e-mail]>]

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