netsec-reqs document: what is, where it is, what to call it.

[gmj@pobox.com]

After some off-list discussion, I think it's time for on-list,
on-the-record discussions WRT what the netsec-reqs/opsec document
is, why it's here, and what to call it.

What is is:
  - A list of capabilities and security related features that
    UUNET wanted/?wants? vendors to support. 
  - A document given to vendors to tell them what UUNET wanted.
  - A starting point for lab/compliance testing.
  - It contains many things that are implemented in current
    devices, and some things that are not. 
   
    For example, while we require a consistent, scriptable config interface
    many today provide only GUI interfaces, snmp appears to
    empirically to be unacceptable to most operators for configuration
    for whatever reason (it's not getting used), and the netconf/xmlconf
    BOF/WG is still trying to get off the ground....but we still have
    a requirement for a consistent, scriptable config interface.

    See http://www.port111.com/opsec/latest/ for a start at breaking
    down the "current" features from the "non-current" features...

What it is not.
  - A list of configuration guidelines.

Why it's being published?
  - To enable the larger community of consumers/operators of
    IP enabled equipment to communicate security needs
    clearly and effectively (read: via references in RFPs)
    to the vendor community....i.e. the end game is better,
    more secure products.

Why IETF?
  - Because (in theory) a document published via IETF will:
    * Result more widespread adoption/use
    * It will provide a forum in which it can be vetted
      to make sure it's solid.
    * There is a good deal of closely related work happening
      in other areas of the IETF...being involved/aware
      of them will prevent us from having to reinvent
      imperfect wheels, and may allow us to have influence
      on that work.
    * Because it's believed that we can get it out relatively
      quickly as some sort of individual submission.

What to call it (what's in a name ?)
    * So, the current question is, what to call it, given 
      the goals above and assuming that the assumptions
      in the "Why IETF?" paragraph above are true?

      Best Current Practice (BCP) doesn't seem right
      because some of the things being asked for
      are not "current" in most/any vendors implementation
      and it's not "practice" in the sense of configuring.

      So, the question is, what sort of document, in IETF
      terms is appropriate and will let us meet the goals
      listed above?

Why this matters?

      We have comments to integrate now.  We need to know
      what sort of document is being produced to 
      integrate them properly.

Thanks,
---George