[writing with no Area Director hat on, i.e., as a random community member]
Hi Richard, all,
On 07/02/2012 08:38 AM, Richard Alimi wrote:
[...]
REQ. ARv14-4: Full compliant : 7.5.3.3.1., 7.5.3.3.2.
REQ. ARv14-5: An ALTO client protocol MUST be extensible to enable
support of other host group descriptor types in future. An ALTO
client protocol specification MUST define an appropriate procedure
for adding new host group descriptor types, e.g., by establishing an
IANA registry.
REQ. ARv14-5: Partially compliant : 7.5.3.1 says: "Extension documents
may define additional Address Types." but it does not define what
kind of document is required (just an Internet-Draft, or
Informational RFC, ...)
It needs something more than just an I-D since that is a pretty low bar.
You can specify 'protocol specification' or 'expert review' as the bar
for an extension.
See also RFC 5226 for a discussion of this:
http://tools.ietf.org/html/rfc5226
Do people think a registry is needed for this? If not, perhaps we can
just make this more explicit that it needs to be a standards-track
RFC.
There should be a registry where you can add additional address types.
Otherwise it is really hard to get new address types in a clean way into
the protocol.
A registry allows also to keep track about all existing address types
(out of the ALTO protocol and what comes later on).
REQ. ARv14-6: For host group descriptor types other than "IPv4
address prefix" and "IPv6 address prefix", the host group descriptor
type identification MUST be supplemented by a reference to a
facility, which can be used to translate host group descriptors of
that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping
table or an algorithm.
REQ. ARv14-6: Partially compliant, with comment: In addition
to IPv4/6 addresses/prefixes the document only defines one
host group descriptor type, namely PIDs. The mapping mechanism
from IP prefixes to PIDs ("Network Map") is described in
4. and 7.7.1.1.
The document allows the definition of additional host group
descriptor types by means of extension documents (see ARv14-5),
but it does not mention the mapping mechanism for them at all.
I propose:
1.) add a clarification in section 7.5.3.1 that the extension
documents not only have to define new Address Types but also
an appropriate mapping mechansim.
At least in the initial discussions of ALTO, there was mention about
using these for addresses other than IP addresses, such as e.164
numbers. That said, I haven't seen any concrete use cases for
anything other than IP addresses or things that can map to IP
addresses.
I don't intend to start a debate on the requirements document at this
stage, but I'm a bit hesitant to say that extensions MUST do this. I
completely agree that those proposing extensions should be thinking
about this, but tend to think that MUST is too strong. How about
extending 7.5.3.1 to state "extension documents defining a new Address
Type SHOULD also document a mechanism to map addresses of the new type
to IPv4 and/or IPv6 addresses prefixes."
A SHOULD is fine, as it implies that people must say why they are not
specifying a mapping mechanism.
2.) maybe we should spend a moment and think about whether
the base protocol needs at least some basic infrastrucure (e.g.,
pre-defined path names, or a standard algorithm to be execuded if a
TypedEndpointAddr of unknown type is encountered, etc.) that
makes defining such a mapping mechanism easier.
Do you have any thoughts on what this might look like?
An appropriate error message with a path name delivered through this
would good. However, this is just a proposal.
3.) should section 9.4. stay in the document? It discusses
alternatives for mapping IP to ASN - if we can't decide that
we want to specify exactly one of these alternatvies and add
it to the base protocol, it is probably better to move the whole
section to our deployment considerations document.
Moving this to the deployment considerations document sounds reasonable to me.
+1
REQ. ARv14-7: Protocol functions for mapping other host group
descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and
specified as part of an ALTO client protocol, and the corresponding
address mapping information SHOULD be made available by the same
entity that wants to use these host group descriptors within an ALTO
client protocol. However, an ALTO server or an ALTO client MAY also
send a reference to an external mapping facility, e.g., a translation
table to be obtained via an alternative mechanism.
[...]
REQ. ARv14-23: Partially compliant: Network Map Version Tag defined
in 5.3. TTL attribute defined in the underlying HTTP
("expires"/"s-maxage" headers).
There used to be an own section "8. Redistributable Responses"
in draft-ietf-alto-protocol-10.txt, which has been removed in -11
There is a reference to draft-gu-alto-redistribution-03, which
has expired January 13, 2011, and which does not contain a
specification of such protocol elements.
I tend to think it's best to leave this one as partially compliant for
now, and leave the additional expiration field for when there is an
extension to support redistribution (the section that was removed in
-11). Any disagreement with that?
Not from my side.
REQ. ARv14-24: An ALTO client protocol SHOULD allow the ALTO server
to add information about appropriate modes of re-use to its ALTO
responses. Re-use may include redistributing an ALTO response to
other parties, as well as using the same ALTO information in a
resource directory to improve the responses to different resource
consumers, within the specified lifetime of the ALTO response. The
ALTO server SHOULD be able to express that
o no re-use should occur
o re-use is appropriate for a specific "target audience", i.e., a
set of resource consumers explicitly defined by a list of host
group descriptors. The ALTO server MAY specify a "target
audience" in the ALTO response, which is only a subset of the
known actual "target audience", e.g., if required by operator
policies
o re-use is appropriate for any resource consumer that would send
(or cause a third party sending on behalf of it) the same ALTO
query (i.e., with the same query parameters, except for the
resource consumer ID, if applicable) to this ALTO server
o re-use is appropriate for any resource consumer that would send
(or cause a third party sending on behalf of it) the same ALTO
query (i.e., with the same query parameters, except for the
resource consumer ID, if applicable) to any other ALTO server,
which was discovered (using an ALTO discovery mechanism) together
with this ALTO server
o re-use is appropriate for any resource consumer that would send
(or cause a third party sending on behalf of it) the same ALTO
query (i.e., with the same query parameters, except for the
resource consumer ID, if applicable) to any ALTO server in the
whole network
REQ. ARv14-24: Partially compliant: first and last option supported
by HTTP mechanisms. Second and third option relied on the now-removed
section 8 of draft-ietf-alto-protocol-10
Yeah - I'm personally okay with this current state, since we
consciously removed the section on Redistribution and left that for an
extension.
If we allow to be partially compliant, we should at least note that the
missing points are part of a future redistribution mechanism and
therefore not specified in the current ALTO protocol.
REQ. ARv14-25: An ALTO client protocol MUST support the transport of
ALTO transactions even if the ALTO client is located in the private
address realm behind a network address translator (NAT). There are
different types of NAT, see [RFC4787] and [RFC5382].
REQ. ARv14-25: Full compliant: The ALTO protocol is based on HTTP
(Sec. 6). Allowing HTTP traffic is one of the most basic requirements
for all types of NAT. For detection of "public" IP address see 9.3.
3.1.5. Protocol Extensibility
REQ. ARv14-26: An ALTO client protocol MUST include support for
adding protocol extensions in a non-disruptive, backward-compatible
way.
REQ. ARv14-26: Full compliant: 10.1
The use of JSON and Section 7.2.7 also helps with extensions.
REQ. ARv14-27: An ALTO client protocol MUST include protocol
versioning support, in order to clearly distinguish between
incompatible versions of the protocol.
REQ. ARv14-27: NOT compliant. There is no version field.
7.6. states: "Future extensions or
versions of the ALTO Protocol SHOULD be accomplished by extending
existing media types or adding new media types, but retaining the
same format for the Information Resource Directory."
As workaround, one could define new media types such as
alto-directory_v2_0+json or
alto2-directory+json
Yeah. There was a discussion when going to the REST-ful approach
about whether we wanted any explicit version numbers or not. The idea
was that we didn't need an ALTO version number exposed to applications
if we used media types appropriately. Using media types like you
suggested is certainly one approach.
Irrespectively of what mechanisms is being used, this protocol needs
versioning support. However, I'm not sure that media-types are the best
way forward for this.
What would be a different approach when using media types?
3.1.6. Error Handling and Overload Protection
REQ. ARv14-28: An ALTO client protocol MUST use TCP based transport.
REQ. ARv14-28: Full compliant. Protocol is based on HTTP (6.), which
does not neccessarily run on top of TCP (see 1.4. of RFC 2616), but
de-facto always does.
side note: IESG evaluation of the requirements document likely will
result in this requirement being changed to something like:
REQ. ARv15-28 An ALTO client protocol MUST use a congestion-aware
transport protocol, e.g., TCP.
but this will not cause any problem here.
REQ. ARv14-29: An ALTO client protocol specification MUST specify
mechanisms, or detail how to leverage appropriate mechanisms provided
by underlying protocol layers, which can be used by an ALTO server to
inform clients about an impending or occurring overload situation,
and request them to throttle their query rate.
In particular, a simple form of throttling is to let an ALTO server
answer a query with an error message advising the client to retry the
query later (e.g, using a protocol function such as HTTP's Retry-
After header ([RFC2616], section 14.37). Another simple option is to
actually answer the query with the desired information, but adding an
indication that the ALTO client should not send further queries to
this ALTO server before an indicated period of time has elapsed.
REQ. ARv14-30: An ALTO client protocol specification MUST specify
mechanisms, or detail how to leverage appropriate mechanisms provided
by underlying protocol layers, which can be used by an ALTO server to
inform clients about an impending or occurring overload situation,
and redirect them to another ALTO server.
REQ. ARv14-31: An ALTO client protocol specification MUST specify
mechanisms, or detail how to leverage appropriate mechanisms provided
by underlying protocol layers, which can be used by an ALTO server to
inform clients about an impending or occurring overload situation,
and terminate the conversation with the ALTO client.
REQ. ARv14-32: An ALTO client protocol specification MUST specify
mechanisms, or detail how to leverage appropriate mechanisms provided
by underlying protocol layers, which can be used by an ALTO server to
inform clients about its inability to answer queries due to technical
problems or system maintenance, and advise them to retry the query
later.
REQ. ARv14-33: An ALTO client protocol specification MUST specify
mechanisms, or detail how to leverage appropriate mechanisms provided
by underlying protocol layers, which can be used by an ALTO server to
inform clients about its inability to answer queries due to technical
problems or system maintenance, and redirect them to another ALTO
server.
REQ. ARv14-34: An ALTO client protocol specification MUST specify
mechanisms, or detail how to leverage appropriate mechanisms provided
by underlying protocol layers, which can be used by an ALTO server to
inform clients about its inability to answer queries due to technical
problems or system maintenance, and terminate the conversation with
the ALTO client.
REQ. ARv14-29..34: Partially compliant: The protocol is based on HTTP,
which features various appropriate protocol mechanisms (R-A header,
3xx and 503 replies, etc.), but no specific guidance is provided
when and how to use them in conjunction with the ALTO protocol.
We also had a discussion about this in the protocol overhaul for
making it REST-ful. The guidance we received there was to not repeat
details from RFC2616. I'm not sure I see much utility in adding
specifics in the ALTO protocol document, since it would basically
amount to saying "If you think you are overloaded, you are free to
return a 503." Then, if we were to add that, people would ask "you
gave me guidance on using 503, but you didn't tell me when I should or
should not use chunked transfer encoding.. how about that??" The idea
was that the statements in Section 7.2, as well as some intelligence
on behalf of implementers on how to apply RFC2616, would answer all of
these questions.
That is not a good way of specifying things. There is no need to say how
a 503 response looks like, but it is definitely good to say when an ALTO
protocol must reply with such a code. "intelligence ...of implementers"
will cause ALTO protocol implementations that do not interoperate.
3.2. ALTO Server Discovery
REQ. ARv14-35..42: not applicable to this document
3.3. Security and Privacy
REQ. ARv14-43: An ALTO client protocol specification MUST specify
mechanisms for the authentication of ALTO servers, or how to leverage
appropriate mechanisms provided by underlying protocol layers.
REQ. ARv14-43: Full compliant: 7.2.5.
REQ. ARv14-44: An ALTO client protocol specification MUST specify
mechanisms for the authentication of ALTO clients, or how to leverage
appropriate mechanisms provided by underlying protocol layers.
REQ. ARv14-44: Full compliant: 7.2.5.
REQ. ARv14-45: An ALTO client protocol specification MUST specify
mechanisms for the encryption of messages, or how to leverage
appropriate mechanisms provided by underlying protocol layers.
REQ. ARv14-45: Full compliant: 7.2.5.
REQ. ARv14-46: An ALTO client is not required to implement
mechanisms or to comply with rules that limit its ability to
redistribute information retrieved from the ALTO server to third
parties.
REQ. ARv14-46: not applicable to this document. See also sec. 11.3.:
"Digital Rights Management (DRM) techniques and legal agreements
protecting ALTO information are outside of the scope of this
document."
REQ. ARv14-47: An ALTO client protocol MUST support different levels
of detail in queries and responses, in order to protect the privacy
of users, to ensure that the operators of ALTO servers and other
users of the same application cannot derive sensitive information.
REQ. ARv14-47: Full compliant. Host Group Descriptors are always
encoded as TypedEndpointAddr, which allows to use IP prefixes.
Therefore it is possible to obfuscate the identity of candidate
resource consumers, e.g., by specifying a broader address range
(i.e., a shorter prefix length) than a group of hosts in question
actually uses, or by zeroing-out or randomizing the last few bits of
IP addresses. However, there is the potential side effect of
yielding inaccurate results.
REQ. ARv14-48: An ALTO client protocol MAY include mechanisms that
can be used by the ALTO client when requesting guidance to specify
the resource (e.g., content identifiers) it wants to access. An ALTO
server MUST provide adequate guidance even if the ALTO client prefers
not to specify the desired resource (e.g., keeps the data field
empty). The mechanism MUST be designed in a way that the operator of
the ALTO server cannot easily deduce the resource identifier (e.g.,
file name in P2P file sharing) if the ALTO client prefers not to
specify it.
REQ. ARv14-48: Full compliant. The optional ("MAY") feature is not
defined and therefore, the MUST-statements do not apply.
REQ. ARv14-49: An ALTO client protocol specification MUST specify
appropriate mechanisms for protecting the ALTO service against DoS
attacks, or how to leverage appropriate mechanisms provided by
underlying protocol layers.
REQ. ARv14-49: Partially compliant: The protocol is based on HTTP,
and protecting HTTP-based services against different kinds of
attacks, including DoS attacks, is a rather well-understood issue.
However, no specific guidance is provided for ALTO over HTTP.
Agree. See comment above.
Give at least guidance where to read on to protect against such threads.
Otherwise this specification is incomplete.
Martin
--
[email protected]
NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
