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

Kai GAO <godrickk@gmail.com> Wed, 30 January 2019 04:44 UTC

Return-Path: <godrickk@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 A796B127B4C; Tue, 29 Jan 2019 20:44:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 MbvBNgBj4Yst; Tue, 29 Jan 2019 20:44:57 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 EEA41124BF6; Tue, 29 Jan 2019 20:44:56 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id v205so13479357vsc.3; Tue, 29 Jan 2019 20:44:56 -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=ENdPRiOcI0DLxS3ktsQVlq47ysK125m2x7Bgz4t5kck=; b=ez9B+FK5lO+G/YUpDoiDb2TijHnhdKP1UKqpqTzt1fJCM+RhsjWTu/+06gPjpbKHqa tyjqB7zYNqKFsDcoux0yMKvBYZ640QV7iJtSu2mi9Mrxxz5pSbNjolZ9WUaFvlJI5Kyu O/0/LVL4HGSBOwYBvRhm2zBWNE4YGBMUMLitWZ+3cc+wF0PSwvtTHykV8FaXtlCmyEhR 5HW/ZsVA02NodgPemuuw2J2ab/kj5hVr43i92Qj/ozE24BxhpP5kjP5npOpi0HtUdvBq ZFAaE1x3OZN9SkiYKCqqUbOnfaPK4v2NWPihdWGzf5XgJxV1qiMsYoC0eu85skEo7872 J/jA==
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=ENdPRiOcI0DLxS3ktsQVlq47ysK125m2x7Bgz4t5kck=; b=HPHCGceHeO7oMXZkXfM+v9RfGCZ56MBrtghv9MNFfhqxuxO/ZI41NWUycwCKL1+Gug rV0otXdwDf5PmQFqn1l0Au5Rwel3lt+5cNkwcjN2e9fWhCnXBicqV6LwEDX4wZIQmvvX im5vmx/dPDLkdSw64j0kRNchDTs/3KQUhSz9cVixBcb1HkfTw9JHTKLRrDS+tqsCqjhc WlRQLgjZw+XC5X7c7XIObp9CphdBN3oXHdBQ1rDz68t2TCcz6zsS0WaFIEAxNfRR/T12 /kNzIKTtiYNpPNa3+vTrgCm3eWZ61cswMxhtyifMkpGPgytCndQfbwJyeNEJzbkKHHxy oTUg==
X-Gm-Message-State: AJcUukfkXL6S5AsOPOeEGvkjvzcpBfP+KqXgQUmJQ5rCU3/QRi8M9euD AYZKLJRGGt5akMS0LKh5vfdUI41WPzi5P7TACfI=
X-Google-Smtp-Source: ALg8bN4K581DHiTtsOHPblCna4KQP4kKByRQedeFDjzIl9QocNI1kOaCJE8TdjuLl7GVoMyuOuJr2NTjNgb9gLjnWB4=
X-Received: by 2002:a67:7106:: with SMTP id m6mr12552716vsc.67.1548823495744; Tue, 29 Jan 2019 20:44:55 -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>
In-Reply-To: <022cc047-a7aa-e087-8638-8f9798e4ea91@nostrum.com>
From: Kai GAO <godrickk@gmail.com>
Date: Wed, 30 Jan 2019 12:44:43 +0800
Message-ID: <CAOELiNPU-vdOSEWbs4eJyUAqiactSSM7Y3K7GMndNE7St-Ju-w@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <sabine.randriamasy@nokia-bell-labs.com>, The IESG <iesg@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "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="00000000000048a4660580a59258"
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/IdSyIV_Vy31ETJWH34cbVpxX2IU>
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 04:45:00 -0000

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?

Best,
Kai


On Wed, Jan 30, 2019 at 3:30 AM Adam Roach <adam@nostrum.com>; wrote:

> On 1/29/19 12:52 PM, Kai GAO wrote:
>
> Hi Adam and Benjamin,
>
> It appears to me that the JSON format is not specific to the cost calendar
> but a general problem with all ALTO extensions (or even all protocols
> encoded in JSON).
>
> I wonder if we have some kind of "best practice" in situations like this.
> For example, how do other protocols handle this if they originally cited
> RFC 7159?
>
>
> I can't offhand think of a protocol in a similar situation regarding JSON.
> In other similar cases, the course of action has been somewhat dependent on
> the nature of the changes between an older draft and a draft that obsoletes
> it. In many cases, changes are backwards-compatible, and I think there's an
> implicit assumption that new implementations will automatically make use of
> the newer document.
>
> In other cases where there have been breaking changes, I've seen working
> groups issue new clarification documents to "clean up" the discrepancy. For
> example, when RFC 6665 replaced RFC 3265, the SIPCORE working group created
> RFC 7647 to clarify the impact of those changes on RFC 3515. It wouldn't be
> unreasonable for ALTO to do something similar.
>
>
> Since you guys are more senior in the IETF, do you happen to know any RFC
> in a similar situation? I think that would be extremely helpful so we don't
> have to get into this fight for other on-going ALTO drafts.
>
>
> The decision made by the JSON working group when creating RFC 8259 was
> that the practice of trying to deal with multiple encodings was problematic
> from an interoperability perspective, and that practical interoperability
> is best achieved by always using UTF-8. The RFC itself attempts to capture
> this rationale:
>
>
>    Previous specifications of JSON have not required the use of UTF-8
>    when transmitting JSON text.  However, the vast majority of JSON-
>    based software implementations have chosen to use the UTF-8 encoding,
>    to the extent that it is the only encoding that achieves
>    interoperability.
>
>
> A decision by the ALTO working group to intentionally use an obsoleted
> version of JSON puts it in the position of reverting consensus established
> by the JSON working group. While this kind of consensus revision is
> possible in the IETF, it needs to be part of the charter of the working
> group that is doing it. Given that ALTO is not chartered to revise JSON
> procedures, this isn't allowable.
>
> If you wanted to normatively cite RFC 8259 and then include non-normative
> text indicating that it is possible that older data might be written in
> UTF-16 or UTF-32, and that implementations might want a configuration
> option that allows reading such formats, I think that would be keeping in
> the spirit of the "part of a closed ecosystem" language in RFC 8259.
>
> /a
>