Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-refuse-any-07

2018-08-31 Thread Joe Abley
On Aug 31, 2018, at 17:52, Meral Shirazipour wrote: > Summary: This draft is ready to be published as Standards Track RFC. > > Major issues: > > Minor issues: > > Nits/editorial comments: > -[Page 5] "those avialable "---typo-->"those available " > -[Page 6] "in this seection "---typo-->"i

[Gen-art] Re: Review of draft-ietf-grow-anycast-03.txt

2006-06-07 Thread Joe Abley
Hi Sharon, On 7-Jun-2006, at 04:40, Sharon Chisholm wrote: Attached is my review of the specified document, submitted as part of the Gen-ART process. For background on Gen-ART, please see the FAQ at . Document: http://www.ietf.org/intern

[Gen-art] Re: Review of draft-ietf-grow-anycast-03.txt

2006-06-20 Thread Joe Abley
ycast-03: Editorial changes and language clean-up at the request of the IESG. draftt-ietf-grow-anycast-04: Replaced reference to RFC1771 with a reference to RFC4271. Replaced reference to draft-ietf-ipv6-addr-arch-v4 with a reference to RFC 4291. Changed author addr

Re: [Gen-art] Gen-ART review of draft-jabley-reverse-servers-01

2010-01-18 Thread Joe Abley
Hi Vijay, Thanks for your review. With respect to your suggested text for section 1, your text states that: > The canonical use of DNS is to resolve domain names to IPv4 or >IPv6 addresses, however the reverse is possible as well. I phrased the original text quite carefully: I think your su

Re: [Gen-art] Gen-ART review of draft-jabley-reverse-servers-01

2010-01-21 Thread Joe Abley
On 2010-01-21, at 11:02, Russ Housley wrote: > This document is being considered for approval in the next few minutes > by the IESG. I do not see the change you are discussing as reason for > delay. Perhaps Vijay and I can continue our private e-mail thread, and if we come up with any improv

Re: [Gen-art] Gen-ART review of draft-ietf-dnsop-dnssec-dps-framework-08

2012-07-16 Thread Joe Abley
Hi Russ, On 2012-07-15, at 11:39, Russ Housley wrote: > Peter: > > Thanks for the review. I've not read this document yet, but you review > raises a question in my mind. > > If a DNSSEC policy or practice statement is revised or amended, what actions > are needed make other aware of the chan

Re: [Gen-art] Gen-ART review of draft-ietf-dnsop-dnssec-dps-framework-08

2012-07-17 Thread Joe Abley
Hi Russ, On 2012-07-17, at 19:06, Russ Housley wrote: > I think you missed my point. In a PKI, when the issuer significantly changes > the policy, subsequent certificates have a different policy identifier. I do > not see a similar concept here. You're right, I did miss your point, quite tho

Re: [Gen-art] Gen-ART review of draft-ietf-dnsop-dnssec-dps-framework-08

2012-07-18 Thread Joe Abley
On 2012-07-18, at 11:49, Russ Housley wrote: > So a DNSSEC signer starts under one set of documents, and then for whatever > reason, the policy changes and the parties validating the signature have no > means to determine that the signer is following a new policy. They have means, they just do

Re: [Gen-art] Gen-ART Telechat review of draft-jabley-dnsext-eui48-eui64-rrtypes-05

2013-08-12 Thread Joe Abley
Hi Jari, I have seen the comments and I have no objection to incorporating the suggested edits. I have avoided doing that to date, following the advice to wait for the responsible AD before submitting any new versions. Joe On 2013-08-12, at 13:15, Jari Arkko wrote: > Peter: Thank you very

Re: [Gen-art] [DNSOP] Genart last call review of draft-ietf-dnsop-caching-resolution-failures-06

2023-08-21 Thread Joe Abley
On 21 Aug 2023, at 17:08, Wessels, Duane wrote: > You’re right that we have not been especially precise when using the word > “transport.” > The authors did intend for DNS over UDP, over TCP, and over TLS, etc to > essentially > be treated as separate transports, or separate ways a client can

Re: [Gen-art] [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

2023-09-15 Thread Joe Abley
Op 16 sep. 2023 om 03:02 heeft Salz, Rich het volgende geschreven: > On the other hand, spending a week or two repeating a cycle to get an > important term in the current document seems like a better solution. For an important omission that does seem like it would be a sensible thing to do, b