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

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 10 Jan 2003 18:47:19 -0500

Nobody got back to me from this request:

> Latest nit from the AD's on core documents: need to separate normative
> and non-normative references, per http://www.rfc-editor.org/policy.html
>
> I'd appreciate it if a couple people could play "spot the
> non-normative references" in the current drafts and share their
> results with me and/or the WG.  (I've done a quick look myself; the
> vast majority are normative).
>
> There will be a document re-spin after this exercise.
>
> Thank you for your assistance.

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

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].
		
http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-16.txt

	All normative

http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-15.txt

	Non-normative:
		[Orm96] (nit: typo in the reference)

	references rfc1766 (superceded)

	apparently unused:
		rfc2459 
		rfc1034

	there are references to Applied Cryptography for several
	algorithms.

http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-16.txt

	All normative.

---

From: Chris Newman <[email-masked]>
Date: Fri, 10 Jan 2003 17:00:44 -0800

begin quotation by Bill Sommerfeld on 2003/1/10 18:47 -0500:
> ...

Yes, use RFC 3066 instead of RFC 1766.

                - Chris

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 10 Jan 2003 20:09:24 -0500

> Yes, use RFC 3066 instead of RFC 1766.

Do you know if there are any significant over-the-wire differences
between 3066 and 1766 ?

---

From: Chris Newman <[email-masked]>
Date: Fri, 10 Jan 2003 17:14:41 -0800

> Do you know if there are any significant over-the-wire differences

RFC 3066 permits digits in subtags, while 1766 doesn't.  Otherwise the ABNF 
is unchanged.  So I'd say the answer to your question is "no".

                - Chris

---

From: "Brent McClure" <[email-masked]>
Date: Thu, 16 Jan 2003 15:09:32 -0700

Bill,

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

My comments on the first couple drafts are below.

--Brent

> All references are normative.  (FIPS-46-3 in this context is a

I Agree. 

> nits: references from text are [RFC-NNN]; references section

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 [email-masked] 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
[email-masked]

---

From: "Brent McClure" <[email-masked]>
Date: Thu, 16 Jan 2003 17:04:36 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-16.txt

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])

     ABRT
     ALRM
     FPE
     HUP
     ...

I read SSH-TRANS and SSH-USERAUTH and the only non-normative ref
I found was [Orm96] that you already identified.

thanks, Brent
[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 16 Jan 2003 19:28:45 -0500

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

> understood...", then it might be considered informative.

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

  ...

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

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 17 Jan 2003 10:12:46 -0500

On Thursday, Jan 16, 2003, at 17:09 America/Montreal, Brent McClure 
wrote:
> might be listed as informative.

It is normative.  An implementation that doesn't follow those
recommendations can't be secure.

> like it could be listed as informative rather than normative.

No.  It is normative because we are obliged to follow that RFC
in our IANA considerations.

Ran

---

From: "Brent McClure" <[email-masked]>
Date: Fri, 17 Jan 2003 09:56:26 -0700

----- Original Message ----- 
From: "Bill Sommerfeld" <[email-masked]>
To: "Brent McClure" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 16, 2003 5:28 PM
Subject: Re: still need review of normative vs. non-normative reference split. 

> 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