Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)

Vijay Gurbani <vijay.gurbani@gmail.com> Wed, 30 January 2019 22:27 UTC

Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A416130EBD; Wed, 30 Jan 2019 14:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 oO4fG2-i87-b; Wed, 30 Jan 2019 14:27:12 -0800 (PST)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E865C130EB2; Wed, 30 Jan 2019 14:27:11 -0800 (PST)
Received: by mail-ed1-x532.google.com with SMTP id d39so958726edb.12; Wed, 30 Jan 2019 14:27:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mBTuNVr/sTH8bl3ThM2C7MLra/HSJ1JTiEsYMiW2JlQ=; b=A/RRgF1/CWWPrRUN6chCl2rXGKEM6imwzR+7dE8ZjPJKDKMGmVzUJprUcwSgUhjh1T ZOFwAOKDZyCTu7nVdxednyx1bjWHQAj71Cf9OoiUgHTsZTXnMuH7Fi+LY8XYXNct4ySc U/zxyobzfGBfmAjAsCViHZDwct+osw+V7q6RAMcBPnnUzosyOfl4aDY25D4EraslXBZP UuOuGJ7pF9Pv5C1ks2fDuaXrs3wlwPEnL7U6BJ0PCKQY9Z+wmWBMfl2+JFEnWFSQ5PAA HLCLqPS+M/MYFVIE+5gfRGbwI7ckIU6d52LeH/9uwQuBgpaRbHbHb/mH5BOpkB9fjGPl 8/mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mBTuNVr/sTH8bl3ThM2C7MLra/HSJ1JTiEsYMiW2JlQ=; b=XLDE7FbHxIxpSQVvFlwY+93DcTlGrQWN2O255kvArWY6o6licUWKjZbl9A0XxgPDSh HmuNRAZZOlqhvYqouqCIzy4UTJ3QetskzluKTWUd50CcsFmVnBb+pQB5xKUTyHuVCZsq S4kFNqkrxwqBrNG16uegvT6eg8zan8EkWKJgtR6eSinnTlY0JASIsDO8WweTKF7vkPHp cR3tOIJMoFkpzOBCRq+uliqPTAE9fCG4iul4dgPqIhqa0nV+ERVTJVjNWq8FXKhVoWMX Mvhad5oVNVd7lnGCfaXud295wY0bs8uOWXv0i3jBkp6fjvXNhkcyokr/l5L0toxzvgo8 fTbQ==
X-Gm-Message-State: AJcUukdsudbzfob0APP23vv8YrgbzHFiuG+vMiMzktX9ez2G86XGJUIc smlbnLRYE8J5XeHUQnpBexKHXKR2Em3Ghkkyezk=
X-Google-Smtp-Source: ALg8bN77sYDO9CGOyuE/x6jeCf0v+TQWktekrZ8k0yjSIpO5nu2N1KsXI9/P+6zs1GbeOLRhja0Dr0Z1t9l4w/u5hdU=
X-Received: by 2002:a17:906:b2cc:: with SMTP id cf12mr26886656ejb.36.1548887230140; Wed, 30 Jan 2019 14:27:10 -0800 (PST)
MIME-Version: 1.0
References: <154345970393.13521.17177728478340801020.idtracker@ietfa.amsl.com> <AM4PR07MB3236DD059F50035D0F5C8F21959B0@AM4PR07MB3236.eurprd07.prod.outlook.com> <1497dbf3-d057-160b-f81a-bbf6b496d81b@nostrum.com> <AM4PR07MB32366E0069BFE9CD455D012095970@AM4PR07MB3236.eurprd07.prod.outlook.com> <CAOELiNNUUMJCDWoCAUhpwscV3R9VocjPCE6a+icSuVf3DNmyzQ@mail.gmail.com> <022cc047-a7aa-e087-8638-8f9798e4ea91@nostrum.com> <CAOELiNPU-vdOSEWbs4eJyUAqiactSSM7Y3K7GMndNE7St-Ju-w@mail.gmail.com> <20190130161322.GA49072@kduck.mit.edu> <CAOELiNP96Lzn3Ba9vksDe5xWT-OCRD=+2HTcRxLcq4HvpJ19RQ@mail.gmail.com>
In-Reply-To: <CAOELiNP96Lzn3Ba9vksDe5xWT-OCRD=+2HTcRxLcq4HvpJ19RQ@mail.gmail.com>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Wed, 30 Jan 2019 16:26:52 -0600
Message-ID: <CAMMTW_LjfmmPq4GfFUdfT5a-PTtjRXaj2_57DcUmZkrrpRTiDA@mail.gmail.com>
To: Kai GAO <godrickk@gmail.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, Adam Roach <adam@nostrum.com>, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>, The IESG <iesg@ietf.org>, "alto-chairs@ietf.org" <alto-chairs@ietf.org>, "draft-ietf-alto-cost-calendar@ietf.org" <draft-ietf-alto-cost-calendar@ietf.org>, "alto@ietf.org" <alto@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002658820580b469dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/mnckXU3Ks3wYUZc6_oWifVAsai0>
Subject: Re: [alto] Adam Roach's No Objection on draft-ietf-alto-cost-calendar-09: (with COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Jan 2019 22:27:15 -0000

Well, procedurally speaking, if we want to fix the root cause (RFC 7285), I
suspect that we can do so through a RFC that modifies RFC 7285.  Related
questions like how quick can we do that, is it in our charter and if not
how to proceed, etc. are questions that can be attended to once the WG
decides that modifying RFC 7285 would be the best course of action.

Do I get the sense that the WG thinks that this is the best course of
action?  (I must apologize as I am coming up to speed on this issue.  If I
was to produce a 1 sentence summary of the issue here, it is that RFC 8259
normatively requires UTF-8 encoding and that there are existing ALTO
implementations conformant to RFC 7285 that use encodings other than
UTF-8.  Is that accurate?).

Thanks,

- vijay

On Wed, Jan 30, 2019 at 3:29 PM Kai GAO <godrickk@gmail.com>; wrote:

>
> Hi Benjamin,
>
> Thanks for the reply.
>
> DISCLAIMER: I'm only speaking on behalf of myself.
>
> Well, the situation is that we don't know the answer to the key question
> at the moment and probably also in the near future.
> Thus, the problem at hand is "how do we proceed if we don't know the
> answer".
> My personal opinion is that ALTO should be self-contained so the principle
> is that extensions should not conflict with the base protocol.
> So instead of patching every draft, why don't we just patch the root cause
> (RFC 7285)?
>
> However, I don't really know if this is the best practice in IETF.
> Since you and Adam are the experts here, we would like very much to
> leverage your expertise a bit and hear your opinions on this procedural
> problem.
> (I imagine the implication is that we should not proceed until we find out
> the answer?)
>
> Back to the encoding. If UTF-8 is the de facto JSON encoding in JSON
> libraries, as Adam pointed out, I don't see why it would not be for ALTO
> usage.
> I don't truly believe there would be a nontrivial amount of developers who
> use an 18-century JSON library or reinvent the wheel just to be
> interoperable with ALTO.
>
> Just my 2 cents.
>
> Best,
> Kai
>
>
>
>
> On Thu, Jan 31, 2019 at 12:13 AM Benjamin Kaduk <kaduk@mit.edu>; wrote:
>
>> On Wed, Jan 30, 2019 at 12:44:43PM +0800, Kai GAO wrote:
>> > Hi Adam,
>> >
>> > Thanks for the clarification. Regarding the situation, I wonder if the
>> > following procedure makes sense:
>> >
>> > 1. Extensions of the ALTO protocol should not explicitly cite a specific
>> > (especially the obsoleted) JSON RFC but "follow the same JSON format as
>> in
>> > the base protocol (RFC 7285)".
>> > 2. Charter a draft to clarify the impacts of new JSON (and probably TLS
>> > too) standards on all ALTO-related RFCs.
>> >
>> > Or maybe we should have a standard paragraph stating the situation and
>> put
>> > it in every ALTO extension?
>> >
>> > What do you think?
>>
>> This seems to be sidestepping the key question, of whether UTF-8 is
>> actually the de facto interoperable JSON encoding for ALTO usage, or
>> whether there is nontrivial usage of other encodings.  It seems a little
>> odd to consider procedural options without knowing what the right answer
>> is.
>>
>> -Benjamin
>>
>