+1 (inclusive of Jim’s nits, which Gavin recently acknowledged, obv)
Thx
Rick
From: regext on behalf of Gould, James
Date: Monday, May 6, 2024 at 2:30 PM
To: mario.loffredo=40iit.cnr...@dmarc.ietf.org
, James Galvin ,
regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WGLC:
Brown
Date: Tuesday, April 9, 2024 at 8:32 AM
To: Rick Wilhelm
Cc: regext@ietf.org
Subject: Re: [Ext] [regext] [EXTERNAL] I-D Action:
draft-ietf-regext-epp-ttl-07.txt
Hi Rick, thanks for sharing your feedback, my responses are below.
> On 8 Apr 2024, at 15:52, Rick Wilhelm
> wrote:
>
Gavin, et al,
This is a mixture of nits and wording things. I had provided this privately to
Gavin, he indicated it was better to just send directly to the list.
1.2.1:
The element may have the following attributes, depending on
Q1: The use of the uncapitalized ‘may’ here could be
Support adoption.
Thx
Rick
From: regext on behalf of Antoin Verschuren
Date: Monday, January 29, 2024 at 10:19 AM
To: regext
Subject: [EXTERNAL] [regext] CALL FOR ADOPTION:
draft-hollenbeck-regext-epp-delete-bcp
CAUTION: This email came from outside your organization. Don’t trust emails,
+1
Rick
From: regext on behalf of James Galvin
Date: Monday, June 26, 2023 at 10:02 AM
To: REGEXT Working Group
Subject: [EXTERNAL] [regext] WGLC: draft-ietf-rdap-opened-22
CAUTION: This email came from outside your organization. Don’t trust emails,
links, or attachments from senders that
+1 for adoption
From: regext on behalf of Antoin Verschuren
Date: Tuesday, April 25, 2023 at 4:54 PM
To: regext
Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-regext-brown-epp-ttl
CAUTION: This email came from outside your organization. Don’t trust emails,
links, or attachments from
+1
Thanks
Rick
From: regext on behalf of Jasdip Singh
Date: Tuesday, April 18, 2023 at 10:38 AM
To: Antoin Verschuren , regext
Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-redacted-11
CAUTION: This email came from outside your organization. Don’t trust emails,
links, or
I think that I’m leaning towards Andy’s approach, but I haven’t soak this
thinking for very long.
Perhaps it’s useful to go back to one of the original motivations for the draft.
As I recall, programmers, especially client-side, have been known to have
difficulty with JCard (for various
Two points in this email:
* one related to the on a comment that I made at the mic during the 30
March meeting at IETF 116; and
* one higher level issue that came up during Yet Another Read of the draft
Point One:
Section 5: Not sure about whether paragraph 3 of section 5 should have
Hi Gavin,
Just gave an initial read. I’m not quite sure of the use-case that would
motivate this, other than trying to eliminate round-trips. But maybe that’s
the point. :-)
One bit of initial feedback: In section 3, I was expecting to see “MUST” in
this sentence:
“When determining
Agreed… +1 on cardinality of one
Thx
Rick
From: regext on behalf of Roger D Carney
Date: Thursday, March 2, 2023 at 8:10 AM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] draft-ietf-regext-epp-eai Path Forward
CAUTION: This email came from outside your organization. Don’t trust
Gavin,
Sorry it’s taken me a while to get to this, but I wanted to actually read the
new version of the draft rather than just make comments based on email traffic,
heh.
Regarding the notion of the client providing a , I’d echo Jim’s
comment below regarding a preference to having the values
+1 to Thomas’ question… would be good to know if this is really existing in the
wild.
This kind of implementation inconsistency doesn’t really help anyone.
Rick
From: regext on behalf of Thomas Corte (TANGO
support)
Date: Thursday, October 20, 2022 at 8:13 AM
To: regext@ietf.org
Subject:
Gavin,
Just a +1 for having this extension cover both the domain and host objects.
The sibling glue model has enough deployment that having the extension cover
both models makes sense.
One other thing… and this is not a call for a change, just concurrence to an
existing design choice that is
I support this proposal.
Thanks
Rick
From: regext on behalf of James Galvin
Date: Monday, August 1, 2022 at 9:51 AM
To: REGEXT WG
Subject: [EXTERNAL] [regext] CONSENSUS CALL: discussion regarding
rdapConformance
CAUTION: This email came from outside your organization. Don’t trust emails,
Scott, et al,
Great question. One use case that comes to mind is working with law
enforcement. In certain situations, authenticated access to RDAP data is
required to override the default restrictions on disclosure. However, for
operational security reasons, the law enforcement agency (LEA)
To: Hollenbeck, Scott , Rick Wilhelm
, jgould=40verisign@dmarc.ietf.org
, regext@ietf.org
Subject: [EXTERNAL] Re: [regext] Login/Logout Processing (was RE: I-D Action:
draft-ietf-regext-rdap-openid-15.txt)
CAUTION: This email came from outside your organization. Don’t trust emails,
links
hould give back error
Thanks
Rick
From: Hollenbeck, Scott
Date: Tuesday, July 12, 2022 at 9:17 AM
To: jgould=40verisign@dmarc.ietf.org
, Rick Wilhelm ,
regext@ietf.org
Subject: [EXTERNAL] RE: [regext] Login/Logout Processing (was RE: I-D Action:
draft-ietf-regext-rdap-openid-
Scott,
A brief response to the Section 4.5 item, you can search for “[RW]” to find it
quickly.
And the suggested edit for Section 5 looks great. Also marked for clarity.
Thanks,
Rick
From: Hollenbeck, Scott
Date: Tuesday, July 5, 2022 at 2:17 PM
To: Rick Wilhelm , regext@ietf.org
Subject
I have been watching this discussion with great interest. Thanks to Jim Gould
for the below. As it’s been a week and no one has commented on this summary, I
will assume that prior participants view the below as largely reasonable.
In considering the below, I’ll offer the observations related
Jim,
Responses embedded in the feedback below. For ease of parsing, search for “RW”.
Thanks
Rick
From: Gould, James
Date: Friday, June 24, 2022 at 10:08 AM
To: Rick Wilhelm , regext@ietf.org
Subject: [EXTERNAL] Re: Re: [regext] I-D Action:
draft-ietf-regext-rdap-redacted-07.txt
CAUTION
Jim, et al,
While there is clearly work going on to determine a direction related to the
conformance values, I wanted to invest some time to give a careful review of
the current rdap-redacted draft to have it better prepared to progress after
the WG comes to some consensus.
Overall, I think
Scott,
Thanks for your ongoing work on rdap-openid. I am, by no measure, an expert in
OpenID, so some (all?) of this feedback may miss the mark. But perhaps some
will be helpful.
I don’t think that any of the below is new to the -15 version. (The second
item is from -14). But I’m hoping
Joseph,
Thanks for the ongoing updates to the draft.
Some comments to the -07 draft below.
Before getting into a more detailed, I want to express support for the
high-level suggestions that Jim Gould made in a June 15 message. Pasting them
here:
1. Split the draft into two separate
Scott,
Overall, I think that the modifications move the I-D in a good direction.
Thanks for your work on this.
I don’t have running code so this is more of a document review, rather than
comments from an implementer perspective.
Pls see the below.
3.1.2:
NIT: 3.1.2 #2 uses the term ‘
I support.
Thanks
Rick
From: regext on behalf of Antoin Verschuren
Date: Monday, December 20, 2021 at 8:55 AM
To: regext@ietf.org
Subject: [EXTERNAL] Re: [regext] WG LAST CALL: draft-ietf-regext-epp-eai-04
CAUTION: This email came from outside your organization. Don’t trust emails,
links,
26 matches
Mail list logo
