On Fri, Jun 09, 2023 at 12:53 PM, Ted Lemon <[email protected]> wrote:

> As I said, I though the text you copied from 8499 was good. It's also fine
> to just refer to 8499. As for the graph theory quote, if I'd reviewed 8499
> I would have said the same thing about it there.
>
> This is not a huge problem. It's just something that I saw that I thought
> could be improved, and then I guess Warren chimed in on it.
>

Yup - I did this while juggling jury duty and trying to figure how I was
going to survive without my phone :-P

I don't think it's reasonable to say "8499 says this, and even though
> that's somewhat confusing, it's more important to repeat what 8499 says
> than to say it more clearly." I am not sure Michael intended to say that,
> but that's how I read his response.
>
> So, from my personal perspective I would prefer that you put back the FQDN
> text and add an example for the "label" text.
>

Yup.

But I'm also perfectly okay with you just deferring explicitly to 8499 and
> not copying what it says at all.
>

Me too!

And I'm also okay with you telling me to shut up. This is not something
> anybody should be losing any sleep over!
>

Indeed. It feel like we might be getting somewhat frustrated over this text
- as Ted noted, they were nits intended to try and improve the document.
Any of the above, including the original are more than fine with me…

W


> On Fri, Jun 9, 2023 at 10:34 AM Owen Friel (ofriel) <[email protected]>
> wrote:
>
>> As Michael says, in -14 and earlier, we were verbatim without change
>> copying text from RFC8499.
>>
>> And the latest -15 abridges the text to remove quoting of the offending
>> text from RFC8499.
>>
>> If neither of the above are acceptable, how about this text:
>>
>> "The terms Label, Domain Name, Subdomain and FQDN are used throughout
>> this document. Please refer to [RFC8499] for a definition of these terms."
>>
>> -----Original Message-----
>> From: Michael Richardson <[email protected]>
>> Sent: Friday, June 9, 2023 2:58 PM
>> To: Ted Lemon <[email protected]>; Warren Kumari <[email protected]>
>> Cc: [email protected]; [email protected]; draft-ietf-acme-integrations.all@
>> ietf.org; [email protected]
>> Subject: Re: Dnsdir last call review of draft-ietf-acme-integrations-15
>>
>>
>> WARREN:
>>
>> Ted Lemon via Datatracker <[email protected]> wrote:
>>     > Frustratingly, the -15 update makes the document worse as a result
>> of
>>     > my initial comments, not better. I think the authors didn't
>> understand
>>     > why I made the comments, and hence are just trying to get rid of the
>>     > text that I commented on rather than fixing it. I actually
>> suggested a
>>     > better way to write the text, in the initial review, which may have
>>     > gotten lost:
>>
>> Hi, I appreciate your frustation.
>> You complained gently about text that wasn't ours.  It was copied from
>> RFC8499.
>> We quoted the definitions to save you a trip to RFC8499 and back.
>>
>> That's an entire RFC *JUST* for DNS Terminology.  Were you aware of this?
>> Was WARREN aware when he asked us to look at your nit, aware of that?
>>
>> If using RFC8499 definitions is wrong in a document that deals a lot
>> about DNS, then we really really have a problem.  Especially for a DNS
>> Directorate REVIEW.
>>
>> Editing the definitions would just lead to confusion as people wondered
>> why we changed things.  Abridging things to omit the words you found
>> unhelpful at least makes it clear we aren't trying to change things.
>> My co-author suggested we just rip all our text out.
>>
>>     >> I'm not seriously proposing that you make this change, but if you
>>     >> don't, I think you should delete the sentence about graph theory,
>>     >> because it's just confusingly broad if you don't then actually
>>     >> describe the subset of graph theory you're talking about.
>>
>>     > So, as an example, I did not suggest removing the text about
>>     > fully-qualified domains, which was fine, and is now not fine, in the
>>     > sense that the reader will have no idea why they are being
>> mentioned.
>>
>> We shortened it to what we thought was essential, but maybe we cut too
>> much.
>>
>> --
>> ]               Never tell me the odds!                 | ipv6 mesh
>> networks [
>> ]   Michael Richardson, Sandelman Software Works        | network
>> architect  [
>> ]     [email protected]  http://www.sandelman.ca/        |   ruby on
>> rails    [
>>
>>
>>
>>
>>
>>
>> --
>> Michael Richardson <[email protected]>, Sandelman Software Works
>>  -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*
>>
>
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to