Allow me †o pile on with a +1 on the document.
I sent Gavin a few nits that I had, and a rhetorical question of EPP
server operators publishing their TTL policies.
tim
On Thu, May 9, 2024 at 9:04 AM Rick Wilhelm wrote:
> +1 (inclusive of Jim’s nits, which Gavin recently acknowledged, obv)
More for the WG/Chairs than Gavin or Rick
I think this document is ready for WGLC - are there any reasons why it
should not be?
thanks
tim
On Tue, Apr 9, 2024 at 11:23 AM Rick Wilhelm wrote:
> Gavin, et al,
>
>
>
> I’m good with the handlings that you describe below.
>
>
>
> That includes
+1 for adopting all of these.
Will sign up to review
tim
On Mon, Feb 5, 2024 at 9:37 AM James Galvin wrote:
> This is the formal adoption request for the following package of Internet
> Drafts:
>
> Versioning in the Registration Data Access Protocol (RDAP)
>
>
> Jasdip
>
>
>
> *From: *regext on behalf of Tim Wicinski <
> tjw.i...@gmail.com>
> *Date: *Monday, November 20, 2023 at 10:36 AM
> *To: *Ties de Kock
> *Cc: *regext
> *Subject: *Re: [regext] CALL FOR ADOPTION:
> draft-jasdips-regext-rdap-geofeed
>
>
I support adoption.
I note that the 9092bis document has expired, we should find out what the
authors are doing with that.
tim
On Mon, Nov 20, 2023 at 10:31 AM Ties de Kock wrote:
> I support adoption.
>
> Kind regards,
> Ties
>
> > On 20 Nov 2023, at 15:36, Antoin Verschuren
uped as observed practices and theoretical practices, perhaps
> we can look at that again. We’ll also look at adding a paragraph to Section
> 3.1 to describe the wide vs. narrow glue situation.
>
>
>
> Scott
>
>
>
> *From:* Tim Wicinski
> *Sent:* Friday, November 10, 2023 6:34
Total +1 to adopt. Willing to contribute, review, etc.
tim
On Tue, Apr 25, 2023 at 4:54 PM Antoin Verschuren wrote:
> This is a formal adoption request for Extensible Provisioning Protocol
> (EPP) mapping for DNS Time-To-Live (TTL) values:
>
>
Hi
I have no objections to this document being published.
tim
On Thu, Mar 23, 2023 at 3:17 AM Mario Loffredo
wrote:
> Hi Andy,
>
> Il 22/03/2023 22:37, Andrew Newton ha scritto:
> > I have read the draft again and support it.
> >
> > That said, is there a plan to add this equivalent from
Since it appears that code changes will need to be done for JContact, the
simpler proposal will be number 3.
Bytes are less expensive than making additional requests. (for the most
part)
tim
On Fri, Mar 31, 2023 at 9:03 PM Rick Wilhelm wrote:
> I think that I’m leaning towards Andy’s
o be proven wrong
tim
Thanks,
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
&
tim
Thanks,
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *Fro
James
I see the value in the registry as I expect this set of information will
change over time.
Having this structured data/information in one place for all to refer
feels simpler than
multiple RFCs.
tim
On Fri, Feb 17, 2023 at 9:02 AM Gould, James wrote:
> Steve,
>
>
>
> To follow-on to
Scott is right on the IANA registry bit. RFC7489 (DMARC) was not just
Informational but
Independent Stream (ISE) and it created a registry just fine.
Informational does make more sense in this case.
tim
On Thu, Feb 16, 2023 at 5:24 PM Andrew Newton wrote:
> I've reviewed this draft and have
(forgot to cc regext)
Big fan of this document and feel it is good. I have only one small nit:
See also "domain name" in [RFC8499].
Should this not be "Domain name" (per 8499) ?
I have a deeper question on using "ext" for extension - it feels like an
abbreviation which doesn't feel useful.
Oh, I like this draft.
Please adopt.
tim
On Mon, Dec 19, 2022 at 10:06 AM Antoin Verschuren wrote:
> This is the formal adoption request for RDAP RIR Search:
>
>
> https://datatracker.ietf.org/doc/draft-harrison-regext-rdap-rir-search/
>
> Please review this draft to see if you think it is
On Tue, Sep 27, 2022 at 9:17 AM Gould, James wrote:
> Gavin,
>
> I believe the domain-level TTL applies to the records it owns, which
> include the DS, NS, and DNAME. The host-level TTL applies to the records
> it owns, which include the A and . In your examples, if we're talking
> about
REGEXT chairs
Please count this as my +1 for adopting this work. I find this highly
relevant to not just create this dictionary, but offer precise definitions
for terms to avoid any "squishness" which seems to come back to bite up
when we least expect it. The work in DNSOP on DNS Terminology is
As an end-user i've always liked the out-of-band registrar-initiated
management of the client status.
I can see a registrar offering both in-band and out-of-band to their
clients.
Also, there appear to be some dangling sentences in section 2.
tim
On Tue, Apr 7, 2020 at 12:57 PM Hollenbeck,
Put me on the list Alexander.
Tim
On Mon, Oct 28, 2019 at 7:18 AM Hollenbeck, Scott wrote:
> I'm interested. This is also something that could be a good topic for next
> May's Registration Operations Workshop, especially if someone has a
> candidate API (or APIs) to discuss.
>
> Scott
>
> >
I nominate Alex to figure to make any remote technology work.
Win!
On Mon, Mar 4, 2019 at 7:30 AM Kal Feher wrote:
> I wont be on-site but will attend remotely if remote participation is
> available.
> On 4/3/19 8:32 pm, Tim Wicinski wrote:
>
>
> Count me in.
>
> Tim
&
Count me in.
Tim
On Mon, Mar 4, 2019 at 4:14 AM Alexander Mayrhofer <
alex.mayrhofer.i...@gmail.com> wrote:
> I've reserved room PARIS on wednesday, 2pm for that discussion. I hope
> that everyone can make it - this is the "unstructured time" slot on
> Wed afternoon, and so far it does not
21 matches
Mail list logo
