From nobody Wed Apr 26 07:27:29 2023 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA52C151532 for ; Wed, 26 Apr 2023 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yale.edu Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0lVE68JxwIf for ; Wed, 26 Apr 2023 07:27:22 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9E1C151555 for ; Wed, 26 Apr 2023 07:27:22 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-95f4c5cb755so103758766b.0 for ; Wed, 26 Apr 2023 07:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; t=1682519240; x=1685111240; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=5qEFVLKpy6zbP1wk67v9xeVbxxoURghnJO2xKP/r2fA=; b=cype0JM4jYWxeDlku3VetgkTYwMe1tjt4sQnxn9KA7Zag+6yLjnUaDct3PEu7PpqJi 6gW8TKBsocaU+c9tW0BVuzxTCJbMoUrxW3ehWs7OFtNEHCrFxKZOBPVAG9RTqpDXJM0j ToaWvkPrLRlza5quSHYXvjMw5TKSWUiNKz4LI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682519240; x=1685111240; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=5qEFVLKpy6zbP1wk67v9xeVbxxoURghnJO2xKP/r2fA=; b=ZWfybFRc84ETCqpC5ZkayRiY5mzgUr8Fd9xzHE284dMPzJnLGCalm+Kkc34UzwaHm8 dSO5JjJ/OBz8tF/pr/WNBc6TKgThPANFcXmw4DJjqhG9KpdBEsHFPEBaPkojhdnlbuqV ExqoI4LGgNwQXaxTDyu1RO/AngUL8D3caZJUcorG1QqIu18iGpIlsKH8IZqByShoFRLF EqDO8syMEKKWUVDjoc0K7jH8LRMX/t3Hp3hroRC44+8XzlS8Sl8omMIFbEdNhU8F7zH3 Wedq2ASiAIrF2F4042CNsjvlYRJDNMjrnO1a6lSq1k3MOFAyA9kAMRKMP4Z9yz9pQFvb tbAA== X-Gm-Message-State: AAQBX9fOftYWdf+5WPPacjAkTd5jd9zm2gzolwyplyQSLseqvVrpWG+t KhNo1ckTwPATmanQPvT3LJit7Ym4NQfS82l/rGQhWA== X-Google-Smtp-Source: AKy350Zqzaslr9gJZRqAq3YUWF1qSrwoxamuNeR0EQcB8tKCok56pjX6oSDpJZb2yzOgBlzduHeRahPclDHD9dQEfFk= X-Received: by 2002:a17:906:3159:b0:957:17c5:8705 with SMTP id e25-20020a170906315900b0095717c58705mr16326511eje.51.1682519240619; Wed, 26 Apr 2023 07:27:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lachlan Keller Date: Wed, 26 Apr 2023 10:26:53 -0400 Message-ID: To: "russ@riw.us" Cc: alto-wg-chairs@ietf.org, draft-ietf-alto-new-transport.all@ietf.org, rtg-dir@ietf.org, alto@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa8ff405fa3e09d4" Archived-At: Subject: Re: [RTG-DIR] Subject: RtgDir Early review: draft-ietf-alto-new-transport-07 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2023 14:27:26 -0000 --000000000000aa8ff405fa3e09d4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Russ, Thank you again for your review of this document. We wanted to check in to see if the proposed change below addresses your nit comment? Best, Lachlan On Thu, Mar 30, 2023 at 5:58=E2=80=AFPM Lachlan Keller wrote: > Hi Russ, > > Thank you so much for taking a thorough look at this. > > With regards to the nit comment, data does not not necessarily need to be > pushed in the correct order, only the client must apply the patches in th= e > correct order, given how JSON merge patch functions. For example, over an > HTTP/3 connection, a client can concurrently request multiple update > patches at the same time, with the possibility that they will be received > out of order. The client should buffer the update items and then apply th= em > in the order that the sequence number indicates. > > We=E2=80=99ve now added a paragraph in Section 8.4 (Considerations for Cl= ient > Processing Updates) to address this: > Though a server SHOULD send update items sequentially, it is possible > that a client receives the update items out of order (in the case of a > retransmitted update item or a result of concurrent fetch). The client > MUST buffer the update items if they arrive out of order and then apply > them sequentially (based upon the sequence numbers) due to the operation = of > JSON merge patch and JSON patch. > > Best, > Lachlan > > > On Thu, Mar 30, 2023 at 9:51=E2=80=AFAM russ@riw.us wrote: > >> Hello >> >> I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D= review of this >> draft. >> https://datatracker.ietf.org/doc/draft-ietf-alto-new-transport/ >> >> The routing directorate will, on request from the working group chair, >> perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submit= ted for >> publication to the IESG. The early review can be performed at any time >> during the draft=E2=80=99s lifetime as a working group document. The pur= pose of >> the early review depends on the stage that the document has reached. >> >> As this document is in working group last call, my focus for the review >> was to determine whether the document is ready to be published. Please >> consider my comments along with the other working group last call >> comments. >> >> For more information about the Routing Directorate, please see >> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >> >> Document: draft-ietf-alto-new-transport-07 >> Reviewer: Russ White >> Review Date: 30 March 2023 >> Intended Status: Standards >> >> Summary: >> >> This document is basically ready for publication, but has nits that >> should be considered prior to being submitted to the IESG. >> >> Comments: >> >> This draft covers a complex protocol and use cases. I had to go back and >> read the previous drafts and other documents to get a good perspective >> on these use cases. Given the inherent complexity, this draft is well >> written, and gives good explanations of the solution proposed. The >> example given towards the beginning of the document was very helpful. >> >> Nits: >> >> This document assumes data will be pushed in the correct order, but it >> doesn't seem to say this is a requirement. Since the document is dealing >> with changes to a network topology (for instance), it seems like this >> would be a requirement to mention someplace. It could be that I missed >> this requirement, however. >> > --000000000000aa8ff405fa3e09d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Russ,

Thank you aga= in for your review of this document. We wanted to check in to see if the pr= oposed change below addresses your nit comment?

Be= st,
Lachlan

On Thu, Mar 30, 2023 at 5:58=E2=80=AFPM Lachlan = Keller <lachlan.keller@yale.e= du> wrote:
Hi Russ,

Thank you so much for taking= a thorough look at this.=C2=A0

With regards to the nit= comment, data does not not necessarily need to be pushed in the correct or= der, only the client must apply the patches in the correct order, given how= JSON merge patch functions. For example, over an HTTP/3 connection, a clie= nt can concurrently request multiple update patches at the same time, with = the possibility that they will be received out of order. The client should = buffer the update items and then apply them in the order that the sequence = number indicates.
=C2=A0
We=E2=80=99ve now added a paragraph in Sec= tion 8.4 (Considerations for Client Processing Updates) to address this:<t>Though a server SHOULD send update items sequentially, it is poss= ible that a client receives the update items out of order (in the case of a= retransmitted update item or a result of concurrent fetch).=C2=A0 The clie= nt MUST buffer the update items if they arrive out of order and then apply = them sequentially (based upon the sequence numbers) due to the operation of= JSON merge patch and JSON patch.</t>

Best,<= /div>
Lachlan
=C2=A0

On Thu, Mar 30, 2023 at 9:51=E2= =80=AFAM russ@riw.us &= lt;russ@riw.us> wro= te:
Hello

I have been selected to do a routing directorate =E2=80=9Cearly=E2=80=9D re= view of this
draft.
https://datatracker.ietf.org/doc/draf= t-ietf-alto-new-transport/

The routing directorate will, on request from the working group chair,
perform an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted= for
publication to the IESG. The early review can be performed at any time
during the draft=E2=80=99s lifetime as a working group document. The purpos= e of
the early review depends on the stage that the document has reached.

As this document is in working group last call, my focus for the review was to determine whether the document is ready to be published. Please
consider my comments along with the other working group last call
comments.

For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

Document: draft-ietf-alto-new-transport-07
Reviewer: Russ White
Review Date: 30 March 2023
Intended Status: Standards

Summary:

This document is basically ready for publication, but has nits that
should be considered prior to being submitted to the IESG.

Comments:

This draft covers a complex protocol and use cases. I had to go back and read the previous drafts and other documents to get a good perspective
on these use cases. Given the inherent complexity, this draft is well
written, and gives good explanations of the solution proposed. The
example given towards the beginning of the document was very helpful.

Nits:

This document assumes data will be pushed in the correct order, but it
doesn't seem to say this is a requirement. Since the document is dealin= g
with changes to a network topology (for instance), it seems like this
would be a requirement to mention someplace. It could be that I missed
this requirement, however.
--000000000000aa8ff405fa3e09d4--