Application-Layer Traffic Optimization (ALTO) Server Discovery
draft-ietf-alto-server-discovery-10

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-alto-server-discovery-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:


IANA understands that, upon approval of this document, there is a single action IANA is required to complete.

In the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters

a new Application Service Tag is to be registered as follows:

Tag: ALTO
Reference: [ RFC-to-be ]

IANA understands that this is the only actions required to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

[Ballot discuss]
s6.1: For DHCP isn't it a bit more than just following BCP on safely operating DHCP - shouldn't it be that DHCP authentication is enabled to ensure the ALTO/DHCP client isn't tricked in to taking information from the wrong DHCP server?  Dditto for modifying the DNS records - shouldn't it be that DNSSEC be enabled?

[Ballot discuss]
I believe that alto-protocol is a normative reference, not an informative one.  It's used as the reason in the second paragraph of Section 3.2 for limiting discovered URI schemes.  If alto-protocol should change in that regard, this would have to also.

[Ballot comment]
Some non-blocking comments that I would like you to seriously consider, and feel free to chat with me about:

-- Section 2 --

In bullet 1, is it correct to be more specific, like this?:

OLD
  One or - in case of multiple interfaces and/or IPv4/v6 dual stack
  operation - more DNS domain names are retrieved
NEW
  One DNS domain name is retrieved for each combination of interface
  and address family

By "manual input", are you really talking about client (or resource consumer) configuration here?  Wouldn't it be clearer to say that?

--Section 3.1.1 --
Not to make too big a thing of this, but it strikes me that the MAY and SHOULD in the second paragraph have nothing to do with the protocol, and are just non-normative advice about implementation for better user experience.  Maybe lose the 2119 key words here?

-- Section 4.1 --

The first sentence confused me for a while, as I tried to figure out what is "enabled".  I finally decided it's not the right word, nor the right phrasing.  Maybe this?:

OLD
  Section 3.1.2 describes the usage of a DHCP option. It enables the
  network operator of the network, in which the ALTO client is located,
  to provide a DNS domain name.
NEW
  Section 3.1.2 describes the usage of a DHCP option that provides a
  means for the operator of the network in which the ALTO client is
  located to provide a DNS domain name.

-- Section 6.1 --

  Best current practices for safely operating DHCP should be followed.

Do you have a pointer to help the reader find those best practices?

  Note that if TLS is used to protect
  ALTO, the HTTPS URI will be authenticated, i.e., the result of the
  U-NAPTR resolution, not the input domain name.

I'm really trying to make sense out of that sentence, but I can't.  Can you try to rephrase it more clearly, please?

  If it turns out
  that relying on the guidance of a specific ALTO server does not
  result in better-than-random results, the usage of the ALTO server
  may be discontinued.

How do you discontinue the use of a server that users have configured (as opposed to one that's been discovered through DHCP)?

[Ballot comment]
I have no objection to the publication of this document, but I do have a comment and a nit.

=====

I find the following text strange:

"In other words, this document
tries to meet requirement AR-32 in [RFC6708] while AR-33 is out of
scope.  A different approach, which tries to meet requirement AR-33,
i.e., third-party ALTO server discovery, is addressed in
[I-D.kist-alto-3pdisc]."

What does it mean to "try to meet"?

If the RFC meets the requirement, then it is useful for the reader to be left in no doubt. If on the other hand it only partially succeeds, it would be useful to the reader to know this early in the text together with a list of issues with the approach.

This may of course be a case of modesty, in which case I suggest s/tries to meet/meets/

========

i.e., a PTR lookup

PTR is used without a definition

=======

[Ballot discuss]
-- Section 4.2 --
The SHOULD in the second paragraph, and, indeed, the whole second paragraph confuses me.  I don't understand how it fits into the protocol described in Section 3, which requires that configuration settings take precedence over DHCP queries.  Please explain this to me.

-- references --
I believe that alto-protocol is a normative reference, not an informative one.  It's used as the reason in the second paragraph of Section 3.2 for limiting discovered URI schemes.  If alto-protocol should change in that regard, this would have to also.

[Ballot comment]
Some non-blocking comments that I would like you to seriously consider, and feel free to chat with me about:

-- Section 1 --

  This document specifies a procedure for resource consumer initiated
  ALTO server discovery, which can be used if the ALTO client is
  embedded in the resource consumer.  In other words, this document
  tries to meet requirement AR-32 in [RFC6708] while AR-33 is out of
  scope.  A different approach, which tries to meet requirement AR-33,
  i.e., third-party ALTO server discovery, is addressed in
  [I-D.kist-alto-3pdisc].

It appears from this that the two approaches aren't just to meet different requirements, but to address different use cases.  Would.it be reasonable to say something about the use cases, as well as the requirements?

-- Section 2 --

In bullet 1, is it correct to be more specific, like this?:

OLD
  One or - in case of multiple interfaces and/or IPv4/v6 dual stack
  operation - more DNS domain names are retrieved
NEW
  One DNS domain name is retrieved for each combination of interface
  and address family

By "manual input", are you really talking about client (or resource consumer) configuration here?  Wouldn't it be clearer to say that?

--Section 3.1.1 --
Not to make too big a thing of this, but it strikes me that the MAY and SHOULD in the second paragraph have nothing to do with the protocol, and are just non-normative advice about implementation for better user experience.  Maybe lose the 2119 key words here?

-- Section 4.1 --

The first sentence confused me for a while, as I tried to figure out what is "enabled".  I finally decided it's not the right word, nor the right phrasing.  Maybe this?:

OLD
  Section 3.1.2 describes the usage of a DHCP option. It enables the
  network operator of the network, in which the ALTO client is located,
  to provide a DNS domain name.
NEW
  Section 3.1.2 describes the usage of a DHCP option that provides a
  means for the operator of the network in which the ALTO client is
  located to provide a DNS domain name.

-- Section 6.1 --

  Best current practices for safely operating DHCP should be followed.

Do you have a pointer to help the reader find those best practices?

  Note that if TLS is used to protect
  ALTO, the HTTPS URI will be authenticated, i.e., the result of the
  U-NAPTR resolution, not the input domain name.

I'm really trying to make sense out of that sentence, but I can't.  Can you try to rephrase it more clearly, please?

  If it turns out
  that relying on the guidance of a specific ALTO server does not
  result in better-than-random results, the usage of the ALTO server
  may be discontinued.

How do you discontinue the use of a server that users have configured (as opposed to one that's been discovered through DHCP)?

[Ballot comment]
I thought this draft was well-written and clear.

I had two minor and non-blocking comments and would appreciate if they were considered, along with any other comments that may come out of IESG Evaluation.

In 3.1.1.  Step 1, Option 1: User input

  The preferred way to acquire a domain name related to an interface's
  point of network attachment is the usage of DHCP (see Section 3.1.2).
  However, in some network deployment scenarios there is no DHCP server
  available.  Furthermore, a user may want to use an ALTO service
  instance provided by an entity that is not the operator of the
  underlying IP network.  Therefore, we allow the user to specify a DNS
  domain name, for example in a configuration file option.  An example
  domain name is:

      my-alternative-alto-provider.example.org

  Implementations MAY give the user the opportunity (e.g., by means of
  configuration file entries or menu items) to specify an individual
  domain name for every address family on every interface.
  Implementations SHOULD allow the user to specify a default name that
  is used if no more specific name has been configured.

So, if you MAY have the opportunity to specify an individual domain name for every address family on every interface, but you don't, and you SHOULD be able to specify a default name, but you can't, can you still use ALTO?

In 6.1.  Integrity of the ALTO Server's URI

      Due to the nature of the protocol, DHCP is rather prone to
      attacks.  As already mentioned, an attacker that is able to inject
      forged DHCP replies into the network may do significantly more
      harm than only configuring a wrong ALTO server.  Best current
      practices for safely operating DHCP should be followed.

Is there a reference you can point to for best current practices when operating DHCP?

Your answer may be "not really", of course - RFC 2131, in section 7, just says it's easy for unauthorized servers to forge DHCP replies, and I didn't see any of the RFCs listed as updating RFC 2131 solving that problem.

[Ballot comment]
I thought this draft was well-written and clear.

I had two minor and non-blocking comments and would appreciate if they were considered, along with any other comments that may come out of IESG Evaluation.

In 3.1.1.  Step 1, Option 1: User input

  The preferred way to acquire a domain name related to an interface's
  point of network attachment is the usage of DHCP (see Section 3.1.2).
  However, in some network deployment scenarios there is no DHCP server
  available.  Furthermore, a user may want to use an ALTO service
  instance provided by an entity that is not the operator of the
  underlying IP network.  Therefore, we allow the user to specify a DNS
  domain name, for example in a configuration file option.  An example
  domain name is:

      my-alternative-alto-provider.example.org

  Implementations MAY give the user the opportunity (e.g., by means of
  configuration file entries or menu items) to specify an individual
  domain name for every address family on every interface.
  Implementations SHOULD allow the user to specify a default name that
  is used if no more specific name has been configured.

So, if you MAY have the opportunity to specify an individual domain name for every address family on every interface, but you don't, and you SHOULD be able to specify a default name, but you can't, this text may be saying that the user can't use an ALTO service instance. If there are workarounds, perhaps it's worth saying so.

In 6.1.  Integrity of the ALTO Server's URI

      Due to the nature of the protocol, DHCP is rather prone to
      attacks.  As already mentioned, an attacker that is able to inject
      forged DHCP replies into the network may do significantly more
      harm than only configuring a wrong ALTO server.  Best current
      practices for safely operating DHCP should be followed.

Is there a reference you can point to for best current practices when operating DHCP?

Your answer may be "not really", of course - RFC 2131, in section 7, just says it's easy for unauthorized servers to forge DHCP replies, and I didn't see any of the RFCs listed as updating RFC 2131 solving that problem.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ALTO Server Discovery) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'ALTO Server Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-09-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The goal of Application-Layer Traffic Optimization (ALTO) is to
  provide guidance to applications that have to select one or several
  hosts from a set of candidates capable of providing a desired
  resource.  ALTO is realized by a client-server protocol.  Before an
  ALTO client can ask for guidance it needs to discover one or more
  ALTO servers.

  This document specifies a procedure for resource consumer initiated
  ALTO server discovery, which can be used if the ALTO client is
  embedded in the resource consumer.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1952/

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-alto-server-discovery-08.  Authors should
review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

WE understand that, upon approval of this document, there is a single action which we must complete.

In the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at:

http://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xml

a new U-NAPTR will be registered as follows:

Tag: ALTO
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (ALTO Server Discovery) to Proposed Standard


The IESG has received a request from the Application-Layer Traffic
Optimization WG (alto) to consider the following document:
- 'ALTO Server Discovery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The goal of Application-Layer Traffic Optimization (ALTO) is to
  provide guidance to applications that have to select one or several
  hosts from a set of candidates capable of providing a desired
  resource.  ALTO is realized by a client-server protocol.  Before an
  ALTO client can ask for guidance it needs to discover one or more
  ALTO servers that can provide suitable guidance.

  This document specifies a procedure for resource consumer initiated
  ALTO server discovery, which can be used if the ALTO client is
  embedded in the resource consumer.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-alto-server-discovery/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1952/