Re: [alto] Zaheduzzaman Sarker's Discuss on draft-ietf-alto-new-transport-17: (with DISCUSS and COMMENT)

2023-11-27 Thread Martin Duke
Two comments: On Tue, Nov 21, 2023 at 7:09 AM Kai GAO wrote: > - I didn't find any explanation of how the "Concurrent, non-blocking update >> > transmission" requirement is meet by the new transport. is this solved by >> the >> use of HTTP/3 with uses QUIC and does not have HOL blocking within

[alto] PCE

2023-11-27 Thread Martin Duke
Hi ALTO, In my email announcing the impending closure of ALTO, I mentioned a number of potential outlets for future work. I neglected to mention PCE , which to me seems to covering a similar problem area. If they haven't already, I would encourage ALTO

[alto] Note to draft authors

2023-10-19 Thread Martin Duke
Please make sure that there has been a reply to all of the Last Call reviews. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

2023-10-19 Thread Martin Duke
id closing TIPS views that have > active polling edge requests or have recently served responses > until clients have had a reasonable interval to request the next update. > > > I will update the document in my evening and post if you think it's OK. > > > Best, > &g

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

2023-10-18 Thread Martin Duke
Let me know if you have issues with those changes. Martin On Tue, Oct 17, 2023 at 6:23 PM wrote: > > > > -Original Messages- > *From:* "Martin Duke" > *Send time:* Tuesday, 10/17/2023 22:45:05 > *To:* kai...@scu.edu.cn > *Cc:* draft-ietf-alto-new-trans

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

2023-10-17 Thread Martin Duke
ld > anticipate that we submit a new I-D enabling that feature :D > This solution works for me, although there's already a section on resource management that's pretty good. I don't like the idea of DELETE being used as some sort of pricing signal -- that seems like abuse of the protocol. >

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

2023-10-13 Thread Martin Duke
duces state at the server. The noise could be mitigated by the next edge request in Sec 7.4. It's all tradeoffs. Those are the thoughts that I have at this point. Any comments or > suggestions are appreciated! > > Best, > > Kai > > -Original Messages- > *From:* "Ma

Re: [alto] AD comments on draft-ietf-alto-new-transport-15

2023-10-12 Thread Martin Duke
. Clients can then request a new TIPS view. I would lean towards (2), but am interested in what you and the team think. Martin Duke On Thu, Oct 12, 2023 at 6:58 AM wrote: > Hi Martin, > > Thanks for the comments. Please see inline. > > Best, > > Kai > > -Ori

[alto] Status of ALTO

2023-09-22 Thread Martin Duke
munity is also welcome to request a side meeting or hackathon slot at future IETFs to further deployment and implementation of existing standards and pioneer development of further extensions. Thanks to everyone for their past, and ongoing, contributions to the internet. Martin Duke Responsible AD

Re: [alto] Paul Wouters' Discuss on draft-ietf-alto-cost-mode-03: (with DISCUSS and COMMENT)

2022-06-02 Thread Martin Duke
I see now that 8.5 of RFC 7285 covers this, so please disregard On Thu, Jun 2, 2022 at 12:07 PM Martin Duke wrote: > I discussed this with Paul. Can we add a sentence about what to do if the > received string is more than 32 characters? > > On Wed, Jun 1, 2022 at 9:24 PM wrote:

Re: [alto] [IANA #1230654] [Errata Verified] RFC7285 (6876)

2022-05-14 Thread Martin Duke
> > > -- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6876 > > > > ------ > > Status: Verified > > Type: Techni

Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)

2022-03-04 Thread Martin Duke
ot update a > Standards Track RFC. It is unlikely IESG will make a new rule for this. > > > > -Qin > > *发件人:* kai...@scu.edu.cn [mailto:kai...@scu.edu.cn] > *发送时间:* 2022年3月4日 15:24 > *收件人:* Martin Duke > *抄送:* Benjamin Kaduk ; IETF ALTO ; > alto-chairs ; The IESG ; > dr

Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-path-vector-22: (with DISCUSS and COMMENT)

2022-03-03 Thread Martin Duke
Ben and Kai, Thanks for calling attention to this problem. In RFC 7285, there is no IANA registry for Cost Mode, because, as you point out Sec 10.5 says the Mode MUST be "ordinal" or "numerical". RFC 8896, though not listed as a

Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

2021-12-20 Thread Martin Duke
Authors, 8312bis is still in the informational references; is this an oversight, or are you arguing that it's not normative? On Mon, Nov 22, 2021 at 8:39 AM Martin Duke wrote: > Good catch! > > I'm not sure that either of these references are actually directly > relevant to the sub

[alto] New chair!

2021-12-06 Thread Martin Duke
Hello ALTO, I'd like to welcome Mohamed Boucadair, of Orange, as the new ALTO chair. This frees Jan to step down at his convenience. When he chooses to do so, we'll thank him properly. Mohamed has not been intimately involved with ALTO, but he will bring significant IETF experience and an

Re: [alto] IESG evaluation results

2021-12-06 Thread Martin Duke
e! A quick reply on performance metrics. >> >> On Fri, Dec 3, 2021 at 1:22 PM Martin Duke >> wrote: >> >>> >>> 2) We will have to do something about performance-metrics. In the >>> telechat, we agreed that metrics collection is out of scope. >&g

[alto] IESG evaluation results

2021-12-03 Thread Martin Duke
The IESG ballot did not go particularly well. Not enough ADs read the drafts to advance any of the documents, which is unfortunate and reflects poorly on the IESG. However, there are numerous useful and straightforward reviews, DISCUSS and otherwise, that we can immediately address. To the

Re: [alto] Lars Eggert's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

2021-11-29 Thread Martin Duke
1. One problem here is that 3649 and 8312 aren't in the references at all, so that should be fixed if we retain the text 2. IMO collection of bandwidth information is out of scope of this document; in general collection of network information is out of scope for ALTO. I viewed the references as

Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

2021-11-22 Thread Martin Duke
, or endpoint to endpoint). > > > > So, it is RFC 8312 in the text, RFC 8312 is vaguely related to TCP > bandwidth > > > > -éric > > > > *From: *Martin Duke > *Date: *Monday, 22 November 2021 at 16:40 > *To: *Eric Vyncke > *Cc: *The IESG , alto-chair

Re: [alto] Éric Vyncke's Discuss on draft-ietf-alto-performance-metrics-19: (with DISCUSS and COMMENT)

2021-11-22 Thread Martin Duke
Thanks Eric, I think you mean RFC 8321? I am in the early stages of AD sponsoring a draft to update that to PS. The authors have the choice of doing a downref or referring to 8321bis and being stuck in the RFCEd queue for a few extra months. On Mon, Nov 22, 2021 at 3:32 AM Éric Vyncke via

[alto] PANRG questions

2021-11-17 Thread Martin Duke
Hello ALTO, Please have a look at this paper in the PANRG about open research questions in path aware networking. https://datatracker.ietf.org/doc/draft-irtf-panrg-questions/ In some ways this document is orthogonal to ALTO, but in others (notably 2.1 and 2.2) ALTO has at least attempted to

[alto] CERN?

2021-11-17 Thread Martin Duke
I've read that ALTO is used for some large data transfers at CERN. Does anyone have a contact there that can talk about this? We're trying to do some promotional material for IETF, and it would be a good testimonial. Thanks, Martin ___ alto mailing list

Re: [alto] Designated Experts

2021-10-26 Thread Martin Duke
Never mind, this is IETF review, so there is no DE needed. On Tue, Oct 26, 2021 at 12:18 PM Martin Duke wrote: > Kai, does this work for you? > > Any other nominations? > > On Mon, Oct 25, 2021 at 10:57 PM Qin Wu wrote: > >> Hi, Martin: >> >> I suggest Kai,

Re: [alto] Designated Experts

2021-10-26 Thread Martin Duke
Kai, does this work for you? Any other nominations? On Mon, Oct 25, 2021 at 10:57 PM Qin Wu wrote: > Hi, Martin: > > I suggest Kai, as the primary, I can be the backup. > > > > -Qin > > *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke > *发送时间:* 2021年

[alto] Designated Experts

2021-10-25 Thread Martin Duke
Who will be the designated experts for the ALTO Cost Source Registry in ietf-alto-performance-metrics? Once I have a couple of volunteers, this can go to IESG evaluation. ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Zaheduzzaman Sarker's No Objection on charter-ietf-alto-04-01: (with COMMENT)

2021-08-27 Thread Martin Duke
Hi Zahed, The original use case for ALTO -- peer to peer -- is largely dead. The current charter's work supports the new CDN Interconnect use case. It is too early to see how this affects adoption of ALTO, and I'm not convinced we understand the current level of ALTO adoption. So, this charter

Re: [alto] Éric Vyncke's No Objection on charter-ietf-alto-04-01: (with COMMENT)

2021-08-27 Thread Martin Duke
Hi Eric, I've edited the charter to reflect your concerns. On Thu, Aug 26, 2021 at 5:48 AM Qin Wu wrote: > Thanks Eric, see comments inline below. > -邮件原件- > >发件人: Éric Vyncke via Datatracker [mailto:nore...@ietf.org] > >发送时间: 2021年8月26日 14:06 > >收件人: The IESG > >抄送:

Re: [alto] charter-ietf-alto-04-01

2021-08-27 Thread Martin Duke
Hi Lars, I'm initiating a discussion about the value of the document deliverables in the charter. Meanwhile, I've already edited the charter to be a little more explicit why the routing WG activities are called out in the text. Thanks for your comments. On Thu, Aug 26, 2021 at 7:46 AM Peng Liu

Re: [alto] Benjamin Kaduk's No Objection on charter-ietf-alto-04-01: (with COMMENT)

2021-08-27 Thread Martin Duke
HI Ben, I edited the H/2 and 3 bullet to read as follows: o Support for modern transport protocols. ALTO only uses the capabilities of HTTP version 1. While ALTO can operate successfully over any version of HTTP, it would benefit from leveraging HTTP/2 and HTTP/3 capabilities such as push. The WG

Re: [alto] I-D Action: draft-ietf-alto-unified-props-new-18.txt

2021-08-12 Thread Martin Duke
Hi Sabine, Minor comments that aren't blocking last call: (7) Eliminate the commas around "for the Client" (8.3) Isn't " The client wants all properties values on all the entities," the use case for the (unfiltered) property map? (8.3) s/Sever/Server On Thu, Aug 12, 2021 at 8:38 AM

Re: [alto] New wikipedia page

2021-07-06 Thread Martin Duke
irs and AD. We will proceed with collaborative > editing and use the datatracker facilities. And indeed, we aim at keeping > it concise and focused on mature work. > > Best regards, > > Sabine > > > > *From:* alto *On Behalf Of *Martin Duke > *Sent:* Friday, July 2, 2021 8:46

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

2021-07-02 Thread Martin Duke
This has been in "Revised I-D needed" for 95 days. Is there an issue I should be aware of, or will I see a revision soon? On Wed, Jun 9, 2021 at 5:36 AM Qin Wu wrote: > Hi, Richard and Martin: > > > > *发件人:* alto [mailto:alto-boun...@ietf.org] *代表 *Martin Duke > *

[alto] New wikipedia page

2021-07-02 Thread Martin Duke
Hello ALTO, When reviewing ALTO documents I find myself constantly re-reading large sections of RFC 7285. To stop repeating this step, I cleaned up my notes and made a Wikipedia page. https://en.wikipedia.org/wiki/ALTO_(protocol) While I think it's a mistake to put immature internet drafts on

Re: [alto] WG Review: ALTO Charter Update(Internet mail)

2021-05-17 Thread Martin Duke
Chunshan, Thanks for your input. I support Qin's comments. I will also say that exploring these sorts of possibilities are the domain of the IRTF -- the IETF works where organizations are ready to deploy an architecture and just need the details to be worked out. ALTO is *not* the working group

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

2021-05-03 Thread Martin Duke
Hi Richard, Replies inline. On Thu, Apr 8, 2021 at 1:04 PM Y. Richard Yang wrote: > If the intent is that it be machine-readable, then there are several >> places where this standard is going to need more standardization (i.e. >> precise definition of text fields). >> > > Some of the authors

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

2021-04-05 Thread Martin Duke
Hi Richard, Where needed, responses inline. On Fri, Apr 2, 2021 at 6:18 PM Y. Richard Yang wrote: > - Sec 2.1. The cost-source model is conceptually sound, but the >> justification for it seems underexplained. What exactly is a client going >> to do with this information? What different

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

2021-03-30 Thread Martin Duke
:30 PM Martin Duke wrote: > One small correction: I'm jumping the gun on the author policy; 6 is > probably OK for now. > > On Mon, Mar 29, 2021 at 11:33 AM Martin Duke > wrote: > >> Hello authors, >> >> Thank you very much for writing this draft. It is c

Re: [alto] AD review of draft-ietf-alto-performance-metrics-15

2021-03-29 Thread Martin Duke
One small correction: I'm jumping the gun on the author policy; 6 is probably OK for now. On Mon, Mar 29, 2021 at 11:33 AM Martin Duke wrote: > Hello authors, > > Thank you very much for writing this draft. It is clearly a useful > extension to ALTO and is quite clearly written, eve

[alto] AD review of draft-ietf-alto-performance-metrics-15

2021-03-29 Thread Martin Duke
Hello authors, Thank you very much for writing this draft. It is clearly a useful extension to ALTO and is quite clearly written, even to someone who is not a practitioner. I have numerous comments/questions and a few nits. These points are all invitations to discussion, rather than commands

[alto] Please mention deployments in the charter

2020-12-01 Thread Martin Duke
Thanks to some feedback I got on announcing this recharter exercise, I think it would be helpful to have the (second?) paragraph of the charter to explain how ALTO has been deployed in the internet. It doesn't need to mention a bunch of companies, or describe every deployment out there, but it

[alto] ALTO Testimonials

2020-11-12 Thread Martin Duke
Hello ALTO, IETF is looking to publicize the work of the transport area a little more to the media. In particular, we'd like to highlight how recent work in Working Groups like ALTO have a made a difference in industry, government, and society. If any of you work for organizations that could

[alto] Welcome Qin Wu

2020-11-09 Thread Martin Duke
Hello ALTO, I'm pleased to welcome Qin Wu as the newest working group chair, effective immediately. Qin is and active participant in ALTO and an experienced chair. We will have three chairs at IETF 109. Shortly afterwards, one of the current chairs will step down. As we complete the current

Re: [alto] Seeking a new ALTO chair

2020-10-16 Thread Martin Duke
Hi ALTO, This is a reminder to get in touch with me by October 20th if you're interested in being the ALTO chair. Thanks, Martin On Wed, Sep 30, 2020 at 9:43 AM Martin Duke wrote: > Hello ALTO, > > As you all know, we are approaching completion of the milestones for the > w

[alto] Seeking a new ALTO chair

2020-09-30 Thread Martin Duke
.* Thanks for your consideration! Regards, Martin Duke Responsible Area Director ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto

[alto] Comment on draft-ietf-alto-performance-metric-09

2020-04-17 Thread Martin Duke
This is not a full review. I'm late to this and I apologize if I'm covering ground which has been fully resolved before. With all hats off... It has come up in the working group before that some of the cost metrics can vary quite a lot over time, much more quickly than the scale at which ALTO

Re: [alto] ALTO Interim in lieu of IETF 107

2020-03-13 Thread Martin Duke
I have no conflicts with any of these times, but #0 and #1 are pretty brutal for Pacific Time. On Fri, Mar 13, 2020 at 10:59 AM Vijay Gurbani wrote: > All: The IESG has been working on coming up with a virtual interim > schedule for WGs that would have met in Vancouver. As the original >