Subject: Re: [apps-discuss] DMARC working group charter proposal

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Apr 2013 19:53:24 +0100

FWIW, I'm concerned about this charter text:

"The strong preference is for the working group to preserve existing
software and procedures. For changes likely to affect the installed
base, the working group will seek review and advice, beyond working
group participants, to include other developers and operators of
DMARC-based mechanisms. "

I don't know how the not-yet-formed WG can have a preference nor
how a formed-wg can seek advice "beyond the working group" with
our processes.

Both of those would seem like charter-show-stoppers to me (and
fairly reek of rubber-stamping to put it pejoratively).

We had to, and did, address similar issues with DKIM/DomainKeys
so I hope that a similar approach will also work here - its
fine for proponents of a technology to prefer no change but
its not fine to constrain an IETF WG to rule out changes, but
I reckon its actually not that hard to write down something
that works, as we eventually did in the DKIM case.

(I've not read the draft yet so this is just a comment on the
charter text, not on the meat of the proposal. I do think this
point deserves to be raised on apps-discuss given that its not
really dmarc-specific.)

Cheers,
S.

On 04/01/2013 06:25 AM, Murray S. Kucherawy wrote:
> At the IETF meeting in Atlanta, Tim Draegen presented a proposal for DMARC,
> which is an email authentication and reporting layer atop SPF and DKIM.
> The externally-developed proposal is now in widespread deployment by a
> number of large-scale providers.  The group that developed it is seeking to
> bring it to the IETF for further development and broad review, and
> development of operational guidance.
> 
> A first draft of a charter can be found linked from
> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki.
> 
> There is a [email-masked] list available for discussing the technical
> contents of the work and also this draft charter.  Please follow up there
> with any charter contents so we don't innundate this list with that
> discussion.  To subscribe to that list:
> 
> https://www.ietf.org/mailman/listinfo/dmarc
> 
> -MSK
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 1 Apr 2013 15:16:10 -0700

Hi Stephen,

We've already had this very conversation, so we're aware of the issue.  The
text we have was an attempt to re-create the same constraints DKIM had,
preferring no changes, but not completely proscribing it either.  It sounds
like we have a little more text massaging to do to make it clear that's
where were trying to go.

Thanks,
-MSK

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Apr 2013 23:22:13 +0100

> like we have a little more text massaging to do to make it clear that's

Right. If the outcome is charter text like we had with DKIM that'd
be fine. FWIW, the initial charter for DKIM said:

"Experimentation has resulted in Internet deployment of these
specifications. Although not encouraged, non-backwards-compatible
changes to these specifications will be acceptable if the DKIM working
group determines that the changes are required to meet the group's
technical objectives."

I don't know if that's something that'd work for dmarc but I
think it does hit the right note, and I think with DKIM that
worked fine. (But I'm biased of course;-)

S

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2013 16:17:21 -0700

Stephen,

DKIM had far less installed base on large operational services than 
DMARC now has.

As for not knowing how to consult outside the working group, surely you 
jest.  We do it all the time.

As for:
> I don't know how the not-yet-formed WG can have a preference

I don't know what you mean.

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Apr 2013 19:44:32 -0400

> DKIM had far less installed base on large operational services than

Right.  DKIM had no installed base.  Just for clarity (I imagine you are), 
you're referring to the DomainKeys installed base?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2013 16:58:51 -0700

> you're referring to the DomainKeys installed base?

I mean DKIM, not Domainkeys.  Domainkeys had two rounds of development 
before the ad hoc, private consortium of roughly 12 organizations met 
for a year to integrate it and cisco's Identified Internet Mail.

Some of the consortium participants implemented the original (pre-IETF) 
specification:

    http://dkim.org/Misc/Press%20Release%20July-2005b.txt

but none of that was on the scale of adoption and deployment that dmarc 
has already received.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Apr 2013 01:20:52 +0100

Hi Dave,

> DKIM had far less installed base on large operational services than

Happy to hear that but I don't think it impacts on the
points below. (Its news to me btw, but then its not my area
so that's not surprising.)

And to be clear: I do welcome folks bringing work to the
IETF, esp. where it is or will be widely deployed.

> jest.  We do it all the time.

Not with such vaguely characterised "others" and nor with
giving 'em anti-change-control that I can recall. Feel free
to point me at examples that do those things. If the text
isn't meant to severely constrain IETF change-control then
it needs a re-write 'cause it reads to me like that's the
intent.

If the "others" are actually well-known and are really
dmarc.org members then saying that would seem to be
useful to start with.

But in any case since that dmarc.org group apparently want
to cede change control then I think DKIM-like charter text
is really what'd work best.

If dmarc.org really don't want to cede change control then
the ISE route would seen more appropriate than an IETF WG.

> I don't know what you mean.

WG-doesn't-exist-yet => WG-can't-have-opinion. That ought be
trivial to fix, but is indicative of a possibly problematic
conflation of the set of folks who drafted this text and the
set of folks that might participate in a future IETF WG, which
will include people who've never seen this draft for example.

S.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Apr 2013 18:37:44 -0600

On 4/1/13 4:22 PM, Stephen Farrell wrote:
>> We've already had this very conversation, so we're aware of the
>> issue.  The text we have was an attempt to re-create the same
>> constraints DKIM had, preferring no changes, but not completely
>> proscribing it either.  It sounds like we have a little more text
>> massaging to do to make it clear that's where were trying to go.
> 
> changes to these specifications will be acceptable if the DKIM
> working group determines that the changes are required to meet the
> group's technical objectives."
> 
> I don't know if that's something that'd work for dmarc but I think
> it does hit the right note, and I think with DKIM that worked fine.
> (But I'm biased of course;-)

FWIW, the original XMPP WG (2002) had the following text in its
charter regarding backward compatibility with the existing
implementations and deployments of the Jabber protocols...

   Although not encouraged, non-backwards-compatible changes to the
   basis specifications will be acceptable if the working group
   determines that the changes are required to meet the group's
   technical objectives and the group clearly documents the reasons for
   making them.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2013 18:35:42 -0700

> implementations and deployments of the Jabber protocols...

There are important phases to the development and deployment of a 
specification.  One of those is the period immediately after release of 
a new specification, as has been done with DMARC.  Existing implementers 
have just made a large investment.  New adopters need to assess whether 
they are going to be safe in implementing the existing spec or whether 
they should wait.

Change the spec in ways that force significant -- or worse, incompatible 
-- software changes too quickly, and the adoption of the technology is 
severely disrupted due to market confusion.  The folks that did the 
X.400 email specs learned this the hard way.  Many others have too.

Hence my point about the recent, extensive deployment of DMARC.

A serious bug is one thing; those need to be fixed.  Stray changes that 
are not essential are quite another; those can be deferred.  Working 
groups often show less concern for the distinction than one would like.

The classic charter language ultimately says that a working group can do 
whatever it wants -- and no matter what 'preferences' are expressed in 
the charter text, the ultimate rule that gets specified is 'the working 
group decides whatever it wants'.  It needs a better anchor.

Hence the current draft requires consulting the installed base.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 01 Apr 2013 21:52:39 -0400

> Hence the current draft requires consulting the installed base.

If the installed base cares about backward compatibility, then they should 
show up for the working group.  The IETF is a much more open venue than where 
DMARC was incubated.  No matter how painful it is to contemplate, if it's not 
the IETF that has change control and the final say, then it's not IETF work.

I think using the DKIM charter as a model is a reasonable compromise.  I think 
there are enough people who understand deployment momentum and what's been 
done so far that you needn't worry over much about change for change sake 
being dumped on DMARC.

Scott K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Apr 2013 19:56:22 -0600

On 4/1/13 7:52 PM, Scott Kitterman wrote:

> If the installed base cares about backward compatibility, then they
> should show up for the working group.

A big +1 to that. It's not a cure-all, but it sure helps to keep a
working group from going astray.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2013 19:31:11 -0700

> working group from going astray.

so does a well-written set of constraints in the charter.  that's why 
they are commonly provided.

the current text was written with quite a bit of thought; at this point 
i've no idea how many working group charters i've/we've written, but a 
fair number have been based on importing existing technology. (i didn't 
write the charter, but i happened to be the area director with oversight 
for initially bringing nfs into the ietf.)

no doubt the current draft needs improving.  so please offer 
improvements rather than replacements or explain the inherent 
deficiencies in the current text.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Apr 2013 03:55:50 +0100

> deficiencies in the current text.

I think improvements that do replace current text have been
offered already (dkim or xmpp style text wrt maintaining
backwards compatibility) and deficiencies in the current text
have been pointed out (not clearly ceding change control)
that do motivate those improvements. Both suggested
improvements are also based on successful cases where
technologies have been brought into the IETF and one of
those (DKIM) is even closely related to dmarc.

Given that you seem to be asking for what's already been
provided, I'd say we must be close to done on this aspect:-)

S.

---

From: SM <[email-masked]>
Date: Mon, 01 Apr 2013 20:04:01 -0700

>fairly reek of rubber-stamping to put it pejoratively).

Whether it is true or not the perception will be that the proposed 
working group is rubber-stamping a specification.  The wording for 
the proposed charter sounds like the IETF does not have change 
control over the specification it is publishing.  Such an approach 
has been tried with various degrees of success.  Lack of change 
control causes unhappiness; it generates more work for WG Chairs and 
increases the probability of process issues.

It's easier to let a draft that will be used as an input document 
stand on its own merit instead of wordsmithing charter language to 
ensure a particular outcome.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Mon, 01 Apr 2013 22:33:00 -0700

On 4/1/2013 8:04 PM, SM wrote:
> Such an approach has been tried with various degrees of success.  Lack
> of change control causes unhappiness; it generates more work for WG
> Chairs and increases the probability of process issues.

SM,

Please elaborate.  In particular, when has a well-constructed charter 
constraint worked poorly?

As for generating more work for the Chairs, a major selling point behind 
tight charters is to make it easier for chairs to help the working group 
distinguish between work that is in-scope and out of scope.  Again, what 
examples do you have of a well-constructed charter constraint causing 
more work for chairs?

And what process issues do you know of that happened?

d/

---

From: SM <[email-masked]>
Date: Mon, 01 Apr 2013 23:27:35 -0700

Hi Dave,
At 22:33 01-04-2013, Dave Crocker wrote:
>Please elaborate.  In particular, when has a well-constructed 
>charter constraint worked poorly?

I'll try and explain.  It might not answer the above question.  In 
general, if the author is reluctant to give the IETF change control 
it can end up as a problem during the working group work.  The 
constraints are less about what is in the charter and more about how 
to get the group to work together.

I don't know whether the DKIM charter was well-constructed or not (I 
have not looked at it recently).  I know that the question of DKIM 
was raised in one working group.  I am not thinking about whether the 
question has merit or not; in my humble opinion it makes the work 
more difficult.

>As for generating more work for the Chairs, a major selling point 
>behind tight charters is to make it easier for chairs to help the 
>working group distinguish between work that is in-scope and out of 
>scope.  Again, what examples do you have of a well-constructed 
>charter constraint causing more work for chairs?

It is not about well-constructed charters.  The charter of a 
particular working group was tightly scoped.  However, there were 
discussions about the scope.  Scope only works well when there is a 
cohesive group.  If the group is not cohesive there will likely be 
disagreement and that will cause more work for the chairs.

>And what process issues do you know of that happened?

I'll take this off-list.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2013 12:14:37 -0700

Stephen,

> so that's not surprising.)

If affects the chartering issues fundamentally, as I've explained.

> IETF, esp. where it is or will be widely deployed.

Good to hear.  Perhaps you'll therefore consider being less terse, 
precipitous and simplistic in your responses then?

Really, Stephen, the way to encourage folks is to encourage them, not to 
post initial responses that are as dire as you've done.

Being encouraging doesn't mean saying yes to everything, but it does 
mean working to understand what they want to do and why and offering 
specific suggestions that go beyond "do it the way we've done it before 
or go away."

> it needs a re-write 'cause it reads to me like that's the

Ahh, so your concern is not what you originally stated, but is more 
nuanced.  Excellent.  That's worthy of discussion.

> dmarc.org members then saying that would seem to be

Clarifying who should be consulted and how could make complete sense.

How is it that the existing draft text "other developers and operators 
of DMARC-based mechanisms" is not sufficient"?  What would you suggest 
as better?

> is really what'd work best.

You (and SM) are confusing the difference between handing over change 
control, versus the permissible scope of work for the first effort, that 
is negotiated as part of the hand-over.

This is a balancing act, every time work is brought into the IETF.

It depends upon the maturity of the technology and the nature of its 
deployed based, as well as the list of work the community believes needs 
to be done.

For example, if you or anyone else has specific work to propose, then 
let's talk about it.  As part of the planning for bringing DMARC to the 
IETF, We did this within the dmarc.org group. We knew it's better to 
bring more 'interesting' work items to the initial round of effort in 
the IETF.  Unfortunately, we didn't see technical development tasks for 
the protocol that are needed right now.  Perhaps you or others do?

> the ISE route would seen more appropriate than an IETF WG.

You appear to think that ceding change control means that the working 
group charter must impose no constraints on the scope of what is 
permitted by the initial working group charter.  That's not the history 
of charters for existing work that's (eventually) brought into the IETF. 
  The permitted types of changes -- and possible disruption to the 
installed base -- are an inherent part of that initial negotiation, each 
time.

> trivial to fix, but is indicative of a possibly problematic

I do not know what language your are reading that asserts preferences 
for the not-yet-formed WG.

> will include people who've never seen this draft for example.

Huh?  Again, I don't know what you mean, and your terseness about a 
potentially serious point isn't helping.

General request, Stephen:  Rather than tossing off this sort off terse, 
dire assertions, please invest some effort into explaining what you mean 
and what the basis is.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Apr 2013 21:31:23 +0100

> If affects the chartering issues fundamentally, as I've explained.

Sure. But not these specific issues IMO.

> Good to hear.  Perhaps you'll therefore consider being less terse,

Terse is good I've found when dealing with folks who might
misinterpret extraneous words.

> specific suggestions that go beyond "do it the way we've done it before

Precipitous, simplistic and dire seem to me to be purely
pejorative terms. I don't think they help.

> of DMARC-based mechanisms" is not sufficient"?  What would you suggest

Best is if those who want to influence WG consensus get involved
in the WG. I can buy that not everyone has time though, but not
that some WG participants are allowed get away with "I consulted
with my unspecified friends and they don't like this proposed
change, so the charter says you can't make that change." The
current text seems too close to the latter IMO.

Again, the approach that worked for DKIM and XMPP seems to me
like it'd be fine.

> This is a balancing act, every time work is brought into the IETF.

I agree its a balancing act, and disagree that I'm at all confused.

> deployed based, as well as the list of work the community believes needs

"the community" could mean the existing dmarc.org or the putative
WG. It seems to me that the confusion (if any) is that those
are being conflated - they're clearly closely related but not
the same.

> permitted by the initial working group charter.  

Nope. The charter can describe any technical constraints and that's
perfectly reasonable, assuming the charter text gets agreed etc.
Doing new process innovations that change how WG consensus is judged
in the charter isn't the same thing. I think the current text seems
too close to the latter.

Yet again, what worked for DKIM and XMPP seems fine to me.

> That's not the history

"The strong preference is for the working group to preserve existing
software and procedures."

> potentially serious point isn't helping.

Sorry.

> dire assertions, please invest some effort into explaining what you mean

Terse != dire:-)

S.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Apr 2013 12:15:35 -0400

My sense is that this conversation's gotten too heated to shed much
light on things, so I want to try to pull it back into what the issues
are, and away from any sort of attack/defense mode.

I believe that Stephen's issue with the charter involves the
restrictions on what the working group would not be allowed to do with
the proposed DMARC spec.  So let me pick out a few quotes from the
proposed charter (
http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC ) and try to
address that, giving my own opinions on the points:

> DMARC already has achieved significant production deployment. Consequently,
> any changes to the specification that create software or operations incompatibilities
> with the installed base need to be considered carefully.

I think this states a requirement clearly, and it seems to me not to
be very controversial.  It doesn't forbid any types of changes to the
spec.  It does say that some sorts of changes "need to be considered
carefully."  Given that there's significant deployment at this point,
that seems wise.

> The strong preference is for the working group to preserve existing software
> and procedures.

Again, nothing forbidden, but it's clear that we have running code,
and requiring those deployments to roll out new core or new
operational parameters would be disruptive.  It's our *preference* not
to do that, so, again, we need to consider carefully.

> For changes likely to affect the installed base, the working group will seek
> review and advice, beyond working group participants, to include other
> developers and operators of DMARC-based mechanisms.

We have a lot of evidence that comes from development and refinement
of application-layer protocols that, while some implementors and
operators will be here participating, many will not: they have a ship
to run.  They understand that disruptive changes aren't likely, and
they're off doing what pays their bills.

This sentence is saying that if we start seriously considering a
disruptive change, we'll explicitly reach out to such operators, alert
them to what we're considering, and bring them in, asking for their
review and comment.  I think that's an acceptable approach.

> However discussion, debate and resolution of issues that target revision
> of the specification are out of scope for this working group.

This is the only sentence that I have difficulty with, for a couple of reasons:

1. The word "revision" is too broad and vague.  On the surface, it
could mean that *any* change to the specification is out of scope.
There's no point in asking the IETF to work on something for which
that's the case.

2. It puts *discussion* out of scope.  That would arguably include
discussion that could lead to the identification of a major fault or
serious omission in the spec -- a fault or omission that the vast
majority of participants might consider it critical to fix.  If we
can't discuss it, we can't determine whether it's something that rough
consensus is against, something that's a good idea that can be dealt
with later, or a critical problem that needs to be addressed now.

I understand that this is meant to prevent the working group from
becoming bogged down in repeated requests for changes that could and
should be taken up later.  But until we discuss them, we don't know
what category they fall into.  This is why we have chairs, and I would
prefer to trust the chairs to manage the discussion -- and to
appropriately manage people who are bringing issues up for discussion
just to be disruptive.

I strongly suggest changing that sentence so that it gives a more
workable characterization of what's out of scope.

Now, to Stephen:

Again, let's step back and perhaps repeat, but in clearer focus, what
your issue(s) are.  Can you quote specific text from the proposed
charter that you have an issue with, say specifically what your issue
is, and say what you'd like done about it (with specific proposed text
if you can)?

If we state that clearly, and afresh, maybe we'll have a better chance
of moving forward.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Apr 2013 10:52:09 -0700

> workable characterization of what's out of scope.

please suggest specific text that you feel would better do the job here.

d/

---

From: Barry Leiba <[email-masked]>
Date: Fri, 5 Apr 2013 14:16:27 -0400

> please suggest specific text that you feel would better do the job here.

I gave the parameters and thought you'd prefer to do the text.  But
I'm happy to propose some:

OLD
The working group will capture feedback about the existing DMARC
specification, and provide it for any future revision effort. However
discussion, debate and resolution of issues that target revision of
the specification are out of scope for this working group.
END

My first preference would be to remove that paragraph entirely; I
think the rest of the charter lays out the guidelines sufficiently.

If you really want to keep it, I think this will address my concerns:

NEW
The working group will capture feedback about possible extensions to
the DMARC specification, and provide it for any future effort.  Such
extensions and accommodation of additional use cases are out of scope
for this working group.
END

Barry

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Apr 2013 12:02:34 -0700

> extensions and accommodation of additional use cases are out of scope

Speaking as a voice of one:  wfm.  Thanks!

What do others think of it?

d/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 06 Apr 2013 00:28:22 +0100

Hiya,

On 04/05/2013 05:15 PM, Barry Leiba wrote:
> the proposed DMARC spec.  

Yep.

> So let me pick out a few quotes from the
> proposed charter (

Considered carefully seem entirely reasonable. But I think following
the template from dkim/xmpp here would however better characterise
when changes would be ok. To repeat from PSA's mail the xmpp text
was:

   Although not encouraged, non-backwards-compatible changes to the
   basis specifications will be acceptable if the working group
   determines that the changes are required to meet the group's
   technical objectives and the group clearly documents the reasons
   for making them.

Incorporating the above might mean more wordsmiting than a simple
replacement but shouldn't be hard.

> to do that, so, again, we need to consider carefully.

I quibble with the above. There's no working group that exists to
have such a preference and the above text seems to me to indicate
a lack of distinction between the proponents of this draft charter
and an eventual WG which will inevitably involve people that are
not currently involved in dmarc. The text however should be easily
fixed, e.g. replacing the above with something like:

"Preserving existing software and procedures is preferable."

But I think the dkim/xmpp template does that already and better.

However, I could live with the current text if the other changes,
or equivalents, are made and nobody else has a problem with this
part.

> review and comment.  I think that's an acceptable approach.

I'm uncomfortable with the above text but fine with the sentiment.
The problem with the text is that it seems to allow a WG participant
to say "I've asked someone I know who deploys DMARC but is too busy
to be here and they say you're wrong." Having that as a winning
argument according to the charter seems to me to be problematic.
I'd suggest something like:

"For changes likely to affect the installed base, the working group
need to carefully consider the views of developers and operators of
DMARC-based mechanisms."

But yet again the dkim/xmpp template text seems better to me.

> workable characterization of what's out of scope.

I agree with Barry's comments on this part. I think that sentence
would be better deleted with no replacement.

> If we state that clearly, and afresh, maybe we'll have a better chance

I hope that that's clear from the above.

S.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Apr 2013 16:52:26 -0700

Stephen,

On 4/5/2013 4:28 PM, Stephen Farrell wrote:
> There's no working group that exists to
> have such a preference

Currently, probably not.

I hope you aren't asserting that it hasn't been done before.

>  and the above text seems to me to indicate
> not currently involved in dmarc.

Huh?  When have charters ever made such a distinction?

d/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 06 Apr 2013 01:05:38 +0100

Dave,

>> There's no working group that exists to

Sigh. You deleted that I said both that this was a quibble
and that I could live with the current text if more
important things are fixed.

To be frank, I interpret that as purely argumentative
and not related to dmarc and hence not worth pursuing
further than this message.

S.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 05 Apr 2013 17:15:59 -0700

> To be frank, I interpret that as purely argumentative

it wasn't intended that way.

>> Huh?  When have charters ever made such a distinction?

and you neglected to respond to this, which also was meant as a serious 
question.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 06 Apr 2013 02:02:09 +0100

> it wasn't intended that way.

Well, ok, I guess.

> and you neglected to respond to this, which also was meant as a serious

I don't know that charters proposed for new wgs have or have
not included such distinctions, and haven't gone looking. I'd
not be surprised if there were lots of things that have been
proposed as charter text that never made it into any real
charter.

And yet again, I said this point is a quibble. I said I
could live with the current text if the substantive issues
are fixed. I hope that that answers your serious question
about my quibble;-)

S.