Re: [secdir] secdir review of draft-ietf-alto-protocol

"Y. Richard Yang" <yry@cs.yale.edu> Mon, 17 February 2014 22:17 UTC

Return-Path: <yang.r.yang@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45991A04ED; Mon, 17 Feb 2014 14:17:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_alj70KsY51; Mon, 17 Feb 2014 14:17:17 -0800 (PST)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF5D1A040A; Mon, 17 Feb 2014 14:17:17 -0800 (PST)
Received: by mail-pd0-f179.google.com with SMTP id fp1so15073266pdb.10 for <multiple recipients>; Mon, 17 Feb 2014 14:17:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TMwIFpOCz7ce16SqeitoWs79WSoA2IZjuSCsmYkBSfw=; b=JhrcS0ckbHaktLR6Sw7BkJEsXtkBrKbyB3jWaDV/1zfKePU/Am7BwtbrxZ2GwnIjnE KnG756nkMp+0/FJQp96ygyIcEt2LKIYfPMy43lgcpOrKbsIFDBuv2TxiCIz1P97Tz31H 3qhGHDjVy1A/mOPpRdCU+xKFyj6UUw+GARkYPewuZHHzLNR0cpuQBTlvzty4lA4EKngg hbyLA65ym4QaoJ/oF6154jg1uiwandx+gGAV/ef1SeXI4fB69vftAOgqhtgXgLGEL8P6 AeaT4X4sBBXbRJf9P7jF0a4eLrMTbkml8ylktXD+Cpw/Jpn4pjm7OoL82TdH4pVfESx0 AnzQ==
MIME-Version: 1.0
X-Received: by 10.66.159.132 with SMTP id xc4mr28712375pab.27.1392675434564; Mon, 17 Feb 2014 14:17:14 -0800 (PST)
Sender: yang.r.yang@gmail.com
Received: by 10.68.144.168 with HTTP; Mon, 17 Feb 2014 14:17:14 -0800 (PST)
In-Reply-To: <CADOmCZWK80noyc83GrDSWVw6TKyHxW8z_K5QBoSxDiAc7pBXKA@mail.gmail.com>
References: <cd3fb9f2748d08183af6652c0d58f61a.squirrel@www.trepanning.net> <CADOmCZU7uxA8RyK7LUy2D1Op4nhVEt_Y1JxGHNCzRvpFgGbh+g@mail.gmail.com> <2910582168899709b7211d3cea87c29d.squirrel@www.trepanning.net> <CADOmCZWK80noyc83GrDSWVw6TKyHxW8z_K5QBoSxDiAc7pBXKA@mail.gmail.com>
Date: Mon, 17 Feb 2014 17:17:14 -0500
X-Google-Sender-Auth: 5eyD31LmbCc2Es6FcE37q6rGNCc
Message-ID: <CANUuoLo+z0U1VhxDaTRQyrxkdeUDvR0t0OkDhp3OWxngLX6v+Q@mail.gmail.com>
From: "Y. Richard Yang" <yry@cs.yale.edu>
To: Richard Alimi <ralimi@google.com>
Content-Type: multipart/alternative; boundary=047d7b6d7a1090939104f2a1848b
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/MmhQ1pMKE868T-6MJadVL6u1uFA
X-Mailman-Approved-At: Mon, 17 Feb 2014 14:28:18 -0800
Cc: secdir@ietf.org, "draft-ietf-alto-protocol.all@tools.ietf.org" <draft-ietf-alto-protocol.all@tools.ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-alto-protocol
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 22:17:19 -0000

Dan, Richard A.

On Mon, Feb 17, 2014 at 4:10 PM, Richard Alimi <ralimi@google.com>; wrote:
>
>
> On Mon, Feb 17, 2014 at 6:26 AM, Dan Harkins <dharkins@lounge.org>; wrote:
>
>>
>>   Hi Richard,
>>
>> On Sun, February 9, 2014 10:58 pm, Richard Alimi wrote:
>> > Thank you very much for the review!
>> >
>> > Responses inline...
>> >
>> >
>> > On Sat, Feb 1, 2014 at 10:54 AM, Dan Harkins <dharkins@lounge.org>;
>> wrote:
>> >
>> >>
>> [snip]
>> >>   - 6.1.2, while a particular Cost Map may contain only one of the
>> >>      two cost modes, servers MUST implement support for both,
>> >>      right? It's not clear from the text.
>> >>
>> >
>> > Servers only need to implement at least one, but not necessarily both.
>> >  Section 6.1.2 states the following:
>> >
>> >
>> >    An ALTO Server MUST support at least one of 'numerical' and 'ordinal'
>> >    modes.
>> >
>> >
>> > Can you suggest which text was misleading so that we can address it?
>>
>>   It's not clear to me how this interoperates unless it's possible to
>> infer
>> one from the other and if that's the case then why are there two things
>> to choose to support?
>>
>
> The key is that the client needs to handle both types, not the server.
>  During working group discussions, it was not clear that a server would
> always wish to provide both and may opt to expose one or the other.
>
> For example, one cited reason for a server not exposing numerical costs
> was concerns over revealing too many details of internal network topology.
>
> It is possible to derive ordinal costs from numerical costs.  Thus, we
> could require servers to provide ordinal costs and optionally provide
> numerical costs.  We opted to put this logic in the client-side, though, in
> the interest of keeping the server simpler.
>
> Richard/Reinaldo: do you believe this is still a reasonable tradeoff and
> am I missing any other rationale for this?  I'm typically on the side of
> keeping servers simpler, but we could reconsider if necessary.
>

I remember extensive discussions on the two modes. Given the dependency
between the numerical and the ordinal modes (one can derive the ordinal
from numerical but not the other way around), we can say that the ordinal
mode is always provided, either implicitly (only numerical) or explicitly
(when both are provided). This will allow interop.

At the same time, the discussion was that we do not enforce the explicit
approach to keep the Server simple, as Richard A. mentioned. Also, the less
redundancy at the source (maintaining both numerical and ordinal), the less
likely we encounter inconsistency.

Richard