[alto] Murray Kucherawy's No Objection on draft-ietf-alto-new-transport-17: (with COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 26 October 2023 07:32 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-alto-new-transport@ietf.org, alto-chairs@ietf.org, alto@ietf.org, mohamed.boucadair@orange.com
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <169830557336.699.7350278342925762782@ietfa.amsl.com>
Date: Thu, 26 Oct 2023 00:32:53 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/HTc49OUtulkiY_jVRGBCYeA-2R8>
Subject: [alto] Murray Kucherawy's No Objection on draft-ietf-alto-new-transport-17: (with COMMENT)

Murray Kucherawy has entered the following ballot position for
draft-ietf-alto-new-transport-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Spencer Dawkins for his two ARTART reviews.

The answer to question #11 in the shepherd writeup is incomplete.

I support Francesca's DISCUSS position. To answer her question about media
types, I must admit I'm at a loss to understand this object notation and how it
relates to a JSON payload. A reference to decoding it would be helpful. My
best guess is that this one media type will be used for both cases, the payload
will be something in JSON format in either case, and a consumer infers the
semantics of the payload based on inspection of its structure, presumably
returning an error if something unexpected is found. However, this seems
peculiar in the context of media types; I would prefer to see such division
done using a parameter to the media type rather than inspection, since the
whole idea of labeling a payload with a media type is to know what it is you're
holding before you start doing something with it.

The SHOULDs in 6.2 are bare. When might one legitimately deviate from that
advice? If no such reason exists, why aren't they MUSTs? Same question about
the SHOULDs in 4.1 and 8.5.

Regarding Sections 10.1 and 10.2, I suggest reviewing RFC 8126 for what's
expected in "Interoperability Considerations".

[alto] Murray Kucherawy's No Objection on draft-i… Murray Kucherawy via Datatracker