[Gen-art] Fwd: Undelivered Mail Returned to Sender
ISorry to send this to the gen-art list, but I don't have an alternate address for Dale. I assume he'll see the note the enclosed refers to, via this list. But I'd like to make sure he also knows about this bounce reason. d/ Forwarded Message Subject: Undelivered Mail Returned to Sender Date: Wed, 10 Feb 2021 08:31:12 -0500 (EST) From: Mail Delivery System To: dcroc...@bbiw.net This is the mail system at host mailout.west.internal. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : host smtp.theworld.com[192.74.137.101] said: 554 Matches spam fingerprint [13]. (in reply to end of DATA command) -- Dave Crocker Brandenburg InternetWorking bbiw.net Reporting-MTA: dns; mailout.west.internal X-Postfix-Queue-ID: 36E2ED60 X-Postfix-Sender: rfc822; dcrocker@bbiw.net Arrival-Date: Wed, 10 Feb 2021 08:30:34 -0500 (EST) Final-Recipient: rfc822; worley@ariadne.com Original-Recipient: rfc822;worley@ariadne.com Action: failed Status: 5.0.0 Remote-MTA: dns; smtp.theworld.com Diagnostic-Code: smtp; 554 Matches spam fingerprint [13]. --- Begin Message --- On 2/8/2021 7:42 PM, Dale R. Worley wrote: After sending my previous message, I realized that I had gone to length explaining why I considered the term "accompanying" to be ill-defined, but I had forgotten to mention that in my review, I'd added "Or perhaps this should be forward-referenced to the discussion in section 3." Just adding a reference to section 3 would clarify it, because section 3 covers the matter well. Another version that would be good is "The emoji(s) express a recipient's summary reaction to the specific message referenced by the In-Reply-To header field of the message in which it is present." Here's the latest version: The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field, for the message in which they both are present. [Mail-Fmt]. For processing details, see Section 3. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --- End Message --- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-crocker-inreply-react-07
On 2/8/2021 7:42 PM, Dale R. Worley wrote: After sending my previous message, I realized that I had gone to length explaining why I considered the term "accompanying" to be ill-defined, but I had forgotten to mention that in my review, I'd added "Or perhaps this should be forward-referenced to the discussion in section 3." Just adding a reference to section 3 would clarify it, because section 3 covers the matter well. Another version that would be good is "The emoji(s) express a recipient's summary reaction to the specific message referenced by the In-Reply-To header field of the message in which it is present." Here's the latest version: The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field, for the message in which they both are present. [Mail-Fmt]. For processing details, see Section 3. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-crocker-inreply-react-07
On 1/30/2021 3:13 PM, Ned Freed wrote: Finally, I think a couple of word choices could be better. So how about: Having seen no objections, I've replaced the draft's existing text with Ned's proposed alternative. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-crocker-inreply-react-07
On 1/31/2021 2:16 PM, Dale R. Worley wrote: Dave Crocker writes: On 1/27/2021 6:32 PM, Dale Worley via Datatracker wrote: The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field. [Mail-Fmt]. This is not specific as to where the In-Reply-To header is. I assume you want to say that it is a header of the parent multipart component of "Reaction" part. Or perhaps this should be forward-referenced to the discussion in section 3. I don't understand the concern. An In-Reply-To header field is part of the message header. That is, it will be in the header of the response message. Given that we're deailing with multipart messages, an In-Reply-To header could be stuck in the message header but it could also be stuck in the headers of any part. I don't know if it's ever done, but certainly, it's plausible that if I include a reply which I had received as an attachment to another email I send, the In-Reply-To header in the received e-mail would show up as a header to the attachment part, not my message as a whole. In general, the situation is one of unlimited complexity. RFC 5322's definition of the In-Reply-To field has it being optionally present in the message header: message = fields *( CRLF *text ) ; Everything after ; first null line ; is message body fields =dates ; Creation time, source ; author id & one 1*destination; address required *optional-field ; others optional optional-field = / "In-Reply-To" ":" *(phrase / msg-id) As such, it's location is not as random or varied as you seem to think. Also note that the In-Reply-To field has long history and is already well-integrated into MUAs. So, the complexity is quite limited. My guess is that you are confusing the variable venues possible for the emoji-sequence with the far less variable venue of In-Reply-To. I suppose a clarification could be added along the lines of: OLD: The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field. [Mail-Fmt]. NEW: The emoji(s) express a recipient's summary reaction to the specific message referenced by the accompanying In-Reply-To header field, for the message in which they both are present. [Mail-Fmt]. If a message is nested within a message, that defines a hard reference boundary. Something inside the nested message does not refer to the containing message, for example. I'm not particular what rules you want to specify, just that when I'm looking at a part with this Content-Disposition that is somewhere in a multipart structure (possibly without parts), that it's clear which sets of headers I need to examine to find the In-Reply-Header. Perhaps you could offer an example or two of messages that you see as creating ambiguity or other confusion? Now I think in reality, it either has to be in the headers of the part with disposition "reaction", or in the multipart containing that part. But whatever the rule is, it should be stated. see above? Reference to unallocated code points SHOULD NOT be treated as an error; associated bytes SHOULD be processed using the system default method for denoting an unallocated or undisplayable code point. Code points that do not have the requisite attributes to qualify as part of an emoji_sequence should also not be treated as an error, although you probably want to allow the system to alternatively display them normally (rather than as an unallocated or undisplayable code point). I think your comment addresses a different issue than the cited text is meant for, but I also might be misunderstanding. For whatever reasons, including not having been allocated by the Unicode folks, or possibly by running an older system that thinks a code point is not allocated, there is an issue of how the system should deal with encountering such a code point. The text here is merely trying to say "do whatever you do". The text is a constraint, though. It *requires* (sort of) that if the bytes in the part form a character which the receiver considers unallocated, it *should not* reject the whole message as being ill-formed. The implementation has great freedom in how to display the caracter, but the message as a whole "SHOULD NOT be treated as an error". Since this specification pertains to processing of some octets, rather than having anything to do with overall processing of the message, I am not understanding your concern. A system that might reject an entire message because the system is unh
Re: [Gen-art] [Last-Call] Genart last call review of draft-crocker-inreply-react-07
On 1/28/2021 12:21 AM, Kjetil Torgrim Homme wrote: On Wed, 2021-01-27 at 19:35 -0800, Dave Crocker wrote: To the extent that your intent is to say that a) this is a subset of UTF-8, and b) multiple bytes can be used, I think that's built into the definition of emoji-sequence. In fact, I had added the one or more text mostly to highlight the the 'sequence' can be only one byte, since 'sequence' would be expected to be read as meaning multiple. One small change here which will reduce the amount of confusion is to avoid the word "byte". Indeed, it is *not* possible for the sequence to be only one byte, since there are no Unicode code points in the range U+ U+007F with the Emoji property set. So, use "emoji characters" or "code points" instead? (I tend to avoid the use of "byte" in favour of "octet" to forestall complaints from the old DEC-10, DEC-20 and Cray users anyway ☺) Well, indeed, my entrenched use of byte probably gets in the way, here... I want the term to be more low-level and physical, than abstract or conceptual. That is, I'd like the term to be outside of the Unicode specialized terminology. To that end, I think octet works well. Reference to unallocated code points SHOULD NOT be treated as an error; associated bytes SHOULD be processed using the system default method for denoting an unallocated or undisplayable code point. Code points that do not have the requisite attributes to qualify as part of an emoji_sequence should also not be treated as an error, although you probably want to allow the system to alternatively display them normally (rather than as an unallocated or undisplayable code point). I think your comment addresses a different issue than the cited text is meant for, but I also might be misunderstanding. Probably, but I think it bears saying something about how to handle code points without the Emoji property set. IMHO they should be handled as undisplayable. This steps into user interface design, more than interoperable emoji labeling and transport. As such, it's outside of this specification and outside of the IETF's expertise. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
On 10/10/2018 12:54 PM, Alissa Cooper wrote: The Gen-ART review for attrleaf is athttps://mailarchive.ietf.org/arch/msg/dnsop/dq-cwawY1UqoGJWFUxQPuWv0oPc. hmmm. I see that its addressing should have reached me but I'm not finding a copy in my mail archive. Thanks for the pointer: From: Erik Kline To: Cc: dn...@ietf.org, i...@ietf.org, draft-ietf-dnsop-attrleaf@ietf.org Message-ID: <153799182298.21553.7443559303630152...@ietfa.amsl.com> Date: Wed, 26 Sep 2018 12:57:03 -0700 Subject: [DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-13 Section 2: "DNS nodes names" doesn't quite scan for me. "DNS node names" perhaps? Section 4.2: s/simply/simplify/? Section 5: s/in the of/in the/? done. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
Henrik, Thanks for the quick followup... On 9/26/2018 1:08 PM, Henrik Levkowetz wrote: I think xml2rfc does the right thing. The quotes are provided by you, the author, not the processor, and you've enclosed the element completely in the quotes: yeah, sorry. played with the combinatorials a bit more and agree. xml2rfc is not a do-what-I-mean-not-what-I-say piece of code quite yet ,;-) well, now, that's something to work on. d/ ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
On 9/24/2018 6:16 AM, Dave Crocker wrote: + Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry [RFC6335]" Move the end quote after Registry. ok. Good catch. Interesting. Just discovered that this probably qualifies as a bug in the xml2rfc processor tool at the IETF site. (I only submitted the xml, which I think is formally ok.) Here's the xml for that paragraph: Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS). (I'm changing the xml to avoid this bug for the next version.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
nt.
-- Obsolete informational reference (is this intentional?): RFC 3921
(Obsoleted by RFC 6121)
Ack. Not intentional; just an error introduced by 12 years of lag time...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GEN-ART telechat review of draft-farrell-perpass-attack-05
On 1/31/2014 8:55 AM, Scott Brim wrote: First, there are good arguments for publication as Informational , but since it incrementally adds to BCP 72, it should be incorporated there, so BCP is slightly better. It does? It does not say it does. So that linkage is something the reviewer is creating. At the least, a claim that it does add to BCP 72 invites further debate about the nature and implications of the update. Again, making this a BCP confuses the nature of the document with those that give substantive operational guidance. This document does exactly what it should: It defines the topic and it says the IETF considers the topic important. It calls for practices, but doesn't -- and shouldn't -- define them. The job of providing substantive details about IETF practices associated with the topic will come later. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-Art telechat review of draft-farrell-perpass-attack-04
On 1/21/2014 1:38 PM, Sam Hartman wrote: I think that consideration of perpass at the architectural level, being prepared to justify decisions, and seeking adequate review of those decision ... I value integrity and honesty very highly and am feel sick when I think about claiming to the world that we're going to address perpass mitigations without being willing to commit to ourselves to do the architectural work. Sam, Consider the level of activity on this topic that is already happening in the IETF, as well as the nature of this initial document. I'll suggest that that's the most important demonstration of organizational commitment. The document in question marks that commitment, but it needs to be careful not to mark it beyond our current capabilities. In particular please point me/us to established consensus documents that define the problem space, the solution space and the architectural choices appropriate to this topic. I'm not aware of any, but perhaps I missed them. Absent established documents on this topic, justifying is only reasonable in terms of demonstrating thoughtfulness, not demonstrating that the choices are correct. Yet a term like justify encourages this latter expectations. the view that we have far more community clue about this topic than we currently have. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Consideration vs. Blocking (was Re: Gen-Art telechat review of draft-farrell-perpass-attack-04)
On 1/19/2014 12:30 AM, Eliot Lear wrote: It is fair to say that we should consider this threat at an architectural level. It's fair (albeit a truism) that finding design flaws earlier in the process rather than later is less costly (ENG-101). Justification language like the above, however, is likely to actively impede the IETF, as these sorts of things have in the past. If I'm understanding this exchange, it hinges on the distinction between due consideration vs. appropriate design response. Pressing to have work consider an issue early and thoughtfully makes sense for any topic that is as important as pervasive monitoring. Having IESG evaluation produce a blocking Discuss because an AD feels that the consideration was not sufficient or the resulting design flawed in terms of this issue is another matter. The point I'm seeing Eliot make is that we don't have enough community understanding of the topic to be sure what constitutes appropriate design consideration. So, in the face of such minimal community understanding, an AD's blocking progress would be whimsical at best. Based on how new this topic is -- we don't even yet have stable and shared terminology for the problem space nor the solution space -- Eliot's concern isn't just valid, it's important. We /do/ have a long track record of well-intentioned ADs asserting Discusses that are reasonable in the abstract but impractical for work in the IETF, especially when the topic is frankly still vague. While the formal status of this document is relevant to the concern, the more important issue I see is our community sense that work going forward needs serious effort, but also an understanding that the basis for blocking specification needs to be extremely cautiously applied. By way of trying to be practical about being practical, I'll suggest that any IESG blocks based on a concern about pervasive monitoring needs to reflect a consensus view of the IESG, not just the concern of a single AD d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06
On 10/18/2012 6:45 AM, John C Klensin wrote: As I said earlier, I can live with almost anything if it is correct and allows us to move forward. I am, however, getting more concerned about the consequences to the virtual 5322bis and its future instantiation if we go down these paths. I would really not like to be the relevant AD (or Pete-bis) trying to defend leaving the explanation and reference out of 5322bis given that they were important enough to include in this document and, if the explanation and reference go into 5322bis, why a large series of other references and explanations should not be included. I'd be a tad happier if this explanatory stuff when into an appendix rather than the text. The job of the current draft is to be sufficient to its purpose. Its purpose is to augment a base document with a specific revision. An update segment document does not typically have the purpose of including extensive annotations for possible later use, attempting to anticipate or hypothesize later editing efforts, to revise the base document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06
I have wondered about that limitation for at least 15 years. I have come up with possible explanations but without a shred of evidence from the RFCs. FWIW, The construct of group is pretty much an assertion of an aggregate identity. That is, an identity beyond that of the listed addressees, deriving from their, u... grouping. The purpose of From: and Sender: is to assign bits of essential responsibility. Unlike the current trend towards declaring personhood for corporations, the design motivation behind using the group construct was to restrict assignment of responsibilities to individuals, rather than aggregations of them. All very abstract, I admit. From the vantage point of some decades, even quaint. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06
On 10/17/2012 10:49 AM, ned+i...@mauve.mrochek.com wrote: Minor issues: 1. It is not clear from the draft what the use case for using the group construct is. Section 3 talks about the issues with using the group construct and recommend limited use, but this is the only information. The main driver for this work is to add support for EAI downgrade mechanisms, Although the Intro text cites this, it doesn't explain how the change will help. Nor is this explained elsewhere in the document. A single sentence summarizing what benefit is achieved with the change, along with a couple of usage examples, would go a long way towards showing how this update helps in practical ways. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06
On 10/17/2012 12:27 PM, John C Klensin wrote: --On Wednesday, October 17, 2012 12:00 -0700 ned+i...@mauve.mrochek.com wrote: A single sentence summarizing what benefit is achieved with the change, along with a couple of usage examples, would go a long way towards showing how this update helps in practical ways. I could live with a single sentence, but I strongly object to the inclusion of examples, for the reasons I gave in my original response. Would a possible middle ground be to include a single well-crafted sentence with an informative citation of draft-ietf-eai-popimap-downgrade? That document does contain examples and an explanation of that particular use case. I thought Ned's goal was -- quite reasonably, IMO -- to not be dependent upon EAI for this general-purpose enhancement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06
On 10/17/2012 2:32 PM, Ned Freed wrote: Channeling my inner Maslow, I see the present text as best, an additional sentence or two as next best, a sentence and a cite to the downgrade doc next in line, and including actual EAI examples in this doc as the worst choice. The problem I have with the current text is that it says 'what' motivated the change, but not how it is useful for the intended class of uses. The reader is left entirely to guess. Self-actualization among the inadequately-informed invites fantasy more than it invites utility. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-leiba-5322upd-from-group-06
On 10/17/2012 5:18 PM, Ned Freed wrote: If you really think this is important to explain why we're making this change against the overall context of RFC 5322 - and I most certainly do not agree that it is important to do so - then the best use case to add is the negative one: The elimination of an unnecessary restriction that isn't followed in practice. I see no way to explain the narrow EAI use case in this context without either dragging in a whole bunch of EAI that has no business being here or leaving various things dangling. ack. mumble. So I'll suggest a bit of an amalgam, including a cross reference of the type I prefer to avoid: 1. State that this removes a restriction that was never essential. 2. State that the timing of this removal is to accomodate EAI and for its use of the now-available features, see [RFC]. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,
On 9/21/2012 8:23 AM, Pete Resnick wrote: On 9/18/12 8:45 PM, Ben Campbell wrote:abstract should mention that this obsoletes 5721 It does. Stylistic point: RFCs last a long time. Including ephemeral information can be distracting, especially in the Abstract. 5 and 10 years from now, the fact that this RFC replaces another will be essentially irrelevant, but the Abstract will still be spending valuable space citing the fact. It is better to have the document written as standing on its own, rather than focus on its relationship to its predecessors, except perhaps in isolated 'background' or 'history' discussions (and, of course, the Updates field...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-eai-rfc5335bis-12
On 10/20/2011 3:37 PM, Pete Resnick wrote: So, if the limit is still 998, then there is no change with respect the former limit. See the next sentence: (Note that in ASCII octets and characters are effectively the same but this is not true in UTF-8.) Remember, in UTF-8, characters can be multiple octets. So 998 UTF-8 encoded *characters* are likely to be many more than 998 octets long. So the change is to say that the limit is in octets, not in characters. The switch in vocabulary is clearly subtle for readers. (I missed it too.) I suggest adding some language that highlights the point, possibly the same language as you just used to explain it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] review of draft-ietf-dkim-rfc4871bis-12.txt
Francis, Thanks for the review... On 7/22/2011 1:44 AM, Francis Dupont wrote: Nits/editorial comments: - ToC page 4 and appendix F page 77: Acknowledgements - Acknowledgments One of the joys of the diversity of the IETF is the diversity of writing conventions we tolerate. For the current document, I'm surprised we didn't wind up with some British spellings... In any event, it turns out that both forms of the word are valid spellings. - Authors' Addresses page 78: please consider to add the zip code to all addresses in the USA? Yes, that would be more considerate to provide. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-dkim-deployment-10.txt
thanks! d/ On 1/11/2010 1:49 PM, Suresh Krishnan wrote: Summary: This draft is ready for publication as Informational RFC. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review for draft-crocker-email-arch-12
Vijay K. Gurbani wrote: Major issues: None. Minor issues: None. Nits/editorial comments: 1) S3.1 s/VPIM [RFC3801] such as/VPIM [RFC3801], such as/ 2) Figure 5, in the legend: s/bpxes/boxes cool. thanks! d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-irtf-asrg-dnsbl-07
Spencer Dawkins wrote: Summary: Ready for publication as Proposed StandardComments: I'm not addressing meta-issues in this review that have already popped up during Last Call comments... Spencer, thanks. Just for completeness, given the meta-issues that have arisen and that it is out of scope for your review, can you summarize the nature of what was *in* scope? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
