Hi Haisheng Yu / Johnson
On Fri, Apr 29, 2022 at 11:05:34AM +0800, Haisheng Yu wrote:
>Hi， Mukund,
> This is Johnson， I'm very sorry to cause you so much trouble.
>
> I think the draft of draft-muks-dns-message-fragments that you
>submitted to the IETF is quite int
Hi Cindy
On Thu, Apr 28, 2022 at 02:30:07PM -0700, Cindy Morgan wrote:
> Hi Mukand,
>
> When the Secretariat got the request to review the replacement
> relationship suggested by haisheng yu, I checked and saw that
> "haisheng yu" was listed as an author on both
> draft-hsyu-message-fragments and
Hi Mukand,
When the Secretariat got the request to review the replacement relationship
suggested by haisheng yu, I checked and saw that "haisheng yu" was listed as an
author on both draft-hsyu-message-fragments and
draft-muks-dnsop-message-fragments, and so I approved the replaced-by
informati
There was
https://datatracker.ietf.org/doc/html/draft-carpenter-whats-an-author-02
My hope is to revive that draft as an RFC Editor policy issue once the RSWG is
established, because it's broader than just an IETF issue.
Regards
Brian Carpenter
On 29-Apr-22 06:16, Donald Eastlake wrote:
Wh
Hi Donald
On Thu, Apr 28, 2022 at 02:16:16PM -0400, Donald Eastlake wrote:
> What you describe is completely improper but I'm not sure it's exactly
> accurate. When you said you were "removed" as an author, I assumed that a
> new revision of a draft was posted where you were a first page author fo
What you describe is completely improper but I'm not sure it's exactly
accurate. When you said you were "removed" as an author, I assumed that a
new revision of a draft was posted where you were a first page author for
version N but not listed as an author for version N+1. That would also be
improp
On Thu, Apr 28, 2022 at 09:33:08AM -0700, DraftTracker Mail System wrote:
>
> Please DO NOT reply to this email.
>
> I-D:
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-hsyu-message-fragments/
>
> This document now replaces draft-muks-dnsop-message-fragments
> draft-hsyu-dnsop
We updated dnsop-structured-dns-error-page:
* Require using RESINFO [I-D.reddy-add-resolver-info] in client
processing and added discussion of attack mitigation of using
RESINFO.
* Removed validation of URI domain suffix, which we can't do for
some URLs (e.g., tel:), is difficult/impossible for o
Didn’t we also agree to have Implementation Status in the drafts?
There probably should be such section covering both crypto library support
(OpenSSL is deprecating “engines” in favor of new “providers”).
This would be useful to both help the implementors decide whether it even
makes sense to imp
