Subject: Compendium of "red flags"

From: Bernard Aboba <[email-masked]>
Date: Fri, 7 Mar 2003 06:31:51 -0800 (PST)

It has occurred to me that it might be useful to have a document
summarizing the most common technical problems encountered in drafts that
have passed WG last call.

These are things that if present in a draft tend to be "red flags" --
items that are often of questionable technical merit, and will tend to
draw scrutiny.

That doesn't mean that such items can never be included -- just that the
WG should be prepared to make a persuasive argument for them.

It might make sense to group the "red flags" by Area -- Transport,
Security, Routing, etc. so that we can make sure to have come up with a
"well rounded" set of issues.

Do people think that such a document would be valuable? How many "red
flags" might be reasonable to discuss in such a document? 10? 25?

---

From: avri <[email-masked]>
Date: Fri, 07 Mar 2003 12:14:19 -0500

It strikes me as yet another nit document.  And the relation
of red flags to sacred cows would be a problem.

I fear that this document once created would be yet another
barrier to getting a document through the process.  I think
it would also be a back door way of defining an architecture.
I.e. this is what we don't do ...

I personally would not be happy to see it.

a.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 09 Mar 2003 23:25:22 +0100

is there a relationship between a collection of red flags and RFC 3426 - 
"General Architectural and Policy Considerations"?

One advantage the id-nits document has is that it is far shorter than the 
average RFC...

                       Harald

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 9 Mar 2003 16:17:26 -0800 (PST)

> "General Architectural and Policy Considerations"?

Not much. RFC 3426 talks about "general architectural and policy
questions" -- issues involved in choosing an approach to a problem. But
what I have in mind is the collection of smaller scale items that
represent commonly acknowledged mistakes made in protocols designed
over the last 5 years -- basic nuts and bolts items.

Not only do we have difficulty stating the problem, and choosing the right
approach to the problem -- often the basic details of the design are not
correct either.

The goal is to come up with a relatively small set of items that have
proven to be issues with protocols designed over the last 5 years.