Subject: [marf] DISCUSS on draft-ietf-marf-redaction-04

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 16 Jan 2012 15:44:08 -0800

One of the security area directors has placed a DISCUSS on the above draft.  The working group needs to talk about the issue raised and determine how to proceed.

The specific issue is that a simple hash over a key prepended to the data to be redacted is not a strong security measure.  Although we've mentioned that this isn't much of a concern in our case in the proposed new text, the complaint has reappeared.  For example, the simple key-hash solution is susceptible to a few simple recovery attacks.

Among other things, the concern is that doing something like this on the standards track might lead future efforts to believe this mechanism is sufficient for arbitrary data protection when it is not.

The proposals going forward appear to be:

a) Instead of a hash of key + data, replace the algorithm with HMAC, as defined in RFC2104.

b) Add even more explanatory text so that the reader has it clear that we are not attempting to completely secure something here, and acknowledge fully that there are weaknesses in our algorithm.  (The Wikipedia page for HMAC gives a pretty good description of the comparison and attacks.)

c) Attempt to argue that it's good enough as it is, and that's how we want it.

Comments, please.

-MSK

---

From: <[email-masked]>
Date: Mon, 16 Jan 2012 19:14:18 -0500

I vote for a or b, but I have not been active in the mailing list.

Thanks,
Kathleen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Monday, January 16, 2012 6:44 PM
To: Message Abuse Report Format working group
Subject: [marf] DISCUSS on draft-ietf-marf-redaction-04

Comments, please.

-MSK
_______________________________________________
marf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/marf

---

From: Steve Atkins <[email-masked]>
Date: Mon, 16 Jan 2012 16:42:48 -0800

> c) Attempt to argue that it's good enough as it is, and that's how we want it.

b, kinda.

I'd like to add an alternative hash with the following algorithm:

1. ROT13
2. Suffix with a semicolon

That way "[email-masked]" would translate to "fgrir;@blighty.com"

That makes the email address illegal, so it cannot be mailed accidentally, and also means it can't be unthinkingly copied and pasted into a message (or made usefully clickable by a zealous MUA or...). 

For many purposes, that is a strong enough hash. For this particular purpose it might be considered a better choice than SHA* by some participants, simply because it is reversible and so will allow the recipient of a report to take action that they might not otherwise be able to do.

OK, it's a slightly frivolous suggestion, but clarifying that the encoding used only needs to be as strong as the entity redacting the message wants it to be might avoid all the concerns about security. 

The only thing that's required for the redaction not to break incident aggregation workflow - and hence be better than xxxxxx@ - is for it to be a 1:1 encoding. Beyond that, the choice of strength of encoding - on the spectrum between the identity hash ("steve" -> "steve") and an arbitrary mapping maintained privately by the report generator ("steve" -> "4783256") - is a policy choice made by the report generator.

Cheers,
  Steve

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 16 Jan 2012 19:48:37 -0500

In
<[email-masked]>,
on 01/16/2012
   at 03:44 PM, "Murray S. Kucherawy" <[email-masked]> said:

>b) Add even more explanatory text so that the reader has it clear
>that we are not attempting to completely secure something here, and
>acknowledge fully that there are weaknesses in our algorithm.  (The
>Wikipedia page for HMAC gives a pretty good description of the
>comparison and attacks.)

That's my preferred option.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Jan 2012 22:18:29 -0500

On Monday, January 16, 2012 03:44:08 PM Murray S. Kucherawy wrote:
...
> b) Add even more explanatory text so that the reader has it clear that we
> are not attempting to completely secure something here, and acknowledge
> fully that there are weaknesses in our algorithm.  (The Wikipedia page for
> HMAC gives a pretty good description of the comparison and attacks.)
> 
...

Either B or C would be my preference.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 17 Jan 2012 05:18:28 -0000

>b) Add even more explanatory text so that the reader has it clear that we are not attempting to completely
>secure something here, and acknowledge fully that there are weaknesses in our algorithm.  (The Wikipedia page
>for HMAC gives a pretty good description of the comparison and attacks.)
>

Since, as we all know, this is an argument about the thickness of a
steel door that is securing a cardboard box, my preference is for C.
If they're adamant, B would be OK.

This is kind of an unusual application for hashing, since the goal is to leak
some information.  Many measures that make sense in secure environments,
notably key rotation, would be counterproductive here.

Also, it doesn't even have to be a hash.  If I kept a database of mail
recipients, and used the record number in the database, that would work
just as well.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 17 Jan 2012 18:17:37 +0100

On 17/Jan/12 01:42, Steve Atkins wrote:
>> that we are not attempting to completely secure something here,
>> and acknowledge fully that there are weaknesses in our algorithm.
>> (The Wikipedia page for HMAC gives a pretty good description of
>> the comparison and attacks.)

I see no reason why HMAC wouldn't be an acceptable choice.  However,
I'd like the phrase "steel lock on a cardboard box" to be part of any
paragraph (of that I-D) where "HMAC" will appear.

It should be clarified that the algorithm is somewhat unimportant, as
long as it's (almost) 1:1.  ROT13, using the (hashed) record number,
or slightly truncating base64 strings (any padding "=" in particular)
are alternatives that could be mentioned in order to convey that idea.

> That makes the email address illegal, so it cannot be mailed
> accidentally, and also means it can't be unthinkingly copied and
> pasted into a message (or made usefully clickable by a zealous MUA
> or...).

+1 for the semicolon, cute way to mark diligent 1:1 redaction!

---

From: Pete Resnick <[email-masked]>
Date: Thu, 19 Jan 2012 15:52:08 -0800

> c) Attempt to argue that it's good enough as it is, and that's how we want it.

I wanted to give you all the summary of the DISCUSSion on the IESG call 
so that you can decide what you would like to do, but I'd also 
personally like to understand the WG's position. So first on my questions:

The argument against (a) seems to be "HMAC is overkill because the data 
can be retrieved other ways." Indeed, one of the (perhaps sarcastic) 
claims was that ROT13 would be as useful as the simple hash. But if 
there is any truth to these arguments, it leads me to ask: Why even 
bother with redaction at all? Why not write a document that says, 
"Redaction is stupid because all of the data can be retrieved by other 
means and when you do it stupidly (like with X's), it screws up our 
ability to do useful things with the report."? If it's truly a cardboard 
box, why not say, "Don't put a lock on this!"?

If the answer is, "because people insist on putting a lock on", then I 
think it's reasonable for someone to say, "Hey, the lock you're selling 
to these people is either made of cardboard itself, or everyone has a 
key, or whatever, and you had either better tell them about that, or 
just sell them a real lock." In other words, I don't see any harm in 
using HMAC, other than it's as much of a waste of time as doing a simple 
hash or ROT13 or nothing at all.

So could someone explain why choosing HMAC is any more silly than doing 
the hash? Or why there is any objection to doing HMAC (since it isn't 
hard to do)?

That said, as of today's telechat, the IESG in general (and Stephen in 
particular, who holds the DISCUSS) are fine with either (a) or (b) and 
Stephen will clear his DISCUSS and I will approve the document once you 
do one or the other in the doc. But do understand that (b) means 
explaining that MD5 is a bad plan, and empty data is a bad plan, and all 
of the other caveats of using a simple hash. If the WG is willing to put 
that stff into security considerations, nobody is going to hold up the 
document. On the other hand, we will be left wondering, cause it seems a 
bit silly not to just use HMAC.

But it is up to the WG.

pr

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jan 2012 16:20:09 -0800

As a participant, I don't have any particular skin in this argument, so I'll go with consensus, which I'm supposed to do as co-chair anyway.  :-)

The one thing not mentioned so far is the fact that there's tell of sites that have implemented the H (hash-key) scheme as we currently have it, versus HMAC.  More specifically, there's one large European ISP that has said they have implemented what the -04 version of this draft said.  I don't know if there are others, nor do I know if they are tracking this work well enough to know they should change if the WG decides to move to HMAC.

We can't argue, though, that this creates an interop concern with the existing deployed base, because there's no actual interoperation in the traditional client/server sense here; if one party is doing it with H and one is doing it with HMAC, they're going to get the same results in the end anyway, minus a few possible paths to stealing the redaction key (even though, as we've said, there are easier ways to mount that attack) in the HMAC case.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jan 2012 16:47:00 -0800

> From: Pete Resnick [mailto:[email-masked]]
> Sent: Thursday, January 19, 2012 3:52 PM
> To: Murray S. Kucherawy
> Cc: Message Abuse Report Format working group
> Subject: Re: [marf] DISCUSS on draft-ietf-marf-redaction-04
> 
> using HMAC, other than it's as much of a waste of time as doing a
> simple hash or ROT13 or nothing at all.

It's my understanding that "people insist" is indeed the answer.  It's a checklist item that local policy imposes.  The simple string substitution redaction that first appeared made the feedback system work less well because it made correlation impossible, and this is the proposed solution.  It's not meant to be bulletproof, just good enough to satisfy both the policy people that wand some kind of redaction and the technical people that have to find a non-destructive way to do it.

> the hash?

It's not more silly.  The point is that H is good enough to achieve the above goals.  If there's a scale from 0 to N where the goal is achieved at, say, 5, H gets us to 5 while HMAC gets us to 10000.  It just seems like overkill, especially since mounting an attack against H is probably more expensive than just log trolling.

> Or why there is any objection to doing HMAC (since it isn't
> hard to do)?

I don't recall any objection beyond the above.

> But it is up to the WG.

Yup.  I'm ready to make whichever change gets consensus.

-MSK

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Jan 2012 20:07:17 -0500

> Indeed, one of the (perhaps sarcastic) claims was
> that ROT13 would be as useful as the simple hash. But if there is any truth
> to these arguments, it leads me to ask: Why even bother with redaction at
> all? Why not write a document that says, "Redaction is stupid because all of
> the data can be retrieved by other means and when you do it stupidly (like
> with X's), it screws up our ability to do useful things with the report."?
> If it's truly a cardboard box, why not say, "Don't put a lock on this!"?
>
> If the answer is, "because people insist on putting a lock on"

Yes, as Murray has said.  But this reminds me, and perhaps you (Pete)
can talk with Stephen and Sean about this:
Several (as opposed to a few) IETF meetings ago, there was discussion
(from a presentation by EKR, if I remember correctly) about the
usefulness of defining what is *specifically* an INSECURE hash.  Do
something like, say, re-define MD5 and call it "IHA-1" (Insecure Hash
Algorithm 1).  Then it could be used in cases where a hash was needed,
but there was no security need for the hash, and no one would say,
"Oh!  Oh!  You can't use MD5!  It's too weak and vulnerable!  Oh!"
(Think Arnold Horshack here, for those young enough to understand the
reference.)

This is exactly one of those use cases.

But we never defined any IHA-1, and so we have to either say, "Use any
damned hash you want (CRC included, to use David Black's silly example
from the GenART review), because it doesn't matter, and if *you* want
to make it more secure, because, you know, your local policy demands
it, well, then, that's fine, and you know how to do it," or else
succumb to pressure to kick it into crypto orbit with HMAC because
"It's not hard."

Go back and read EKR's slides from SAAG at IETF 73:
http://www.ietf.org/proceedings/73/slides/saag-0.pdf
...and tell me that it really matters that we say *anything* about
what hash to use.

Barry

, then I think
> it's reasonable for someone to say, "Hey, the lock you're selling to these
> people is either made of cardboard itself, or everyone has a key, or
> whatever, and you had either better tell them about that, or just sell them
> a real lock." In other words, I don't see any harm in using HMAC, other than
> it's as much of a waste of time as doing a simple hash or ROT13 or nothing
> at all.
>
> So could someone explain why choosing HMAC is any more silly than doing the
> hash? Or why there is any objection to doing HMAC (since it isn't hard to
> do)?
>
> Stephen will clear his DISCUSS and I will approve the document once you do
> one or the other in the doc. But do understand that (b) means explaining
> that MD5 is a bad plan, and empty data is a bad plan, and all of the other
> caveats of using a simple hash. If the WG is willing to put that stff into
> security considerations, nobody is going to hold up the document. On the
> other hand, we will be left wondering, cause it seems a bit silly not to
> just use HMAC.
>
> But it is up to the WG.
>
> pr
>
> --

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Jan 2012 23:03:03 -0500

On Thursday, January 19, 2012 04:47:00 PM Murray S. Kucherawy wrote:
> It's not more silly.  The point is that H is good enough to achieve the
> above goals.  If there's a scale from 0 to N where the goal is achieved at,
> say, 5, H gets us to 5 while HMAC gets us to 10000.  It just seems like
> overkill, especially since mounting an attack against H is probably more
> expensive than just log trolling.

My objection is it's overkill.  Over specifying because someone is afraid that 
someday someone may point to this as an example to be insecure when it does 
matter is a silly reason.  

Scott K

---

From: "John Levine" <[email-masked]>
Date: 20 Jan 2012 04:04:57 -0000

> If it's truly a cardboard box, why not say, "Don't put a lock on this!"?

Lawyers, of course.  But having talked to some of the people who do
redaction, it's not quite as stupid as it might seem.

The party that originally sent the mail can in most cases figure out
who they sent message to, either by comparing logs or by looking at
other clues in the message.  People who didn't send the message
generally can't.  So in the not uncommon case that you're sending FBL
data to a provider which has customers who run their own mail servers,
the customers who sent the mail can de-redact if the provider forwards
them the reports.  The provider can't, but can still use the hash to
help figure out whether their customers are misbehaving.

>the hash? Or why there is any objection to doing HMAC (since it isn't 

It just seems pointless.  The suggestions for key rotation were
actively misguided.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Jan 2012 23:16:03 -0800

Would a path forward be to do this?:

1) Change the algorithm in Section 2 to use HMAC.

2) Add a Section 2.1 that talks about extant implementation(s) that use only H, even though it's known to be attackable, because (reasons to tolerate the vulnerabilities that we've already given).

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jan 2012 12:53:53 -0500

> 1) Change the algorithm in Section 2 to use HMAC.

My objection to that path forward is that there's NO interoperability
benefit given by prescribing any hash function.  What this document
does for interoperability is define a mechanism that, if used
consistently, will provide the interop we want/need.  It only matters
that the redactor consistently use the same hashing.  It doesn't
matter AT ALL *what* that hashing is.  I think it's not a good idea to
over-specify.

I think the way forward is to explain why we don't need cryptographic
security here, and why the specific hash function chosen doesn't
matter, as long as the redacted value stays the same for the same
unredacted input.  And that's all.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jan 2012 10:06:22 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Friday, January 20, 2012 9:54 AM
> To: Murray S. Kucherawy

What do you think might be missing from the current Security Considerations to nail this point home to the IESG's satisfaction?  Basically, I thought we'd done this already in -05.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Fri, 20 Jan 2012 13:03:20 -0500

In
<[email-masked]>,
on 01/20/2012

>unredacted input.  And that's all.

++

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Jan 2012 13:34:39 -0500

On Friday, January 20, 2012 10:06:22 AM Murray S. Kucherawy wrote:
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Barry Leiba
> What do you think might be missing from the current Security Considerations
> to nail this point home to the IESG's satisfaction?  Basically, I thought
> we'd done this already in -05.

If this issue, AIUI, is that someone is worried that later this will be 
referenced in an inappropriate way, I'm not sure what would satisfy that.  I 
think it's already clear.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jan 2012 13:35:08 -0500

> to nail this point home to the IESG's satisfaction?  Basically, I thought we'd
> done this already in -05.

I'd thought so, as well, so I don't know the answer to your question.
I'll be happy to try tossing out some text.

Another thought occurred to me, from what Pete has said:

Pete's question is, "Why NOT use HMAC?"

That's the wrong question; it's the IESG overstepping its authority,
if they insist that that's the question.  The IESG is objecting to
what the working group has come up with, and the burden is on them to
show that what we have is not sufficient FOR THIS USE CASE.  The
question isn't, "Why NOT use HMAC?"

The correct question is, "For our use case, WHY REQUIRE HMAC?  What
does it give us that is necessary for our use case?"

The amount of "security" in the redaction is ENTIRELY up to the
redactor.  Given this spec, the redactor is welcome to use HMAC if
they want to -- if they or their lawyers think they need that level of
confidence that it can't be deciphered.  Depending upon the redactor's
sensibilities, they are also welcome to use plain SHA1, or MD5, or
CRC, or, hey, just base64-encode the plain-text string if all you want
is to keep it away from idle eyes.

It makes no sense for this spec to declare anything in this regard.

Barry

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jan 2012 10:49:37 -0800

> Sent: Friday, January 20, 2012 10:35 AM
> To: Murray S. Kucherawy
> redactor.  Given this spec, the redactor is welcome to use HMAC if they
> want to -- if they or their lawyers think they need that level of
> sensibilities, they are also welcome to use plain SHA1, or MD5, or CRC,
> or, hey, just base64-encode the plain-text string if all you want is to
> keep it away from idle eyes.
> 

Does that mean, in Section 2, we could replace steps 1 through 4 with something more generic, like simply "Apply any isomorphic transformation to each instance of private data in this message", and suggest a range of possibilities from base64 to rot13 to CRC32 to H to HMAC, depending on the site's needs, perhaps with requisite admonition to be aware of the strengths and weaknesses of each?

That would mean Section 3 becomes a lot simpler as well.

---

From: SM <[email-masked]>
Date: Fri, 20 Jan 2012 10:57:59 -0800

Hi Scott,
>think it's already clear.

I don't think so.  One of the points mentioned by Murray [1] was:

   "the concern is that doing something like this on the standards
    track might lead future efforts to believe this mechanism is
    sufficient for arbitrary data protection when it is not."

One of the questions asked by the Responsible AD [2] was:

   "why there is any objection to doing HMAC (since it isn't hard to do)?"

The text from the DISCUSS is:

  "I don't think that's ok. I think you want HMAC() and not H().

   If I could supply a redactor with a zero length "private" string,
   e.g. message with a header field like "To: @example.org" then the
   redactor will send H(redaction-key) which can then allow (via
   hash-continuation) checking if any value matches a value from an
   output here.

   If the alphabet for sensitive values has N characters
   then I can also send "To: "+char[i]+"@example.org" for
   each i and then play the continuation game on that.
   Same for two character prefixes etc.

  (2) I can also use this to validate guesses of the redaction
  key value. I need to think about how one might avoid that
  or if its possible to avoid that."

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/marf/current/msg01681.html
2. http://www.ietf.org/mail-archive/web/marf/current/msg01691.html

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Jan 2012 14:04:30 -0500

> Does that mean, in Section 2, we could replace steps 1 through 4 with something
> more generic, like simply "Apply any isomorphic transformation to each instance
> of private data in this message", and suggest a range of possibilities from base64
> to rot13 to CRC32 to H to HMAC, depending on the site's needs, perhaps with
> requisite admonition to be aware of the strengths and weaknesses of each?
>

That would work for me.

Barry

---

From: Steve Atkins <[email-masked]>
Date: Fri, 20 Jan 2012 11:04:53 -0800

> Does that mean, in Section 2, we could replace steps 1 through 4 with something more generic, like simply "Apply any isomorphic transformation to each instance of private data in this message", and…

I think that would improve it in general, as well as avoiding some of the supposed security concerns.

Cheers,
  Steve

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jan 2012 11:08:20 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Friday, January 20, 2012 11:05 AM

Pete, do you think this approach would fly?

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Jan 2012 14:40:35 -0500

On Friday, January 20, 2012 10:57:59 AM SM wrote:
> >referenced in an inappropriate way, I'm not sure what would satisfy that. 
> >I think it's already clear.
> 

Thanks for the clarification.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jan 2012 15:08:33 -0800

> Sent: Friday, January 20, 2012 11:08 AM

Stephen, Barry and I like the proposed changes visible now at http://www.blackops.org/~msk/marf.html.  This would clear the discuss and allow publication as long as Pete also agrees.

MARF participants, please review this and provide any feedback, including support or requested changes.  I'll post it Monday morning unless I hear some objection.

I need to adjust the bit around the mention of encoding non-ASCII stuff because it might also be necessary to base64-encode redacted data if the redacted form includes spaces, but that's a very minor change.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Jan 2012 17:40:01 -0600

> Pete, do you think this approach would fly?

Sorry for not getting back to you earlier; tied up in meetings all 
afternoon. But you did hear back from Stephen: This would address his 
concerns. This way, you're not saying that H is a good idea for 
redaction without explaining the limited meaning of "redaction" that 
this document anticipates. I would like to see a "MAY" appear somewhere 
in section 3 of your proposed text to indicate that the choice of 
algorithm is a protocol option. (E.g., "An implementation MAY choose one 
of ROT13, CRC32, MD5, H, HMAC, or any transformation that has a 
reasonably low likelihood of collision...blah...blah...blah..."). And I 
think you're likely to need references for the example algorithms you do 
give, and maybe a a quick line about the features of each, (e.g., "ROT13 
(manually invertible, but visually obscure), CRC32 (invertible by code, 
but not simply by a human), ..."). But I think this is perfectly reasonable.

pr

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jan 2012 15:53:00 -0800

> Sent: Friday, January 20, 2012 3:40 PM
> To: Murray S. Kucherawy
> algorithm is a protocol option. (E.g., "An implementation MAY choose
> one of ROT13, CRC32, MD5, H, HMAC, or any transformation that has a
> think you're likely to need references for the example algorithms you
> do give, and maybe a a quick line about the features of each, (e.g.,
> "ROT13 (manually invertible, but visually obscure), CRC32 (invertible
> by code, but not simply by a human), ..."). But I think this is
> perfectly reasonable.

I doubt there's a formal definition of ROT13 anywhere, but I'll look for the rest.  If anyone has references handy, please do post them and save me the time of going to track them down.

The list I would use would include at least these, which need references:

- ROT13
- CRC32
- MD5
- SHA (already have the FIPS-180 reference)
- H
- HMAC (already cite an RFC for this one)
- full encryption a la what openssl can do (does this have a formal name and a good reference?)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 20 Jan 2012 15:58:18 -0800

> by code, but not simply by a human), ..."). But I think this is

(Oops, wasn't quite done yet.)

I'm not clear on the suggestion about MAY.  We already present the choice; a MAY here would mean you can opt not to do any of these, which isn't redaction at all, and this whole memo doesn't apply.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Jan 2012 18:01:13 -0600

OBE if you go with the new path, but to follow up:

On 1/20/12 12:35 PM, Barry Leiba wrote:
> what the working group has come up with...
>    

You will note that I quite carefully and explicitly split my questions 
about the WG's intent from the IESG's DISCUSS questions. The question of 
"Why NOT use HMAC?" was mine. The IESG did not ask that question and in 
no way overstepped its authority. *I* thought it important to understand 
why the WG was choosing not to use HMAC (and answer I really haven't 
gotten, but again, it sounds like it's moot). The IESG DISCUSSion said, 
"Either you need to use HMAC or explain the failings with H ('IHA') so 
that readers understand what they do and do not get with H." That is 
perfectly within bounds.

> and the burden is on them to
> show that what we have is not sufficient FOR THIS USE CASE.

Sorry, no. I suspect that the issue really is that the document does not 
sufficiently define the use case to make it clear that H (or anything in 
particular) is appropriate. That's why one of the solutions given was, 
"Explain the limitations of H". If the use case was simply, "not easily 
reversible by a human", BASE64 is perfectly reasonable and H is probably 
overkill. But the document did not outline the use case and left open 
the question of what was necessary.

> does it give us that is necessary for our use case?"

Again, the IESG did not require you to use HMAC. It was either use HMAC, 
or make clear the limitations of H. I think that defining the use case 
would have also sufficed (though perhaps gotten some quizzical looks 
about, "Then why not just use BASE64?", but without the DISCUSS.)

> It makes no sense for this spec to declare anything in this regard.

I think that is correct and on what we all agree.

pr

---

From: "John Levine" <[email-masked]>
Date: 21 Jan 2012 00:03:21 -0000

>> algorithm is a protocol option. (E.g., "n...blah...blah...blah...A").

I'd suggest not stepping back into the tarpit, and say

  An implementation MAY choose any transformation that has a
  reasonably low likelihood of collision.

Leave it at that.

R's,
John

PS: http://catb.org/~esr/jargon/html/R/rot13.html

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Jan 2012 18:12:08 -0600

> I'm not clear on the suggestion about MAY.  We already present the choice; a MAY here would mean you can opt not to do any of these, which isn't redaction at all, and this whole memo doesn't apply.

"MAY choose A, B, or C" is not equivalent to "MAY choose A, B, C, or 
none of the above". For example, from RFC 5321:

    Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
    and extension name keywords) are not case sensitive, with the sole
    exception in this specification of a mailbox local-part (SMTP
    Extensions may explicitly specify case-sensitive elements).  That is,
    a command verb, an argument value other than a mailbox local-part,
    and free form text MAY be encoded in upper case, lower case, or any
    mixture of upper and lower case with no impact on its meaning.

In this case, I'm not sure what opting to not do any of those might mean.

On the other hand, I'm also fine with John Levine's suggestion:

pr

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 20 Jan 2012 19:34:08 -0500

On Friday, January 20, 2012 03:08:33 PM Murray S. Kucherawy wrote:
> Stephen, Barry and I like the proposed changes visible now at
> http://www.blackops.org/~msk/marf.html.  This would clear the discuss and
> allow publication as long as Pete also agrees.
> 
> MARF participants, please review this and provide any feedback, including
> support or requested changes.  I'll post it Monday morning unless I hear
> some objection.
> 
> I need to adjust the bit around the mention of encoding non-ASCII stuff
> because it might also be necessary to base64-encode redacted data if the
> redacted form includes spaces, but that's a very minor change.

Seems reasonable to me.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Sat, 21 Jan 2012 12:15:35 -0500

> You will note that I quite carefully and explicitly split my questions about
> the WG's intent from the IESG's DISCUSS questions. The question of "Why NOT
> use HMAC?" was mine. The IESG did not ask that question and in no way
> overstepped its authority.

Ah, sorry.  I will note that either you weren't careful and explicit
enough or (more likely) I simply missed it.  I was committing a bit of
hyperbole here, and didn't really think the IESG was going over the
edge... but I did think the "explain why you won't use HMAC, or else
use HMAC" think was what was required to clear the DISCUSS position.

As it turns out, what was really needed was for us to better explain
what the redaction is trying to do, so it's clear why the specific
encoding doesn't matter and needn't be specified here.  And, of
course, that *is* reasonable for the IESG to ask.  That done, all is
well.

Please forgive me for being inappropriately inflammatory in my
hyperbolicness.  Probably I was a little grumpy at the time, as well.

Barry, who will now get back to chairing quietly in his chair

---

From: Pete Resnick <[email-masked]>
Date: Sun, 22 Jan 2012 12:01:49 -0600

So, let me answer your message in reverse:

> Barry, who will now get back to chairing quietly in his chair

Please don't. I hope (indeed *want*) serious technical pushback to the 
IESG from WG members and chairs when any AD (myself included) makes a 
technical claim that might be wrong. In this case, pushing back on 
Stephen for asking for HMAC was entirely appropriate: The fact is that 
HMAC *is* overkill for this protocol, but we (the WG) hadn't yet clearly 
spelled out why in the document, and the fact that we were using a hash 
algorithm muddied the waters, because it was probably overkill as well 

> course, that *is* reasonable for the IESG to ask.  That done, all is

So, technical pushing back on this was good and I want more of that. The 
only thing that I was concerned about was your statement that this was 
an "overstepping its authority" situation. As I expect you know, I take 
these sorts of appeal-worthy process things pretty darn seriously. If 
you (or anyone) think something is going a-foul of process (especially 
the IESG overstepping authority), please bring that to me immediately. 
In particular, don't throw it into the middle of a technical discussion 
on a WG list. Aside from it not being the best venue, it also can get 
things rather contentious rather quickly. I do want to hear about and 
discuss these things, and as you said, perhaps I wasn't careful enough 
in my message to keep the "Pete questions" separated enough from the 
"IESG issues", but let's all try to keep those discussions cleanly 
separated.

> hyperbolicness.  Probably I was a little grumpy at the time, as well.

No need for apology, and completely forgiven. I will also ask for a bit 
of forgiveness myself, as I was also likely grumpier than necessary due 
to being a bit sick this past week (food poisoning blows), and having 
spent my recovery time on an IESG telechat. But my intention was not to 
be scolding, and I'm sorry that it came off that way.

> use HMAC" think was what was required to clear the DISCUSS position.

A misunderstanding, and I think we're all on the correct page now.

Your (perhaps not sufficiently) humble servant.

pr

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 Jan 2012 10:51:24 -0800

On 1/22/2012 10:01 AM, Pete Resnick wrote:
>  I hope (indeed *want*) serious technical pushback to the IESG from
> WG members and chairs when any AD (myself included) makes a technical claim that
> might be wrong.

I'll suggest that "pushback", per se, is the tactical point.  The strategic 
point is the dual obligation for:

    1) the AD to be (more?) clear about their underlying concerns and not just 
assert the problem or the solution they think will resolve it, as well as the 
requirement that they engage in a /direct/ dialogue with the working group, and

    2) the working group to be (more?) clear about its underlying goals and 
requirements, as well as engaging in real and constructive dialogue with the 
AD(s) toward a useful resolution, rather than merely one that pacifies the ADs.

I have more than my share of just getting pissed off at ADs who lodge vague and 
even inappropriate Discusses and can attest that while pushing back is fine, 
indulging in being pissed off is never helpful, even when they warrant the 
reaction.  (That's meant merely to mark an extreme, not claim it applied here.)

Unfortunately, my review of the current wg's mailing list record shows quite a 
bit less of #1 than there should be, IMO, in spite of Pete's active, follow-on 
participation.  (And I note that the Discuss is not yet cleared...)

Stephen has not engaged directly.  Now it well might be that Pete has been an 
adequate surrogate, but forgive me, it is Stephen who holds the Discuss.

It really is essential that a wg not be forced to guess what will satisfy ADs 
who hold Discusses.

As a matter of due diligence, I'll also ask folks whether they believe the 
modifications to the specification retain its previous level of utility and 
pedagogy as a specification, for strangers out there in implementation land who 
lack the background from participating in the working group?  I ask this because 
sometimes handling the one point raised by a Discuss alters the answer for other 
aspects of the spec...

> So, technical pushing back on this was good and I want more of that. The only
> thing that I was concerned about was your statement that this was an
> "overstepping its authority" situation.

If one reviews Stephen's Discuss, one sees an engineer asserting the details of 
an alternative solution, with what is really none of the underlying concepts or 
issues that might justify it.  However the concerns in the underlying stuff are 
the real substance.

Perhaps my reading comprehension is inadequate here, but I simply don't see the 
material a working group ought to be given, to permit serious dialogue.

Forgive me, but that really /is/ overstepping (or understepping) the role of the 
IESG at this stage, IMO, even if the suggestion is the right one.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Sun, 22 Jan 2012 11:41:11 -0800

Hi Dave,
At 10:51 22-01-2012, Dave CROCKER wrote:
>As a matter of due diligence, I'll also ask folks whether they 
>believe the modifications to the specification retain its previous 
>level of utility and pedagogy as a specification, for strangers out 
>there in implementation land who lack the background from 
>participating in the working group?  I ask this because sometimes 
>handling the one point raised by a Discuss alters the answer for 
>other aspects of the spec...

The title of the draft is "Redaction of Potentially Sensitive Data 
from Mail Abuse Reports".  The draft is about addressing the following:

   "Previous redaction practices, such as replacing local-parts of
    addresses with a uniform string like "xxxxxxxx", often frustrates any
    kind of prioritizing or grouping of reports."

The desired outcome is to allowing grouping of reports.  What the 
specifications ends up doing is trying to protect "Potentially 
Sensitive Data".  I found version -03 useful for strangers as it 
basically recommends to use a hash/digest instead of "xxxxxxxx".  The 
most important point in that version was:

   "it is extremely unlikely that report generation software could
    ever be created to recognize all of the different ways that
    private information may be expressed through human written
    language"

Regards,
-sm

---

From: SM <[email-masked]>
Date: Sun, 22 Jan 2012 14:01:11 -0800

Hi Barry,
>Barry, who will now get back to chairing quietly in his chair

I fully support the WG co-chair.  I found your advice useful; for example:

   "As it turns out, what was really needed was for us to better explain
    what the redaction is trying to do, so it's clear why the specific
    encoding doesn't matter and needn't be specified here.  And, of
    course, that *is* reasonable for the IESG to ask.  That done, all is
    well."

Regards,
-sm

---

From: Pete Resnick <[email-masked]>
Date: Sun, 22 Jan 2012 18:21:12 -0600

I think Dave is exactly right on just about everything here. I have a 
couple of issues with the details of some of the logistics, but it is in 
the details. For those who want to see my thoughts on sausage making, 
continue below.

On 1/22/12 12:51 PM, Dave CROCKER wrote:

> I'll suggest that "pushback", per se, is the tactical point.

I should have been more clear that I intended exactly your strategic 
point: Engage.

> The strategic point is the dual obligation for:
>
>    1) the AD to be (more?) clear about their underlying concerns and 
> not just assert the problem or the solution they think will resolve 
> it, as well as the requirement that they engage in a /direct/ dialogue 
> with the working group, and
>
>    2) the working group to be (more?) clear about its underlying goals 
> and requirements, as well as engaging in real and constructive 
> dialogue with the AD(s) toward a useful resolution, rather than merely 
> one that pacifies the ADs.

Absolutely agree on both counts. How that direct dialogue occurs is an 
interesting question; more on that below. But the AD's concerns must be 
clear, and the WG should look to address the concern (even if addressing 
it is, "we have documented that we understand the concern and we feel it 
is not a problem we will solve), not just appease.

> I have more than my share of just getting pissed off at ADs who lodge 
> vague and even inappropriate Discusses and can attest that while 
> pushing back is fine, indulging in being pissed off is never helpful, 
> even when they warrant the reaction.  (That's meant merely to mark an 
> extreme, not claim it applied here.)

+1!

> Unfortunately, my review of the current wg's mailing list record shows 
> quite a bit less of #1 than there should be, IMO, in spite of Pete's 
> active, follow-on participation.

Yup. And in this case, I think that, until I jumped in, #2 wasn't going 
so well either. (That is, Stephen's DISCUSS comment was -- and 
unfortunately is still written as -- "H has problems; you want HMAC", 
and the WG's response was, "HMAC is overkill", instead of figuring out 
that the problem was the lack of clear text on the use case, and the 
solution being to clarify the use case, and probably state that neither 
H nor HMAC was necessary.)

> (And I note that the Discuss is not yet cleared...)

An unfortunate side effect of there not being an appropriate tool. ADs, 
both the ones issuing the DISCUSSes and the ones managing the WG getting 
the DISCUSSes, have turned the ballot position into an issue tracker. 
That's dumb and needs to be fixed. But I'm guilty of this too. A long 
and different discussion I'm happy to have in some other forum.

> Stephen has not engaged directly.  Now it well might be that Pete has 
> been an adequate surrogate, but forgive me, it is Stephen who holds 
> the Discuss.

So let me talk a bit about direct engagement. It's not the standard 
thing for the IESG now, but you're going to see more of it soon. During 
the last WG chair lunch, we had a discussion about copying all ballot 
DISCUSSes and COMMENTs to the WG mailing list and I think this is 
exactly the right thing to do. My plan is to, on a case by case basis at 
first, add the WG list to the magic field in the datatracker to which 
such comments go. The only issue is that this has to be reasonably managed.

First, keep in mind that ADs make lots of comments (DISCUSSes and 
otherwise) and it would be quite a lot of mail for an AD to get if they 
got the full flood from every mailing list they sent a comment to, 
especially because so many of us make a slew of comments all during the 
telechat week. (Yeah, we're pretty poor planners.) So when we do direct 
engagement, I'm going to ask a bit of forbearance from the WG and try to 
avoid flooding the poor schlump AD who made a comment with a huge number 
of messages. But that's just a matter of being a bit more "conservative 
in what they send" when an AD is in the mix. (And I'm only talking about 
volume, not tone. :-) ) We can figure out how to do that.

Second, note that currently all DISCUSS and COMMENT messages and all of 
their replies are Cc'ed to the IESG list. Just flipping the switch on 
would be potentially a *lot* of email to the IESG list. So we may want 
to figure out a way to split the "WG is mulling this over" messages from 
the "we have a response to this" messages.

Finally, the current model has the AD directly engaging with *only* the 
editors and the chairs. Sometimes that's helpful because having only a 
few people chatting with the AD to understand the AD's issue is often 
easier than having the entire WG have that conversation. But that also 
means that sometimes the chairs or the editors come up with solutions to 
the AD's issue that the WG wouldn't buy into. (Jeez, I hope that's 
rare.) Bringing everyone into the conversation is again going to require 
a little mental shift so that people (WG chairs especially) get used to 
how to manage these conversations.

All of these are simply (?!) cultural changes about how direct 
engagement will work. I think direct engagement is a *much* better 
model, but it does have side effects, and I want to make sure that those 
side effects don't cause a backlash against doing so. Right now, the 
model is "only do direct engagement once there's a problem", which is 
the wrong model. But I want to minimize heartburn while getting to the 
right model.

So, with all that said, I'm happy to get Stephen directly engaged on 
this particular topic, though I think we now have a pretty good handle 
on what the issue is and how to deal with it. I'll leave it to the 
chairs to tell me what level of involvement they think is good at this 
point.

> It really is essential that a wg not be forced to guess what will 
> satisfy ADs who hold Discusses.

+1.

> As a matter of due diligence, I'll also ask folks whether they believe 
> the modifications to the specification retain its previous level of 
> utility and pedagogy as a specification, for strangers out there in 
> implementation land who lack the background from participating in the 
> working group?  I ask this because sometimes handling the one point 
> raised by a Discuss alters the answer for other aspects of the spec...

You bet!

> If one reviews Stephen's Discuss, one sees an engineer asserting the 
> details of an alternative solution, with what is really none of the 
> underlying concepts or issues that might justify it.  However the 
> concerns in the underlying stuff are the real substance.
>
> Perhaps my reading comprehension is inadequate here, but I simply 
> don't see the material a working group ought to be given, to permit 
> serious dialogue. 

In retrospect, I completely agree. Stephen's DISCUSS comment is how to 
address what he believes the issue to be, not a discussion of what the 
issue really is. If his assessment of the issue is correct, that might 
be a real timesaver, but if it's wrong, well, we get to where we are now.

> Forgive me, but that really /is/ overstepping (or understepping) the 
> role of the IESG at this stage, IMO, even if the suggestion is the 
> right one.

I agree with understepping, not overstepping. We've all gotten into bad 
patterns with the goal of helping things move faster. (You will note 
that the IESG Statement on DISCUSS Criteria talks about always making 
DISCUSS comments "actionable".) As I said above, when it works, great, 
but when it doesn't, it causes bad feelings. In this case, Stephen 
wasn't trying to force a particular technical solution, and therefore I 
don't think he was exceeding his authority. But neither he nor the WG 
initially figured out what the real problem was, and that's a 
shortcoming in what happened.

Thanks for a good analysis, as well as an opportunity to talk about what 
I'd like to do to address these problems.

pr

---

From: SM <[email-masked]>
Date: Sun, 22 Jan 2012 17:40:25 -0800

Hi Pete,
>I should have been more clear that I intended exactly your strategic 

And try to sift thought the misunderstandings.

>Yup. And in this case, I think that, until I jumped in, #2 wasn't 
>going so well either. (That is, Stephen's DISCUSS comment was -- and 
>unfortunately is still written as -- "H has problems; you want 
>HMAC", and the WG's response was, "HMAC is overkill", instead of 
>figuring out that the problem was the lack of clear text on the use 
>case, and the solution being to clarify the use case, and probably 
>state that neither H nor HMAC was necessary.)

You were trying to address the DISCUSS comment.

>thing for the IESG now, but you're going to see more of it soon. 
>During the last WG chair lunch, we had a discussion about copying 
>all ballot DISCUSSes and COMMENTs to the WG mailing list and I think 
>this is exactly the right thing to do. My plan is to, on a case by 
>case basis at first, add the WG list to the magic field in the 
>datatracker to which such comments go. The only issue is that this 
>has to be reasonably managed.

A WG Chair can always copy the DISCUSS and COMMENT to the WG mailing 
list.  This is the type of information that might be useful on the 
relevant wiki.

>Second, note that currently all DISCUSS and COMMENT messages and all 
>of their replies are Cc'ed to the IESG list. Just flipping the 
>switch on would be potentially a *lot* of email to the IESG list. So 
>we may want to figure out a way to split the "WG is mulling this 
>over" messages from the "we have a response to this" messages.

If "we" used our discretion to cut down Cc to relevant information, 
it might help.

>model, but it does have side effects, and I

It's a lot of work.

>In retrospect, I completely agree. Stephen's DISCUSS comment is how 
>to address what he believes the issue to be, not a discussion of 
>what the issue really is. If his assessment of the issue is correct, 
>that might be a real timesaver, but if it's wrong, well, we get to 
>where we are now.

Yes.  And it is an eye-opener on how the average reader might read 
the document.

I suggest following up on the cultural change on another list if you 
believe it is worth pursuing.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Sun, 22 Jan 2012 21:38:55 -0500

> So let me talk a bit about direct engagement. It's not the standard thing
for
> the IESG now, but you're going to see more of it soon. During the last WG
> chair lunch, we had a discussion about copying all ballot DISCUSSes and
> COMMENTs to the WG mailing list and I think this is exactly the right
thing to do.
> My plan is to, on a case by case basis at first, add the WG list to the
magic field
> in the datatracker to which such comments go. The only issue is that this
has to
> be reasonably managed.

Let me, as a WG chair, urge you NOT to do it that way, but to let the
chairs handle the decision of what needs to go to active WG discussion and
when.  By all means, chat with your chairs and tell us what you expect.
 But let us manage the WG discussions.  If a chair isn't being open enough
for you, have further discussion.  You always have the option of forcing
the issue by doing what you suggest above if the chairs don't handle it as
you'd like.

The majority of the non-DISCUSS comments are dealt with by such minor
editorial changes that opening the discussion up to WG comments will likely
inundate the entire IESG unnecessarily (consider, say 5 comments each on 20
documents in one week, and a few vocal and unstoppable WG participants for
each).  Perhaps every approved doc should go back to its WG for a week for
validation, to be sure they see the final edits AND the RFC Editor notes
that the AD put there -- you do want those openly discussed by the WG, too,
right?

Even many DISCUSS comments are resolved with what will clearly be
non-controversial edits, which should well be reviewed by the WG, but which
don't need to have the WG engaged in the discussion.  The doc shepherd
needs to have the responsibility of taking it to the WG as appropriate.

In this case, in fact, Murray did bring the discussion to the WG, without
your needing to force it.  Whatever we think of how the discussion went,
not having it in front of the WG when it should have been was NOT one of
the problems.

> So, with all that said, I'm happy to get Stephen directly engaged on this
particular
> topic, though I think we now have a pretty good handle on what the issue
is and
> how to deal with it. I'll leave it to the chairs to tell me what level of
involvement
> they think is good at this point.

I don't think any involvement by Stephen is needed at this point: he's
already confirmed that he's happy with this version and will clear his
DISCUSS.  And, so everyone knows, Stephen was engaged and responsive with
the authors and chairs, as we discussed options.  The issue is that he
wasn't engaged with the WG when the chairs brought the discussion here.
 That's likely in part because we didn't CC him when we did that -- I have
no reason to think that he'd have avoided it if we'd asked him to be here.

Barry, chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 22 Jan 2012 21:13:38 -0800

One more perspective to throw into the mix...

I found this DISCUSS experience frustrating for two reasons:

1) My own interpretation of the way our options were presented was: "You can either (a) change to HMAC, or (b) stick with your way but explain why it's appropriate (and, quite honestly, we're going to set the bar on (b) very, very high, so you may as well just do HMAC)."

2) Related to the above, I thought we /had/ done an appropriate job of explaining why H was enough for our purposes in this application, especially after the Gen-ART review, but the IESG position didn't change; Stephen didn't answer me more than once, and any other IESG reply I got showed that our point wasn't being heard.  I never understood why; maybe I wasn't making it well, or maybe my facts are wrong.  Either way, at times it felt like there wasn't an "enough" that could be reached, which is obviously exasperating.

Eventually Barry said something on the list that led me to the proposed compromise, which brings us to text that the DISCUSS holder has accepted and I'll be posting soon.  I'm comfortable with it inasmuch as we can get this overwith and it doesn't make existing implementations obsolete, but I think the lack of specific implementation guidance might weaken it somewhat.  But I'm not interested in reopening that now.

In terms of what I've learned from this experience, I'm willing to admit that a better vetting of the algorithm earlier on would've helped our cause; either we would've switched to something more defensible or been able to present a decent defense from a technology standpoint (e.g., "we know about these attacks, you should too, but really we're fine with it and here's why").  Lesson learned for next time.

-MSK

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Mon, 23 Jan 2012 08:09:25 -0500

In
<CALaySJ+J1whbpmWZ4NCZoun2i2JAsGn=[email-masked]>,
on 01/22/2012
   at 09:38 PM, Barry Leiba <[email-masked]> said:

>non-controversial edits,

A procedural question: is it necessary for multiple WG members to
respond with "+1" to avoid an assumption of lack of interest? I tend
to post only in response to drafts that I consider problematical or to
issues that others have raised.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 23 Jan 2012 08:44:04 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shmuel Metz
> Sent: Monday, January 23, 2012 5:09 AM
> To: [email-masked]
> respond with "+1" to avoid an assumption of lack of interest? I tend to
> post only in response to drafts that I consider problematical or to

The IETF likes to see a record of consensus and support for decisions it makes, including publication of documents.  A "+1" is better than nothing, but ideal would be "I've read this, I agree with what it says, and I believe it should go forward to publication" or words to that effect.

Absent that, the statement of consensus or support for a document is far weaker, and someone would be within his/her rights to claim there's no indication of support justifying publication.

In short, silent reviewers don't help anyone.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 Jan 2012 08:54:54 -0800

On 1/22/2012 6:38 PM, Barry Leiba wrote:
>  >    During the last WG
>  > COMMENTs to the WG mailing list and I think this is exactly the right thing
> to do.

So do I.

> Let me, as a WG chair, urge you NOT to do it that way, but to let the chairs
> handle the decision of what needs to go to active WG discussion and when.

This is the IETF model of roughly two decades.

It has a basic flaw:

      The premise of the open IETF processes is that open collaboration means 
broad-based review, diverse perspectives and broad-based support for whatever is 
decided.

      Closed processes make it more likely that there will be narrower 
perspectives -- and therefore some aspect of the issue missed -- and less 
support. It actually makes an AD less accountable for their Discuss.  It 
certainly puts more of a burden on working groups to guess at what the AD wants 
and guess at what will resolve matters.

Working group discussion and other reviews are open and collaborative.  All of 
the details, major and minor, for handling concerns is public and on the wg 
mailing list.  Working groups already have the challenge of dealing with trivia, 
irritations, and basic disagreements.  Why should the direct, specific 
objections of an AD be kept out of that forum?  Or rather, why shouldn't the 
person lodging them be automatically required to take them directly to the 
working group? Why should ADs be immune from the requirement to take their 
concerns to the chartered forum that is established for conducting exactly such 
discussions?

Further, AD Discusses are now publicly documented.  So the step you are 
objecting to is a matter of convenience, not availability.  And it streamlines 
the resolution process by eliminating the information gatekeeping by whoever is 
mediating between the AD and the working group:  It puts the AD directly in 
front of the folks whose work is being challenged.

The current model is that an AD lodges the Discuss but the direct reporting of 
the fact and the explanation is left to be mediated by a chair or author.  There 
are cliches about the effects of having someone in the middle, trying to 
interpret things.

> By
> all means, chat with your chairs and tell us what you expect.  But let us manage
> the WG discussions.

What you are calling for is not "managing wg discussion".  It is gatekeeping the 
resolution process with the AD.  That's an entirely different and far less 
healthy matter.

> The majority of the non-DISCUSS comments are dealt with by such minor editorial
> changes that opening the discussion up to WG comments will likely inundate the
> entire IESG unnecessarily

"The entire IESG"?  I don't understand how this suddenly puts the entire IESG 
into the main flow of interaction between the AD who is blocking things and the 
wg that is being blocked.

In any event, a Discuss is expensive for the wg.  Why shouldn't it be expensive 
for the ADs lodging them?

> don't need to have the WG engaged in the discussion.

This is a classic error in logic:  The current mechanism often works adequately, 
so let's ignore the times it doesn't and let's ignore its inefficiencies an 
inequities.

My core point is that the /design/ of the current process is inherently flawed: 
  it violates the IETF's model for handling objections that pervades every other 
aspect of IETF work.

> In this case, in fact, Murray did bring the discussion to the WG, without your
> needing to force it.

This places an undue burden on chairs and/or authors.

Put the onus on the AD:  lodge a Discuss and you will be directly accountable to 
/all/ of the people whose work you are blocking.  You will then be required to 
explain and negotiate directly.

ADs are smart folk.  They often have extremely important and valid concerns. 
They often see a problem that really does need addressing.  Make them pursue it 
in the forum where all other such matters get pursued:  the working group.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 Jan 2012 08:58:54 -0800

So do I.

It has a basic flaw:

d/

-- 

   Dave Crocker

---

From: Pete Resnick <[email-masked]>
Date: Mon, 23 Jan 2012 11:35:17 -0600

This is probably something to be moved to a different list; I've at 
least changed the subject, since we're now on the general topic and not 
something specific to this WG. I'll ask for the chairs guidance, and if 
they want this moved off somewhere else we can do so.

On 1/23/12 10:54 AM, Dave CROCKER wrote:
>> chairs

As I said, this is a different thing than what we have been doing and I 
will not be doing so without first consulting with chairs and making 
sure they can and will manage the discussion reasonably. I'm not going 
to be springing this on anyone. But I do think that this needs to be 
done in the long run and, with proper preparation, I think it can be 
done reasonably.

>      The premise of the open IETF processes is that open collaboration 
> means broad-based review, diverse perspectives and broad-based support 
> for whatever is decided.
>
> perspectives -- and therefore some aspect of the issue missed -- and 
> less support. It actually makes an AD less accountable for their 
> Discuss.  It certainly puts more of a burden on working groups to 
> guess at what the AD wants and guess at what will resolve matters.

Right. One alternate means for doing this is moderating discussion. We 
are generally loathe to do moderated mailing list postings in the IETF 
unless things have gotten entirely out of hand in a WG, but we do allow 
it. If in particular instances chairs feel that a WG would be ill-served 
by a DISCUSS thread on the WG mailing list, moderation of the WG list 
(or a separate list specifically for the DISCUSS) could be put in place. 
That would leave things somewhat open. But I don't think this is ideal.

Remember, this is a change in behavior for all of us, so we do have to 
make these kinds of changes with open eyes.

> Further, AD Discusses are now publicly documented.

Right. But the additional worry I have is that responses to it are *not* 
publicly documented (i.e., when chairs or editors reply to the AD for 
clarifications, potential resolutions, etc.) unless the AD takes the 
additional step to update their comments in the tracker. That certainly 
needs to change. So, even if it is a moderated discussion, we need to do 
something different to document that discussion.

> So the step you are objecting to is a matter of convenience, not 
> availability.  And it streamlines the resolution process by 
> eliminating the information gatekeeping by whoever is mediating 
> between the AD and the working group:  It puts the AD directly in 

This is dependent on the AD *and* the WG involved. An AD might bring up 
an issue that was clearly resolved by a WG many months (years!) ago. 
Without a bit of restraint by the WG, a lot of sturm und drong can be 
generated if folks don't just wait for the chair or cognizant AD to 
explain, "We are aware of that issue, discussed it at length in the WG, 
and resolved it in this way for the following reasons." (This, BTW, can 
happen whenever anyone outside the WG comes in to participate without 
the history, but AD DISCUSS ballots generate a lot more sturm und drong 
because of how late they happen in the process and how solidly they can 
knot things up.) So it's a bit more than convenience. It's sometimes 
manageability of the WG process. But it's not something that can't be 
handled.

>> editorial
> "The entire IESG"?  I don't understand how this suddenly puts the 
> entire IESG into the main flow of interaction between the AD who is 
> blocking things and the wg that is being blocked.

Because the current model is that all replies to the DISCUSS messages 
are Cc'ed directly to the IESG list. And the IESG often does engage in 
that DISCUSSion. So when we embark upon this model, we're going to have 
to adjust several things that we're doing to keep everyone sane. Again, 
it can all be handled, but we have to be clear with everyone how it goes.

> In any event, a Discuss is expensive for the wg.  Why shouldn't it be 
> expensive for the ADs lodging them?

Indeed, and it's expensive for the IESG as a whole. However, while 
simply increasing the expense for everyone is one approach, it's 
probably not ideal.

Again, I think having all AD comments (DISCUSS or COMMENT) go to the WG 
list is the preferred outcome, but it is a cultural change. I want to do 
it carefully and deliberately.

pr

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 23 Jan 2012 11:29:40 -0800

On 1/23/2012 9:35 AM, Pete Resnick wrote:
> This is probably something to be moved to a different list;

glad to pursue it elsewhere, but felt that a direct response to this wg's chair 
was appropriate (too).

> As I said, this is a different thing than what we have been doing and I will not
> be doing so without first consulting with chairs and making sure they can and
> will manage the discussion reasonably.

As opposed to having chairs who won't?

That is, while the tone of what you say sounds entirely reasonable, I suspect 
it's predicate actually isn't.

Or rather, if there is claimed to be an inability to have reasonable list 
discussion, there's a much, much deeper problem.  The problem will need 
attention, but it isn't really a justification for treating Discusses as 
different from other input to the wg.

> Right. One alternate means for doing this is moderating discussion. We are
> generally loathe to do moderated mailing list postings in the IETF unless things

I believe IETF working groups are never moderated generically.  That is, I 
believe they never assert control over /all/ messages before being circulated. 
Some /individuals/ have messages moderated, but not all messages from everyone, 
to the group.

As a consequence, this tool in the arsenal again sounds superficially reasonable 
but probably isn't.

The overriding problem with the model, here, is the assumption that the working 
group needs to be protected in this specific situation.  What's missing is 
either the track record or the theory to justify this, other than extremely 
broad, vague and unfounded fears, I believe.

> Remember, this is a change in behavior for all of us, so we do have to make
> these kinds of changes with open eyes.

Transitions need tailoring, yes, but let's be clear about the difference between 
the transition issues versus to steady-state, long-term issues.

> clarifications, potential resolutions, etc.) unless the AD takes the additional
> step to update their comments in the tracker.

Isn't it nice how conveniently all of this gets fixed by simply moving the 
process to the working group mailing list?

>> So the step you are objecting to is a matter of convenience, not availability.
>> And it streamlines the resolution process by eliminating the information
>> gatekeeping by whoever is mediating between the AD and the working group: It
>> puts the AD directly in front of the folks whose work is being challenged.
>
> This is dependent on the AD *and* the WG involved. An AD might bring up an issue
> that was clearly resolved by a WG many months (years!) ago. Without a bit of
> restraint by the WG, a lot of sturm und drong can be generated if folks don't

In other words, unlike for anyone else who re-raises old, settled issues, we 
need to be especially protective of ADs?

Again, the nature of the issue, here, isn't new.  Old material being re-raised 
happens in wgs all the time.

All that's different for a Discuss is giving an AD the authority to block things 
and then also believing the AD needs to be privileged out of directly 
interacting with the wg about it.

The fear that the wg might get upset should not be a fear.  It's a certainty 
that it will happen... sometimes.

My response is:  yes, that's part of the cost of having an AD fail to do due 
diligence before blocking a working group.  Everyone else who re-raises old 
stuff suffers that cost, why shouldn't ADs?  (If an AD wants to get educated 
properly before lodging a Discuss, they should do that offline.)

> just wait for the chair or cognizant AD to explain, "We are aware of that issue,
> discussed it at length in the WG, and resolved it in this way for the following
> reasons."

And indeed, that's quite reasonable.  But again, it's reasonable /all/ the time, 
not just for ADs.

> (This, BTW, can happen whenever anyone outside the WG comes in to
> participate without the history, but AD DISCUSS ballots generate a lot more
> sturm und drong because of how late they happen in the process and how solidly
> they can knot things up.)

Why should ADs be protected from it?

> So it's a bit more than convenience. It's sometimes
> manageability of the WG process. But it's not something that can't be handled.

Your premise is that the sturm und drang makes the wg unmanageable.  I'll claim 
that it makes for a more honest process because it makes more clear to the AD 
that they have overstepped, if they have.  Or it makes more clear that the wg 
has/had a broken process.  Either way, it's a more complete and accurate process.

>> into the main flow of interaction between the AD who is blocking things and
>> the wg that is being blocked.
>
> Because the current model is that all replies to the DISCUSS messages are Cc'ed
> directly to the IESG list.And the IESG often does engage in that DISCUSSion.

Oh.  Well, yeah, that probably needs to change, in some way, since yes the 
traffic volume on the topic is certain to be higher.

Since it certainly seems like a good idea to make it easy for the rest of the 
IESG to be able to observe the process, while also being good to separate the 
traffic, I will suggest [email-masked][1] or somesuch as a 
separate iesg list to which such traffic is sent, in addition to the wg mailing 
list.

That permits iesg fold to separate the traffic and handle it distinctly.

> Indeed, and it's expensive for the IESG as a whole. However, while simply
> increasing the expense for everyone is one approach, it's probably not ideal.

I'm not suggesting it as a goal.  But the current model inherently imposes a 
large burden on the wg and relatively little on the person creating the block.

Moving the primary venue to be the wg makes the handling of a discuss the same 
as handling any other topic -- ADs do not get an exemption -- although the 
desire to keep the rest of the iesg in the loop does provide a special wrinkle 
(see above.)

> Again, I think having all AD comments (DISCUSS or COMMENT) go to the WG list is
> the preferred outcome, but it is a cultural change. I want to do it carefully
> and deliberately.

+1

d/

[1]  I'd have suggested iesg-discuss-discuss, but the IESG already uses the term 
"discuss-discuss" for something entirely different.

-- 

   Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Mon, 23 Jan 2012 15:57:05 -0500

On Mon, Jan 23, 2012 at 11:58 AM, Dave CROCKER <[email-masked]> wrote:
> broad-based review, diverse perspectives and broad-based support for> whatever is decided.

Which doesn't mean that every word is or needs to be written in
real-time on a public WIKI with everyone watching.  The editors
usually go off and make changes, and the working group reviews those
changes.  I'm suggesting nothing more nor less here.

> perspectives -- and therefore some aspect of the issue missed -- and less> support. It actually makes an AD less accountable for their Discuss.

I very much disagree with you.  What a side discussion does is allow
the editor(s) and the AD(s) to understand each other.  I have
similarly had side conversations with GenART reviewers, SecDir
reviewers, and other working group participants.  That those
discussions didn't happen on the mailing list didn't compromise the
process.  It allowed us to work out an understanding, and allowed me,
as editor, to propose some text, which the working group could review.

> Working group discussion and other reviews are open and collaborative.  All
> of the details, major and minor, for handling concerns is public and on the> wg mailing list.

And you NEVER, in any of your editing in, say, DKIM, went off and
discussed things off the list?  Every detail, major and minor, was on
the list at every moment of its development?

> directly to the working group? Why should ADs be immune from the requirement
> to take their concerns to the chartered forum that is established for> conducting exactly such discussions?

No one has said that an AD shouldn't participate in a working-group
discussion of the issues she brought up.  All I've said is that the
chairs, not the ADs, should manage the working group, its process, and
its discussions.

I've had quite a few DISCUSS comments on my documents, which (the
comments) were resolved with one or two email messages, sometimes with
no text changes at all (there was something the AD didn't understand).
 While I have no *objection* to the DISCUSS being posted to the
mailing list, as a management point I see no reason to remove the
judgment from the chairs' hands of how to handle the conversation.

> objecting to is a matter of convenience, not availability.

Exactly.  Nothing hidden at all.

> streamlines the resolution process by eliminating the information
> gatekeeping by whoever is mediating between the AD and the working group:

Nothing is "streamlined" when a minor clarification turns into
(perhaps) a large number of messages from the working group copied to
the entire IESG.

>  It puts the AD directly in front of the folks whose work is being> challenged.

Ah, here we get to a key point: the assumption that a DISCUSS is
adversarial.  A DISCUSS does block progress of a document, but it's
often NOT a "challenge".  It's often simply a request to, well,
discuss something briefly.  It's also often an administrative
mechanism -- as Pete said, a way of tracking something that needs to
happen before the document goes to the RFC Editor.  The working group
can see them any time it wants to look; not all of them need to be
explicitly brought to the WG for discussion.

> "The entire IESG"?  I don't understand how this suddenly puts the entire
> IESG into the main flow of interaction between the AD who is blocking things> and the wg that is being blocked.

Pete has answered this: the messages we're talking about are copied to
the IESG mailing list.  When the WG participants respond, they can
remove that CC.  We can all guess how often that will happen.

> This is a classic error in logic:  The current mechanism often works
> adequately, so let's ignore the times it doesn't and let's ignore its> inefficiencies an inequities.
Did I ever say anything about ignoring anything?  I don't recall that.
 In fact, I said that when in the chair's judgment the discussion
should go to (or at least be copied to) the WG, the chair can and
should take it there.  We've "hired" the chairs as managers, and they
should be left to manage.

> My core point is that the /design/ of the current process is inherently
> flawed:  it violates the IETF's model for handling objections that pervades> every other aspect of IETF work.
There's no question that the DISCUSS process is flawed.
The question is whether automatically copying every DISCUSS and
COMMENT to the WG mailing list is the (or "a") right way to fix it.  I
think it's not.

>> your needing to force it.>

It's an "undue burden" on the chairs to manage their working groups?
I can't agree.

On Mon, Jan 23, 2012 at 12:35 PM, Pete Resnick <[email-masked]> wrote:
> I'll ask for the chairs guidance, and if they want this
> moved off somewhere else we can do so.

I'm happy to continue this discussion here.
I'm also happy if Pete or Dave wants to take it to a more open place,
such as [email-masked].  Or, perhaps before that, to [email-masked].

> generally loathe to do moderated mailing list postings in the IETF unless
> things have gotten entirely out of hand in a WG, but we do allow it.

When I talk about the chairs moderating the discussion in this sense,
I do NOT mean using a moderation queue in the list software.  I'm
talking about management.  This, of course, relies on the WG
participants' cooperation, and banning them for being uncooperative is
rather extreme.

> something different to document that discussion.

This is a key point, which we should deal with in some way.  I don't
think that putting all of the discussions on the WG mailing list is
the right way to handle it.  Perhaps having them copied to a
discussion archive is the right answer.

> This is dependent on the AD *and* the WG involved. An AD might bring up an
> issue that was clearly resolved by a WG many months (years!) ago. Without a
> bit of restraint by the WG, a lot of sturm und drong can be generated

Exactly one example.

Scenario 1:
DISCUSS message goes to editors and chairs.  AD brings up issue X.
Editor or shepherd replies, "WG discussed this at length, and closed the issue."
AD says, "Ah, OK, thanks," and clears.

Scenario 2:
DISCUSS message goes to WG mailing list.  AD brings up issue X.
Five angry WG participants, sick to death of issue X, send angry
responses, which go to the IESG.
Two holdouts, who had prolonged the discussion endlessly before, take
this as an invitation to rant about issue X again, sending it to the
WG and the IESG.
AD gets the message and clears, but lots of time was wasted.

Scenario 3:
DISCUSS message goes to editors and chairs.  AD brings up issue X.
Editor or shepherd replies, "WG discussed this at length, and closed the issue."
AD says, "No, I don't think that's the right answer, and I won't clear."
Shepherd posts the discussion to the WG mailing list.

I'm sure you can see that I think scenarios 1 and 3 are the way things
should work, and 2 is the one I want to avoid.  The chairs are the
ones most able to judge what will happen, and when it should be posted
to the WG list.

Barry

---

From: Pete Resnick <[email-masked]>
Date: Mon, 23 Jan 2012 15:37:17 -0600

Skipping down to the end:

On 1/23/12 2:57 PM, Barry Leiba wrote:
>> This is dependent on the AD*and*  the WG involved. An AD might bring up an

My contention is that with proper socialization of the WG, scenario 2 
becomes, for all intents and purposes, scenario 1 or 3. That is, if the 
WG is restrained and managed well enough not to jump out of their skin 
when an AD posts a DISCUSS (or, for that matter, when a 
non-usual-WG-participant posts a message about a topic that his been 
decided), the post can go to the list, the chair or editor can say, "We 
discussed this at length, and closed the issue", the AD can respond in 
whichever way, and the discussion can continue as necessary. The bonus 
to scenario 2 + socialization is (a) there is an obvious archive where 
the discussion has taken place, and (b) the WG gets to see the comments 
and, if the chair or editor misunderstand the issue, another calm 
participant can pipe up, "Oh, that smart AD has said something 
especially insightful that we missed some months ago. I now see that I 
agree that we haven't solved this problem."

And this is why I said I will not be springing this on anybody. We'll do 
it with a WG and chair that is prepared so we don't get five angry 
participants who are sick to death instantly committing public ritual 
suicide on the list. And as Dave said, such restraint should be going on 
with anyone who re-raises an old issue (chairs should take the lead on 
such folks, ADs or otherwise, and explain history, and others should be 
patient until that happens), and as Dave also said, we should expect 
that sometimes humans will be humans and a participant will get publicly 
obnoxious (toward an AD or other person) and we'll deal with that 
accordingly.

The end goal is for ADs to be able post all of their comments to the WG 
list and for issues to get resolved appropriately without unwarranted 
fanfare.

pr

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 24 Jan 2012 08:20:24 -0800

On 1/23/2012 12:57 PM, Barry Leiba wrote:
>The editors

Actually, you are.  You are suggesting that the negotiation between the AD and 
the wg chair/authors take place in private, only consulting the wg at the end.

That's certainly the typical current mode for handling a Dicuss, but it is 
consistently a problem.

The model you are endorsing treats the wg as a passive, post hoc reviewer. 
That's not the official view of the role of a wg in the IETF...

> the editor(s) and the AD(s) to understand each other.

It perhaps allows that, but that means that the wg does not gain the same 
understanding nor at the same time.  It treats the authors and chairs as 
privileged to more information than the wg.

The Discuss is with a wg product, not an author product.

(FWIW I'll proffer my own theory that ADs who provide vague, incomplete or 
excessively narrow Discuss text or who prove to be unresponsive will tend to 
improve significantly, when they experience the broad and immediate feedback 
from a working group, rather than continuing to be permitted to conduct their 
Discuss activity out of the sunlight of that forum.)

> I have

Side discussions are fine, but that's not really what you are promoting.  You 
are promoting a parental process in which wg management filters the primary 
exchange with the AD.

Once again, why is it reasonable to have a different process for resolving 
issues with ADs than for anyone else posting comments and challenges to the wg?

> the list at every moment of its development?

Another error in logic both in form and extent.   There is a difference between 
side -- that is, adjunct -- conversations that are sometimes held, versus 
formal, primary exchanges that are always conducted.  (Your casting it in terms 
over 'every detail' moves towards hyperbole, which isn't helpful.)

The current model is that the formal clarification and negotiation takes place 
in private.  And, no, that's not the way wg work is done.

That some side, private discussions might and do take place is fine here, as for 
all other situations, but not as the norm and not as the primary vehicle for 
resolving things.  THAT is a major difference from the way the rest of wg 
business is conducted.

> chairs, not the ADs, should manage the working group, its process, and

Requiring the AD with the Discuss to interact with the wg does not hand over 
management of the wg to them.  Management by the chairs would remain unchanged.

> no text changes at all (there was something the AD didn't understand).

So?

> judgment from the chairs' hands of how to handle the conversation.

The current reality of standard working group process is that chairs do not have 
active control over the conduct of other wg interactions.  Their "judgement" is 
relevant at a higher level than the gatekeeping of particular participants, 
absent misbehavior.

Why does the interaction with an AD need to be different?

> Exactly.  Nothing hidden at all.

Practically speaking, that's not true.  First, the documentation is in a 
separate venue that is not typically visited and second because the interaction 
with the AD is offlist. Second, the negotiations are hidden.

> (perhaps) a large number of messages from the working group copied to

You are repeating the logic error:  Some situations /might/ cause some problems; 
so use this as an excuse for ignoring the larger problems that generally /do/ occur.

The meta-error is to look at one kind of problem, ignore its frequency or scale, 
but use its (occasional) existence as a basis for denying the import of other 
problems.  That error is common in IETF debate.

> adversarial.

A Discuss is an exercise of power.  It blocks the progress of the document.  It 
is one person -- typically someone with no history of the wg activity -- telling 
a small community that their work is not yet adequate.  It is an AD saying NO 
(for now).

One can be constructive or not, friendly or not, but that is inherently an 
adversarial process.  It frequently produces the real and frequent wg tendency 
to want to appease the AD rather than worry about what makes for the best document.

That some ADs are highly judicious and constructive about Discusses is fine, but 
it ignores that others are not.  And nothing I'm proposing requires any 
discomfort in the process.  It merely requires full sunlight.

>  A DISCUSS does block progress of a document, but it's
> often NOT a "challenge".

It is exactly and completely a challenge.  By formal definition, a Discuss is a 
challenge.

>  It's often simply a request to, well,
> discuss something briefly.

It is not a 'request".  It is a demand.  One with teeth.

> Did I ever say anything about ignoring anything?

Yes.  You are using the /possibility/ of some sturm und drang as an excuse for 
the /guarantee/ that wg participants are filtered out of direct involvement in 
dealing with a Discuss.

>   In fact, I said that when in the chair's judgment the discussion

Barry, you keep ignoring the core point I keep making:

      The chair does not do that kind of prior restraint for any other part of 
wg process.

      Why is it reasonable for the chair to exert parental control over wg 
content for this part?

> There's no question that the DISCUSS process is flawed.

Really?  I haven't seen anything in your postings that suggests that's your 
view.  In any event, you've phrased that as a very broad point about Discusses 
and the one I've been pressing is quite narrow.

> It's an "undue burden" on the chairs to manage their working groups?

Would it be reasonable to require all participants to be required to first get 
permission from the chairs or authors before bringing an issue to the list?

Why is it then reasonable to impose that gatekeeping for this particular 
situation with ADs?

d/

-- 

   Dave Crocker