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

[Richard Alimi <[e-mail]>]

On Mon, Jul 2, 2012 at 8:05 AM, Martin Stiemerling
<[e-mail]> wrote:
> [writing with no Area Director hat on, i.e., as a random community member]

Good to have you back :)

> 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).

Right - okay. We'll add an Address Type registry.  That said, it'd be
really nice to point to an existing registry. I think we'd need the
following for such a registry:
(1) A textual string for an address type itself
(2) A specification (preferably a pointer to one) for how to serialize
and deserialize a textual address of that type.
(3) (maybe, depending on the result of the discussion below) a
statement of how an address type can be mapped into IPv4/v6 addresses.

However, when browsing through the available IANA registries I didn't
see one that really matched those requirements.  Does anyone have a
better option before we go about defining our own?

>>
>>>>     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.

I'll save my reply for your later followup.

>>
>>>
>>>      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.

Sounds good to me.  We can add a note here.

>
>
>>
>>>
>>>>     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?

Do you mean a different approach *than* using media types?  One other
option would be to revert revert back to what we had before, which is
have an explicit field in each and every response.

Here's one pointer to mailing list discussions about protocol
versioning and media types:
  http://www.mail-archive.com/[e-mail]/msg00609.html
I'll note that our AD at the time (Lisa) was one of the people
suggesting we use content negotiation to provide protocol versioning.

My preference would be to not re-hash the merits of protocol
versioning unless we think there is a clear technical advantage over
what we have now.

>>
>>>> 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.

If we want to make revisions here, can you give some guidance on where
we should recommend certain usage of HTTP and where we shouldn't?
Should it be just additional text to ensure that we satisfy the
requirements on overload control, or additional guidance on how to to
employ other parts of HTTP such as transfer encoding, caching, when to
use redirects, etc?

>>>> 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
>
>