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

["Brent McClure" <mcclure%swcp.com@localhost>]

----- Original Message ----- 
From: "Bill Sommerfeld" <sommerfeld%east.sun.com@localhost>
To: "Brent McClure" <mcclure%swcp.com@localhost>
Cc: <ietf-ssh%netbsd.org@localhost>
Sent: Thursday, January 16, 2003 5:28 PM
Subject: Re: still need review of normative vs. non-normative reference split. 


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

I guess "interoperable" was the perspective was taking. One could 
never have read 1750 and still write an interoperable implementation, 
so technically one might categorize it as informative. I didn't feel 
that doing this necessarily gives a green light to poor implementations.
Especially since the text of SSH-ARCH makes it clear how important
randomness is.

If making it normative helps emphasize it's importance, I'm happy
to see it stay that say.

--Brent