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

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

Bill,

I'm working through the drafts a couple at a time.

My comments on the first couple drafts are below.

--Brent

> here's my take.  Anyone disagree with the categorization?
> 
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-01.txt:
> 
> All references are normative.  (FIPS-46-3 in this context is a
> "historic normative")

I Agree. 

> 
> http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-13.txt
> 
> Non-normative:
> RFC854 (telnet)
> RFC894 (IP over Ethernet)
> RFC1134 (PPP)
> RFC1232 (rlogin)
> (the above are refereced as part of an analsis of
> relative protocol overhead.)
> 
> All others are normative; note that I think RFC1766 has been
> superceded.
> 
> nits: references from text are [RFC-NNN]; references section
> has [RFCNNN].

Agree. With some possible exceptions:

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

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.

---

nit: SSH-ARCH refers to [RFC-2343] in the body, but I believe is
                         ^^^^^^^^^
supposed to be RFC2434.

I'll look over the remaining drafts soon.

thanks, Brent
bdm%vandyke.com@localhost