Re: [alto] alto-protocol-11 vs. alto-reqs-14

[Martin Stiemerling <[e-mail]>]

[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


-- 
[e-mail]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283