Rolling back the clock a bit here...
On Thu, May 26, 2022 at 11:11 AM John C Klensin wrote:
> First, it appears that it is making a more fundamental change to
> EPP than just allowing for SMTPUTF8 (aka "non-ASCII" or "EAI")
> addresses local parts. The second paragraph of the Introduction
> say
On Mon, May 15, 2023 at 12:06 PM Antoin Verschuren via Datatracker <
nore...@ietf.org> wrote:
> Antoin Verschuren has requested publication of
> draft-ietf-regext-rdap-reverse-search-22 as Proposed Standard on behalf of
> the REGEXT working group.
>
> Please verify the document's state at
> https:
On Tue, Jul 11, 2023 at 8:44 AM Mario Loffredo
wrote:
>
> * In Sections 12.2.3.2 and 12.2.4.2, the individual entries are run
> together into one big blob. Could we get blank lines between them, or
> maybe put each in its own subsection if necessary? Or make it a table?
>
> [ML] I know that the
On Wed, Jul 26, 2023 at 4:07 AM Mario Loffredo
wrote:
>
>
>
>> * Section 3 should probably specify what should happen if the JSONpath
>> refers to an attribute/value that's not present in the object it's
>> referencing.
>>
>> [ML] The JSONPath expressions related to reverse search properties are
AD evaluation:
Thanks, Andy, for a good shepherd writeup. It would be helpful, even if it
seems redundant or obvious, to include an answer to the question about why
Proposed Standard is the right status for this document.
The first paragraph of Section 3 is a bit confusing; it says you MUST NOT
AD review:
I note that the shepherd writeup's last question points out the creation of
a registry using Specification Required rules, and thus doesn't need a
designated expert, referencing RFC 8126 Section 4.6. However, that section
of that RFC says:
This policy is the same as Expert Review,
Hey Scott,
On Mon, Aug 14, 2023 at 5:54 AM Hollenbeck, Scott
wrote:
> Thanks for the review, Murray. Notes below.
>
>
>
> Scott
>
>
>
> *From:* regext *On Behalf Of *Murray S.
> Kucherawy
> *Sent:* Saturday, August 12, 2023 7:58 PM
> *To:* regext@ietf.or
On Wed, Aug 16, 2023 at 6:48 AM Hollenbeck, Scott
wrote:
> *From:* Murray S. Kucherawy
> *Sent:* Monday, August 14, 2023 6:23 PM
> *To:* Hollenbeck, Scott
> *Cc:* regext@ietf.org; AlBanna, Zaid ;
> regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Publication has
On Thu, Aug 17, 2023 at 12:56 PM Hollenbeck, Scott
wrote:
> *From:* Murray S. Kucherawy
> *Sent:* Thursday, August 17, 2023 11:56 AM
> *To:* Hollenbeck, Scott
> *Cc:* regext@ietf.org; AlBanna, Zaid ;
> regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Publication
On Fri, Aug 18, 2023 at 7:38 AM Hollenbeck, Scott
wrote:
>
>
> *From:* Murray S. Kucherawy
> *Sent:* Friday, August 18, 2023 1:54 AM
> *To:* Hollenbeck, Scott
> *Cc:* regext@ietf.org; AlBanna, Zaid ;
> regext-cha...@ietf.org
> *Subject:* [EXTERNAL] Re: [regext] Public
Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext on behalf of "Murray S.
> Kucherawy"
> *Date: *Saturday, August 12, 2023 at 7:38 PM
> *To: *"regext@ietf.org"
> *Cc: *"a...@hxr.us" , Gusta
On Tue, Aug 22, 2023 at 6:11 AM Mario Loffredo
wrote:
> > ### Outdated references
> >
> > Document references `draft-ietf-jsonpath-base-17`, but `-19` is the
> latest
> > available revision.
>
> [ML] The document makes use of the citation
>
> https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
On Thu, Aug 24, 2023 at 3:33 AM Mario Loffredo
wrote:
> > It looks as though draft-ietf-jsonpath-base should be a Normative
> reference. In
> > fact, this is explicitly mentioned in the shepherd writeup (thank you!):
> >
> > > 15. Should any informative references be normative or
> vice-
Hi Andrew,
Apologies for the delay processing this one. I'm digging my way out of
this December backlog.
My plan is to get it reviewed by an I18N expert in its current form. I'm
pushing to get that started this week. I'd like to either get it going in
its current form, or have a clear set of c
On Thu, Apr 9, 2020 at 6:45 AM Barry Leiba wrote:
> > Section 5.1.3: "This element SHOULD be present in deposits of type
> Incremental
> > or Differential." This makes it sound like a deposit of those two types
> not
> > using this element might be non-compliant. I suggest instead "This
> eleme
On Thu, Feb 18, 2021 at 8:10 AM Hollenbeck, Scott
wrote:
> [SAH] I'm going to blame that on one of the WEIRDS co-chairs ;) who
> reviewed 7482.
>
They really were a pair of slackers, weren't they?
I agree that it might help to add some more text to explain the rationale
> for the SHOULD. I don'
On Thu, Feb 18, 2021 at 7:47 AM Hollenbeck, Scott
wrote:
> > Section 10.1 is an update to an existing media type registration, not a
> new
> > one. Therefore:
> >
> > * Shouldn't this become the referenced document? Or is RFC 7483 still
> > controlling for this registration? * If the latter, sh
Hi all,
This is my AD review for draft-ietf-regext-epp-registry-maintenance.
General:
The use of "maintenance" in this document is sometimes awkward to me,
especially in its plural form. For instance, the first sentence of the
introduction includes "conduct maintenances", which reads oddly. I
4
> 23:59 PDT.
>
> Please find inline our comments.
>
> Best,
> Tobias
>
> On 9. Jul 2021, at 21:16, Murray S. Kucherawy wrote:
>
> Hi all,
>
> This is my AD review for draft-ietf-regext-epp-registry-maintenance.
>
> General:
>
> The use of "m
1, at 13:03, Tobias Sattler
> wrote:
>
> Thanks, Murray.
>
> We are not in a hurry. We will do the update next week then and look
> forward to the next steps.
>
> Best,
> Tobias
>
> On 16. Jul 2021, at 09:09, Murray S. Kucherawy
> wrote:
>
> Thanks, that&#x
On Wed, Jul 28, 2021 at 4:24 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> In the interest of letting the document move forward, I am balloting
> Abstain
> because the document still contains behavior that, while fully specified,
> seems to require additional conditional behavior
On Wed, Jul 28, 2021 at 7:01 AM The IESG wrote:
>
> The IESG has received a request from the Registration Protocols Extensions
> WG
> (regext) to consider the following document: - 'Registry Maintenance
> Notifications for the Extensible Provisioning
>Protocol (EPP)'
>as Proposed Standard
[Cc: trimmed]
Hi Tobias,
On Mon, Aug 16, 2021 at 2:19 AM Tobias Sattler
wrote:
> Hi Murray,
>
> We addressed the point on the XML schema by changing the URI as suggested;
> and explained our reasoning behind the “maint” abbreviation.
>
> The IANA experts want to get back to us as soon as they h
ded the IANA experts the link asking
> if this is fine for them. They said they would check that and get back to
> us.
>
> Best,
> Tobias
>
> On 20. Aug 2021, at 00:57, Murray S. Kucherawy
> wrote:
>
> [Cc: trimmed]
>
> Hi Tobias,
>
> On Mon, Aug 16, 2021 at
No, I was not aware, sorry. I missed Tobias' earlier message.
Please wait until after the telechat to post -18. You'll see its state
change to "IESG Evaluation::Revised I-D Needed", and that'll be your signal
to proceed.
-MSK
On Mon, Sep 27, 2021 at 6:34 AM Antoin Verschuren wrote:
> Murray,
On Wed, Oct 6, 2021 at 11:21 AM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:
> Francesca Palombini has entered the following ballot position for
> draft-ietf-regext-epp-registry-maintenance-17: Discuss
>
> When responding, please keep the subject line intact and reply to all
> em
> On 6. Oct 2021, at 07:47, Murray S. Kucherawy wrote:
>
> No, I was not aware, sorry. I missed Tobias' earlier message.
>
> Please wait until after the telechat to post -18. You'll see its state
> change to "IESG Evaluation::Revised I-D Needed", and that'll b
On Mon, Nov 29, 2021 at 1:37 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-regext-rfc7484bis-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included i
On Tue, Jan 25, 2022 at 4:05 PM Marc Blanchet
wrote:
> > 1. -
> >
> > FP: Please replace references to RFC 7234 with
> draft-ietf-httpbis-cache-19.
>
> I have a hard time thinking to replace an RFC reference to a draft in
> a document that would become an Internet Standard. Moreover, I think
Hi all, thanks for sending this along. And thanks for including Section 7.
1) In Section 3, you have:
"The validation rules introduced in RFC 6531 are considered to be followed."
I don't quite understand this sentence. Do you mean this?
"It is assumed that addresses used with this extension w
On Fri, May 20, 2022 at 6:08 AM Dmitry Belyavsky wrote:
> On Tue, May 17, 2022 at 7:28 PM Murray S. Kucherawy
> wrote:
>
>> 1) In Section 3, you have:
>>
>> "The validation rules introduced in RFC 6531 are considered to be
>> followed."
>>
>&g
Perfect. My DISCUSS is cleared.
-MSK
On Tue, Jan 7, 2025 at 5:52 AM Gavin Brown wrote:
> Hi Murray,
>
> > On 19 Dec 2024, at 22:25, Murray S. Kucherawy
> wrote:
> >
> > On Thu, Dec 19, 2024 at 5:02 AM Gavin Brown
> wrote:
> > A server may need to disreg
On Thu, Dec 19, 2024 at 6:09 AM Gavin Brown wrote:
> > I support Murray’s DISCUSS position re the SHOULD in Section 3.1,
> although
> > possibly for a slightly different motivation. I saw the reply to his
> DISCUSS to
> > the effect that you’re saying the operator really had better configure a
>
On Thu, Dec 19, 2024 at 5:02 AM Gavin Brown wrote:
> A server may need to disregard the provided TTL values in order to address
> security and stability issues. So "MUST" is not appropriate, because (to
> quote RFC 2119) there may exist valid reasons in particular circumstances
> to ignore those
Yep, I think that's more solid. Thanks!
-MSK
On Thu, Mar 6, 2025 at 6:38 AM Carroll, William
wrote:
> Murray,
> Thanks for your review. We think MUST would make sense here. Would this
> change to 5.1.3.4 address your concern?
> Old:
> The sacrificial name server SHOULD resolve to one or more I
On Mon, Mar 31, 2025 at 7:52 AM Andrew Newton (andy) wrote:
> IMO, things like NOT RECOMMENDED and SHOULD/SHOULD NOT are nearly
> worthless unless they can be qualified. That is, unless we can describe the
> conditions for going against a recommendation then there is no clear need
> to allow doin
36 matches
Mail list logo
