Subject: [apps-discuss] Apps Area Review of draft-ietf-alto-server-discovery-08

From: Eric Burger <[email-masked]>
Date: Sat, 13 Jul 2013 06:23:54 -0400

I have been selected as the Applications Area Review Team reviewer for this draft.  For background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team .
 
Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
 
Document: draft-ietf-alto-server-discovery-08
Title: ALTO Server Discovery
Reviewer: Eric Burger
Review Date: 13 July 2013
IETF Last Call Date: unknown
IESG Telechat Date: unknown
 
Summary: This draft is almost ready for publication as a Proposed Standard and should be revised before publication.

Major Issues:
 
Section 3.1:
The second option of Step 1 Option 2, is using RFC 2132 to get the name of the access domain in the event the DHCP server does not know RFC 5986 or a middlebox is damaging DHCP requests. That is OK as a fallback mechanism. However, the document needs to describe why we want RFC 5986 behavior and not RFC 2132 behavior. The big one is going to be that a service provider may have the ALTO overlay on a different level than the access network. For example, the ALTO overlay may span east.us.example.net, while my access network might be nova.va.east.us.example.net. My presumption is a U-NAPTR lookup for ALTO in nova.va.east.us.example.net will fail, while east.us.example.net is what I want. If I am wrong there, then this major issue becomes a minor issue - just say something for folks not using the mechanism every day.

Minor Issues:
 
Section 4.2:
Under what circumstances would an ALTO client *not* " query the ALTO server(s) that have been discovered for this specific interface and address family"?
 
Hidden normative language. I would propose "If there is a change in the IP address of an interface, the client MUST rerun the ALTO server discovery procedure." Also, why the restriction of forgetting prior earlier gained information? If the client MUST rerun the procedure, do not suggest to implementors to remember prior information. This is like telling a child he cannot have a cookie. He did not know he could have a cookie until you told him not to have one. In the situation of server discover, if you say rerun the procedure, there is no question of using the old data.
 
Nits:
Section 6.2, Page 12, first full paragraph:
OLD
The domain name that is used to authenticated
 
NEW
The domain name that is used to authenticate