RE: Compendium of "red flags"

[Black_David@emc.com]

> 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.

This is an opportunity for something qualitatively different from the
nits document.  The nits document is a list of MUSTs - if the draft
doesn't do <X>, the IESG will send it back until it does, period.

In contrast, a "red flags" document is an opportunity for SHOULDs:
  <X> is a known problem area that is often addressed poorly in
  ways <P>, <Q> and <R>.  Don't go there if it's not necessary,
  and pay specific attention to <P>, <Q>, and <R>.
This can be particularly useful when <X> is outside the main
technical focus area of the protocol.

Here's an example that I caught early enough before it
had a chance to cause real problems:

  Naming can be problematic when a new class of names has global
  or world-wide scope.  Creation of new classes of globally
  unique protocol-independent names is strongly discouraged;
  it is usually better to focus on the naming needs of the
  protocol at hand, ideally via an existing class of names.
  Global uniqueness of names is difficult and subtle to specify
  correctly, and expecting a new class of such names to be
  globally resolvable is usually unrealistic.

Some discussion of use vs. abuse of DNS could be added.
In my particular example, some timely discussion with an AD and
IAB member lead to a reasonable mid-course correction - the IPS WG
was basically doing the right technical thing, but it was necessary
to curb some overblown visions of broader applicability of a new
class of names.

Thanks,
--David

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: Sunday, March 09, 2003 7:17 PM
> To: Harald Tveit Alvestrand
> Cc: wgchairs@ietf.org
> Subject: Re: Compendium of "red flags"
> 
> 
> > is there a relationship between a collection of red flags 
> and RFC 3426 -
> > "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.
> 
> 
> 
> 
>