Re: still need review of normative vs. non-normative reference split.

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

[wg chair hat on..]

the normative/non-normative reference split is a new requirement which
started being imposed after the core documents were first submitted to
the IESG.  this is an evolving requirement and exactly how it's being
handled is still a bit fuzzy at the moment..

My understanding right now is that the current cited reason to not
mark a reference "normative" is to avoid publication delays when you
have non-normative references to unpublished internet-drafts.

Since all the references in the core drafts are either
within-the-hairball or to published documents, this is largely a
non-issue for us.

[wg chair hat off for the following.]

> I wonder if RFC-1750 (Randomness recommendations for security) might
> be listed as informative. Obviously randomness is something that is
> important for implementors to pay attention to, but it still seems
> like it might be considered "background" (or "very important
> background").

so, if we go by the "must read this in order to implement"
interpretation of normative, I think we're safer off declaring this as
normative.

> I guess what I'm basing this one could implement the protocol using
> a very poor stream of random data and it would still "work".

while such an implementation would interoperate, it would emphatically
not provide meaningful security.  

> Also, it seems like RFC2434 (IANA considerations in RFCS) seems 
> like it could be listed as informative rather than normative. 
> It is referred to as policy for allowing DNS domain owners 
> to introduce names like name%mydomain.org@localhost to secsh. Since it is
> referred to as policy rather than "technology that must be 
> understood...", then it might be considered informative.

On the other hand, it's normative for the process to follow when
implementing private extensions..

> I wonder if [POSIX] could really be categorized as informative.
> While POSIX was the source of the secsh list of signals, the fact
> that they came from there doesn't seem to require one to go
> read POSIX to implement. Here is the relevant text in SSH-CONN:

  ...
  The signal name is one of the following (these are from [POSIX])

so, my take is that you need to read [POSIX] to understand what a
"signal" is and how to map your local OS's equivalent into the
over-the-wire protocol message.

					- Bill