Subject: Re: Last Call: <draft-jdfalk-maawg-cfblbcp-02.txt> (Complaint Feedback Loop Operational Recommendations) to Informational RFC

From: SM <[email-masked]>
Date: Mon, 03 Oct 2011 02:38:05 -0700

At 06:43 22-09-2011, The IESG wrote:

>The IESG has received a request from an individual submitter to consider
>the following document:
>- 'Complaint Feedback Loop Operational Recommendations'
>   <draft-jdfalk-maawg-cfblbcp-02.txt> as an Informational RFC
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2011-10-20. Exceptionally, comments may be

The short title of the draft is "CFBL BCP".  Given the recent short 
discussion about the use of "BCP", I suggest changing that.

In the Abstract section:

   "This document is an attempt to codify, and thus clarify, the ways that
    both providers and consumers of these feedback mechanisms intend to use
    the feedback, describing some already-common industry practices."

I suggest using "document" instead of "codify" as this is not being 
standardized.

 From page 2:

"About MAAWG

    MAAWG [1] is the largest global industry association working against
    Spam, viruses, denial-of-service attacks and other online
    exploitation.  Its' members include ISPs, network and mobile
    operators, key technology providers and volume sender organizations.
    It represents over one billion mailboxes worldwide and its membership
    contributed their expertise in developing this description of current
    Feedback Loop practices."

Could the PR blurb be removed?

Please note that the comments below should be read as informative as 
this is a re-publication of a document from a trade organization.

   "Message Delivery - The process of transferring a message from one
    mail transfer agent (MTA) to another."

According to RFC 5598:

   'A Message Transfer Agent (MTA) relays mail for one application-level
    "hop".'

The above definition sounds more like message relaying.

   'Reverse DNS ... Further, a reverse DNS query returns a PTR record
    rather than an A record."

If the "user-visible query" returns an IP address, it can be an A or 
AAAA record.

In Section 3.5:

   "Ownership of IP addresses can and should be crosschecked by means of
    origin ASN, whois/rwhois records, Reverse DNS of the sending hosts,
    and other sources."

The term "IP address ownership" is generally avoided to prevent 
assertions of ownership rights.  There are organizations which sell 
IP address registration services.

In Section 3.5.1:

  'Sending IP addresses and/or DKIM "d=" string

   "From" email address'

These terms are used loosely.  It may be viewed as appropriate for a 
non-IETF audience.

If there is any derivative work from this draft, I would recommend 
rearranging the information, i.e. some separation of the technical 
and non-technical details.  I might suggest moving the overview 
before the glossary to introduce people who have been through a 
dysfunctional educational system to the topic.  The first paragraph 
could then be the introduction, followed by a glossary and then an 
overview of the system.

The draft discusses about a subject where the answers can be 
complex.  Hence, it does not take a one size fits all approach.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 3 Oct 2011 15:58:28 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Monday, October 03, 2011 2:38 AM
> To: [email-masked]
> Subject: Re: Last Call: <draft-jdfalk-maawg-cfblbcp-02.txt> (Complaint
> Feedback Loop Operational Recommendations) to Informational RFC
> 

Does the filename really matter?

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Oct 2011 10:17:02 -0400

SM says...
>> discussion about the use of "BCP", I suggest changing that.

Murray says...
> Does the filename really matter?

He's not talking about the filename; the short title is what's printed
at the top of every page.  It comes from the "abbrev" parameter in the
"title" element in the XML.  It can be changed with an RFC Editor
note.

SM says...
> I suggest using "document" instead of "codify" as this is not being

That's a sensible change.

> Could the PR blurb be removed?

I think it's useful in this document.  People reading IETF documents
aren't likely to know what MAAWG is, and a short paragraph doesn't
seem untoward.  I'd agree, if there were excessively long text for
this, but it's brief.

Barry

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 4 Oct 2011 17:28:05 +0200

On 4 October 2011 16:17, Barry Leiba wrote:

>> I suggest using "document" instead of "codify" as this is not
>> being standardized.

> That's a sensible change.

[Insert DEnglish disclaimer:]  For "document" I read "we say so", for
"codify" I read "we say so, and we mean it".   While this memo is no
standard, it is still a recommendation; "codify" (desired behaviour)
instead of "document" (observed behaviour) makes sense for me.

>> MAAWG [1] is the largest global industry association working
>> against Spam, viruses, denial-of-service attacks and other online
>> exploitation.
[...]

> seem untoward.  I'd agree, if there were excessively long text for

In Wikipedia the "largest" would immediately get a "citation needed"
flag; it sounds like spam.  With a reliable third party reference it
might be possible to say "as of 2011 was the largest"; but do we care
who was "the largest whatever" at the time of the RFC publication?

IMO saying "is a large whatever" would be better.  Presumably readers
of this RFC know MAAWG; otherwise they might be in to grok dozens of
ASRG acronyms and mail-abuse RFCs before they'll understand this RFC.

-Frank

---

From: "J.D. Falk" <[email-masked]>
Date: Tue, 4 Oct 2011 09:09:25 -0700

> "title" element in the XML.  It can be changed with an RFC Editor

I'm certain MAAWG won't object to that change.  Do I need to send the note?

> That's a sensible change.

I lean more towards Frank Ellerman's interpretation (elsewhere in this thread), but if there's a strong interest in changing it then I won't push back much.

Perhaps a better change would be simply: "This document is an attempt to clarify the ways..."

> seem untoward.  I'd agree, if there were excessively long text for

MAAWG will insist on keeping this.  The primary purpose, in my mind, is to show that even though this wasn't written within the IETF it was still written by people who really do know what they're talking about.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Barry Leiba <[email-masked]>
Date: Tue, 4 Oct 2011 13:51:20 -0400

> I'm certain MAAWG won't object to that change.  Do I need to send the note?

No; the sponsoring AD will enter the RFC Editor note in the tracker.
You can change it in your XML, and if there are other changes that
require a revised I-D it'll get picked up then.  Otherwise, the RFC
Editor will fix it before AUTH48.

Barry

---

From: Douglas Otis <[email-masked]>
Date: Tue, 04 Oct 2011 17:23:27 -0700

> MAAWG will insist on keeping this.  The primary purpose, in my mind, is to show that even though this wasn't written within the IETF it was still written by people who really do know what they're t…
I agree with Frank on this issue.  The PR blurb should not be included.  
If MAAWG finds removal unacceptable, they are free to publish the 
document themselves among their other documents.  MAAWG has a closed 
membership heavily influenced by ISPs and high volume senders.  The IETF 
has normally resisted this type of influence by not referring to 
specific organizations.  Such influence is not always beneficial from 
the perspective of many IETF objectives.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 4 Oct 2011 21:28:14 -0700

> From: J.D. Falk [mailto:[email-masked]]
> Sent: Tuesday, October 04, 2011 9:09 AM
> To: Barry Leiba
> Cc: Murray S. Kucherawy; [email-masked]
> Subject: Re: Last Call: <draft-jdfalk-maawg-cfblbcp-02.txt> (Complaint Feedback Loop Operational Recommendations) to Informational RFC
> 
> >> "About MAAWG
> >>
> MAAWG will insist on keeping this.  The primary purpose, in my mind, is
> to show that even though this wasn't written within the IETF it was
> still written by people who really do know what they're talking about.

I support its inclusion based on this, and simply to provide some context about what MAAWG is.  To Frank's comment, I suggest changing "the largest" to "a large", and leaving the rest as-is.  If people really hate its placement up-front, perhaps it could appear in an appendix instead, but I'm fine with it where it is.

I don't think the IETF needs to be too worried about publishing an externally-generated document as an RFC given that it's Informational only, and is directly related to work that is going on in a current working group.  I suspect it would be more of a concern if it were re-publishing something onto the Standards Track without sending it through a working group first.

(And "Its'" should be "Its".)

-MSK

---

From: Eliot Lear <[email-masked]>
Date: Wed, 05 Oct 2011 08:43:02 +0200

For the record, I tend to dislike pollution of the RFC series with PR
blurbs as well.  This having been said, I would be far more interested
in a discussion about the actual substantive content of the document.

Eliot

On 10/5/11 2:23 AM, Douglas Otis wrote:
>> MAAWG will insist on keeping this.  The primary purpose, in my mind,
>> is to show that even though this wasn't written within the IETF it
>> was still written by people who really do know what they're talking
>> about.
> I agree with Frank on this issue.  The PR blurb should not be
> included.  If MAAWG finds removal unacceptable, they are free to
> publish the document themselves among their other documents.  MAAWG
> has a closed membership heavily influenced by ISPs and high volume
> senders.  The IETF has normally resisted this type of influence by not
> referring to specific organizations.  Such influence is not always
> beneficial from the perspective of many IETF objectives.
>
> -Doug
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Hector <[email-masked]>
Date: Wed, 05 Oct 2011 05:56:00 -0400

Douglas Otis wrote:

>> is to show that even though this wasn't written within the IETF it was 

and thats the problem with people who believe that.

> the perspective of many IETF objectives.

+1000.

--
HLS

---

From: Hector <[email-masked]>
Date: Wed, 05 Oct 2011 06:03:44 -0400

> I don't think the IETF needs to be too worried about publishing an externally-generated document as an RFC given that it's Informational only, and is directly related to work that is going on in a…

Funny thing these days, FAST TRACK "Information Only" I-Ds tend to 
used to "influence" direction, changed things, even charters or become 
something else to ram down people's throats.

Exceptions should not be allowed.  MAAWG is a specific organization 
that is most likely 0.0001% of the total IETF population - special 
memberships should not be used to influence the IETF or its medium 
begin to be become eyeballs for MAAWG advertising.

It smells with ETHICS issues.  Better to keep out.

--
HLS

---

From: Hector <[email-masked]>
Date: Wed, 05 Oct 2011 06:11:01 -0400

> in a discussion about the actual substantive content of the document.

+1, the real problem is that once this door is cracked open then we 
begin to see more of it and that what we really don't wish to be 
dealing with.

--
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 05 Oct 2011 18:28:48 +0200

> instead of "document" (observed behaviour) makes sense for me.

It seems that much of the formerly desired behavior can now be
actually observed.

> ASRG acronyms and mail-abuse RFCs before they'll understand this RFC.

I agree with Frank and Murray on substituting /the largest/ to /a
large/ (maybe also s/Spam/spam/, since we're at it), and leaving the
rest as-is.  (Otherwise, any global industry association larger than
MAAWG, based on such statement, can be defamed for evading working
against spam and other exploitations...)

I guess that document would have been a BCP if it had originated
within the IETF, and that's what it's actually meant to be in any
case.  That PR blurb and the second paragraph of the abstract explain
why it is Informational instead.

Another reason not to move it is that the boilerplate paragraph
following it says that MAAWG is going to retain their copyright:

   This document may not be modified, and derivative works of it may
   not be created, and it may not be published except as an Internet-
   Draft.

By publishing this spec as an RFC, the IETF acknowledges those FBL
practices, thereby taking a good position fix in the becoming of the
anti-spam endeavor.  This, in turn, will ease related and derivative
developments within the IETF; assuming that the latter ones will be
considered fair use, that is.

---

From: SM <[email-masked]>
Date: Wed, 05 Oct 2011 11:22:24 -0700

>    not be created, and it may not be published except as an Internet-

I missed that.  The Abstract mentions that:

   "While not originally written as an Internet Draft, it has been
    contributed to the IETF standards repository in order to make it
    easier to incorporate this material into IETF work."

The "no derivative" clause makes it impossible to incorporate the 
material in this draft in any IETF work.  The restriction is not 
called out correctly in draft-jdfalk-maawg-cfblbcp-02.  I commented 
previously [1] about this work when it was brought to the MARF WG and 
asked whether the draft could be resubmitted without any such 
restrictions as that is, if I am not mistaken, the usual practice for 
IETF working group work.

I would be grateful if the IESG would read my position as "against" 
in its determination of consensus.

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/marf/current/msg01091.html

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 5 Oct 2011 20:52:25 +0200

On 5 October 2011 18:28, Alessandro Vesely wrote:

Hi,

> maybe also s/Spam/spam/, since we're at it

I vaguely recall that "Spam" vs. "spam" used to be an intentional
difference in Usenet *.abuse.* newsgroups:  One variant was for
"SPiced hAM", and the other form was for "UBE" (unsolicited bulk
e-mail) or the original "Netnews Spam".  Therefore I guess it is
no typo in the draft.

-Frank

P.S.: <URL:https://duckduckgo.com/lite/?q=Monty+Python+Spam>

---

From: "John Levine" <[email-masked]>
Date: 5 Oct 2011 20:18:43 -0000

>material in this draft in any IETF work.

Section 3.3 of RFC 5378, on derivative works says:

   There are two exceptions to this requirement: documents
   describing proprietary technologies and documents that are
   republications of the work of other standards organizations.

It looks to me like the latter clause applies here. RFC 5744 has
similar language specifically for the Independent stream.

Since J.D. happens to be on the relevant MAAWG committee, he could
probably get approval to make minor changes, e.g., move the MAAWG
blurb to the end, but I would rather the IETF stop nitpicking and just
publish it.  It's a reasonable discussion of a relevant topic on which
MAAWG has more expertise than the IETF.

RFCs 5564, 5728, 5830, 5831, and 5832, all are republished and have
no-derivative notices, so this wouldn't be particularly new or
unusual.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Wed, 05 Oct 2011 16:10:01 -0700

> in a discussion about the actual substantive content of the document.
Eliot,

Thank you for asking.

In addition to PR and copyright issues that forbid modification of the 
draft, there are a few technical issues that also affect the MARF draft 
as well.  The assertion of being DDoS experts does not explain why 
potential DDoS attacks perpetrated by leveraging recipient resources 
necessary for processing SPF scripts had been overlooked.  SPF can be 
exploited to initiate a highly distributed demand against any targeted 
domain unrelated to any domain found within an attacking email campaign.

The assertion that it is difficult to forge a DKIM message overlooks the 
purpose of feedback and what these reports imply.  DKIM does NOT assure 
a domain can be held accountable for any unsolicited message which 
creates some risks to feedback resources.  The domain of the DKIM 
signature may serve as a basis for permitting feedback to the specific 
domain, but should not be used to confirm any unrelated domains.

A more serious problem exists with the use of SPF in permitting 
feedback.  This problem is made more problematic by 
Authentication-Results headers not capturing the IP address used to 
"verify" SPF records, although the MARF report includes a purported 
Source IP address.  There is still no way to determine how this 
purported IP address information had been derived, or how it might 
relate with SPF verification assertions.  An SPF record can be crafted 
to return a pass result unrelated to the originating IP address.  As 
such, SPF can be subverted to gain feedback access with lax validation 
results returned in Authentication-Results headers.  This oversight had 
been officially challenged, but never corrected. :^(

Any domain can resolve any IP address.  The draft's assertion that 
forging the IP address is difficult must be considered in respect to the 
use of SPF in qualifying for feedback.  The source IP address does not 
receive feedback.  The feedback relationship is further undermined with 
consensus on which message element, whether the EHLO, the MailFrom, or 
the PRA selects the SPF resource record.  In addition, feedback is 
likely to occur when SPF assertions fail, so it becomes imperative to 
understand what was used to initially qualify SPF feedback relationships.

In addition, this draft describes use of third-parties located at 
different domains without advising how these entities being given access 
to feedback streams are to be vetted, or whether they should be allowed 
at all.

-Doug

---

From: SM <[email-masked]>
Date: Wed, 05 Oct 2011 16:29:01 -0700

Hi John,
>MAAWG has more expertise than the IETF.

It's up to the RFC Editor to decide whether the blurb is appropriate.

>no-derivative notices, so this wouldn't be particularly new or

RFC 5564 is an Independent Submission.  RFC 5728 describes the MIB 
module for DVB-RCS.  RFC 5830, RFC 5831 and RFC 5832 are Independent 
Submissions about GOST.  For what it is worth, these three RFCs are 
about Russian Federal standards.  As for MIBs, they are considered as 
Code components.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Oct 2011 22:00:04 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Levine
> Sent: Wednesday, October 05, 2011 1:19 PM
> To: [email-masked]
> Cc: [email-masked]

Concur.  I'm in support of publication, as well as the "enough with the nitpicking already" sentiment.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 06 Oct 2011 18:32:24 +0200

On 05/Oct/11 20:22, SM wrote:
> The Abstract mentions that:
> 
> called out correctly in draft-jdfalk-maawg-cfblbcp-02.

IANAL, but my understanding is that one will be able to cite MAAWG's
RFC in other works, thereby /using/ those statements without actually
incorporating protected material literally.  Copyright should protect
the wording, not the technique.  Taking up terminology and quoting
small snippets of text should be fair use:  J.D. himself, wearing a
IETF hat, is drafting a Standard Track I-D (marf-as) that uses the
CFBL BCP that way.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 6 Oct 2011 10:01:44 -0700

> IETF hat, is drafting a Standard Track I-D (marf-as) that uses the

Yep.  A reference to a work is not a derivative of that work.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 14 Oct 2011 01:18:28 -0500

> Editor will fix it before AUTH48.

The sponsoring AD would like to know what is desired in the RFC Editor 
note: What would you like the short title to be? "CFBL Recommendations"? 
That said, I'm happy to have you fix it with other items (such as 
s/codify/document, etc.) as such come up.

As for the "About MAAWG": Personally, I think it would be better to put 
the paragraph in the Acknowledgments section, or it could be simply put 
as a paragraph in the References section under reference [1]. I find the 
Last Call discussion pretty convincing that this text is untoward in the 
Abstract.

Unlike Eliot, I am not as worried about substantive content complaints. 
These are recommendations from MAAWG, and they are being published as an 
informational, non-consensus document so that a WG can refer to the 
document. Such a WG may agree with all of the recommendations, but more 
likely will have some alternative advice when referring to this 
document. I'll certainly discuss with the IESG whether an IESG note 
explaining this is necessary, but I think the standard template ("This 
document is not an Internet Standards Track specification; it is 
published for informational purposes. It has been approved for 
publication by the Internet Engineering Steering Group (IESG).") is 
probably sufficient.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Oct 2011 09:14:36 -0400

> The sponsoring AD would like to know what is desired in the RFC Editor note:
> What would you like the short title to be? "CFBL Recommendations"?

Yes, that's consistent with the main title.

> said, I'm happy to have you fix it with other items (such as

Of course.

> As for the "About MAAWG": Personally, I think it would be better to put the
> paragraph in the Acknowledgments section, or it could be simply put as a
> paragraph in the References section under reference [1]. I find the Last
> Call discussion pretty convincing that this text is untoward in the
> Abstract.

I think those are reasonable compromises, but, of course, I can't
speak for J.D.  I suggest moving the second paragraph of the Abstract
into a new "Introduction" section that comes first in the body (new
Section 1).  Put the footnote [1] to MAAWG there, and then put the
"about MAAWG" text in the footnote.  Everyone understand that?  Makes
sense?  I think that works better than putting it in the Acks.

So it would look like this:
-----------------------------------
Abstract
   (First paragraph of current abstract.)

Status of this Memo
   (boilerplate)

Copyright Notice
   (boilerplate)

Table of Contents
   (as generated)

1. Introduction

   This paper is the result of cooperative efforts within the Messaging
   Anti-Abuse Working Group [1], a trade organization separate from the
   IETF.  The original MAAWG document upon which this document is
   based was published in April, 2010.  While not originally written as an
   Internet Draft, it has been contributed to the IETF standards
   repository in order to make it easier to incorporate this material
   into IETF work.

2. Glossary of Standard Terms
   (as current)

...etc...

9. References
   (citations as current)

   [1]  MAAWG <http://www.maawg.org/> is the largest global industry
   association working against Spam, viruses, denial-of-service attacks
   and other online exploitation.  Its' members include ISPs, network
   and mobile operators, key technology providers and volume sender
   organizations.  It represents over one billion mailboxes worldwide
   and its membership contributed their expertise in developing this
   description of current Feedback Loop practices.

   [2] (as current; etc)
-----------------------------------

> likely will have some alternative advice when referring to this document.

Exactly, and that's what MARF is doing.  So, yes, I agree with this approach.

Barry

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 14 Oct 2011 09:03:05 -0700

> Yes, that's consistent with the main title.

Agreed.

> sense?  I think that works better than putting it in the Acks.

I'm okay with either, with a slight preference for including it in the Acknowledgements section.  MAAWG understands that this kind of boilerplate is unusual for IETF documents.

Should I submit a new draft with these changes?

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 14 Oct 2011 19:43:14 +0200

> Should I submit a new draft with these changes?

I'd still prefer s/the largest/a/ or s/the largest/a large/ or similar.

Others asked about the "non-derivative" blurb, and maybe I missed the
answer for these questions.  What is the idea?  Clearly modifying the
RFC while still claiming that it is a MAAWG document without consent
of the MAAWG makes no sense.  This doesn't need extraneous legalese.

Otherwise the content of the memo is perfectly harmless, if others
wish to create their own "derivative" version, what is the problem?

Please keep the "codify",
 Frank

---

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Oct 2011 13:59:38 -0400

> I'd still prefer s/the largest/a/ or s/the largest/a large/ or similar.

I suggest that J.D. leave it as it is, and let the IESG change it if
they think it should be changed.  An RFC Editor note posted after the
telechat should take care of it, if that's what they decide, and Pete
is aware of the point.

> of the MAAWG makes no sense.  This doesn't need extraneous legalese.

That is standard boilerplate, settled on by the IETF a couple of years
ago.  It's not changing, and it's out of J.D.'s control.

It also doesn't stop anyone from doing what's intended, here, which is
citing this document from another, and specifying the ways in which
the other document differs from this one.  What it's meant to prevent
is for someone to copy the document and change a paragraph here or
there.

The changes we're talking about making, to the abstract, intro,
acknowledgments, and references, are in the IETF-specific portions
that J.D. and MAAWG put there.  Those changes can be made with J.D.'s
and/or MAAWG's agreement, without altering the fact that the body of
the document is a re-publication of the MAAWG document.

> Please keep the "codify",

As with the other point, I suggest that J.D. leave it as "codify", and
let the IESG change it if they think it's necessary.  There were two
suggestions brought up in last call ("codify" and "document"), and no
clear consensus one way or the other.

Barry

---

From: "John Levine" <[email-masked]>
Date: 14 Oct 2011 18:28:25 -0000

>I'd still prefer s/the largest/a/ or s/the largest/a large/ or similar.

This makes no sense. you believe that there is another large
organization that does what MAAWG does?

>answer for these questions.  What is the idea?

That's the normal language for for RFCs that reproduce other
organizations' documents.  There's nothing unusual about it.

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 14 Oct 2011 20:52:20 +0200

On 14 October 2011 20:28, John Levine wrote:

Hi John,

> you believe that there is another large organization that
> does what MAAWG does?

For "largest" I'd have to *know* that there's nothing else,
and that is not the case, e.g., I can't say what ECO does,
what folks in AP-regions do, and if they are already MAAWG
members or not.

I'd trust you if you'd say that the ASRG is no part of this
picture.

Too lazy to look in the member list for "missing pieces",
 Frank