Subject: Re: [AAA-WG]: [Issue] Normative versus Informative references

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Jan 2002 11:01:37 +0200

> RFC Editor has indicated that future RFCs will need to separate Normative
> versus Informative references.

Well, here's my first cut at separating these in two classes.
(Where the base spec mandates some specific thing, and has
a reference, then I have considered it as a Normative reference.
If the reference is just used as a background for Diameter
requirements I've considered it as Informative.)

There's a few borderline cases. For instance, is the
NASREQ application Normative from the point of view of
the Base spec?

Interestingly, there's a few references I can't find any
use for...

Jari

BASE DRAFT REFERENCE CLASSIFICATION

Informative:
============

[1]  C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentica-
     tion Dial In User Service (RADIUS)", RFC 2865, June 2000.

[20] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC
     2477, January 1999.

[21] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access
     Server Protocols", RFC 3169, September 2001.

[22] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA",
     RFC 3141, June 2001.

[23] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho-
     rization, and Accounting Requirements". RFC 2977. October 2000.

[25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Pro-
     tocol (EAP)." RFC 2284, March 1998.

[40] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting Man-
     agement", RFC 2975, October 2000.

[42] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 51,
     July 1994.

[43] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming
     Implementations", RFC 2194, September 1997.

[44] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementation
     in Roaming", RFC 2607, June 1999.

[45] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October 1996.

Probable informative, not sure:
===============================

[7]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Appli-
     cation", draft-ietf-aaa-diameter-nasreq-08.txt, IETF work in
     progress, November 2001.

[10] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft-
     ietf-aaa-diameter-mobileip-08.txt, IETF work in progress, November
     2001.

[31] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
     ABNF", RFC 2234, November 1997.

Normative:
==========

[2]  Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994.

[3]  Postel, "User Datagram Protocol", RFC 768, August 1980.

[11] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security applica-
     tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in
     progress, November 2001.

[8]  Aboba, Beadles "The Network Access Identifier." RFC 2486.  January
     1999.

[12] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations
     Section in RFCs", BCP 26, RFC 2434, October 1998

[13] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
     els", BCP 14, RFC 2119, March 1997.

[15] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409,
     November 1998.

[41] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Payload Compres-
     sion Protocol (IPComp)", RFC 2393, December 1998.

[16] Hinden, Deering, "IP Version 6 Addressing Architecture", RFC 2373,
     July 1998.

[17] ISI, "Internet Protocol", RFC 791, September 1981.

[18] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4,
     IPv6 and OSI, RFC 2030, October 1996.

[24] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC
     2279, January 1998.

[26] R. Stewart et al., "Stream Control Transmission Protocol". RFC
     2960.  October 2000.

[27] Postel, J. "Transmission Control Protocol", RFC 793, January 1981.

[28] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Pro-
     tocol, Version 2", RFC 2165, June 1999.

[29] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform
     Resource Identifiers (URI): Generic Syntax". RFC 2396, August 1998.

[30] Institute of Electrical and Electronics Engineers, "IEEE Standard
     for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985,
     August 1985.

[32] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Service:
     Schemes", RFC 2609, June 1999.

[33] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the
     location of services (DNS SRV)", RFC 2782, February 2000.

[34] D. Eastlake, "Domain Name System Security Extensions", RFC 2535,
     March 1999.

[35] D. Eastlake, "DNS Security Operational Considerations", RFC 2541,
     March 1999.

[36] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s )",
     RFC 2931, September 2000.

[37] S. Kent, R. Atkinson, "Security Architecture for the Internet Pro-
     tocol", RFC 2401, November 1998.

[38] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, Jan-
     uary 1999.

[46] IANA, "RADIUS Types", http://www.isi.edu/in-notes/iana/assign-
     ments/radius-types

[47] IANA, "Number assignment", http://www.iana.org

[49] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Dif-
     ferentiated Services Field (DS Field) in the IPv4 and IPv6 Head-
     ers," RFC 2474, December 1998.

[50] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding
     PHB Group," RFC 2597, June 1999.

[51] V. Jacobson, K. Nichols, K. Poduri, "An Expedited Forwarding PHB",
     RFC 2598, June 1999.

[52] B. Aboba, J. Wood, "Authentication, Authorization and Accounting
     (AAA) Transport Profile", draft-ietf-aaa-transport-04.txt, IETF
     Work in Progress, June 2001.

Seem unnecessary (quick search didn't reveal references):
=========================================================

[4]  Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[5]  Kaufman, Perlman, Speciner, "Network Security: Private Communica-
     tions in a Public World", Prentice Hall, March 1995, ISBN
     0-13-061466-1.

[6]  Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message
     Authentication", RFC 2104, January 1997.

[14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key
     Infrastructure Online Certificate Status Protocol (OCSP)", RFC
     2560, June 1999.

[19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc-
     ture Certificate and CRL Profile", RFC 2459, January 1999.

[39] "The Communications of the ACM"  Vol.33, No.6 (June 1990), pp.
     677-680.

[48] P. V. Mockapetris, "Domain names - implementation and specifica-
     tion," RFC 1035, November 1987.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jan 2002 06:17:30 -0800 (PST)

Question: 

Why is the reference to SNTP [18] normative? Does Diameter require time
synchronization? If so, does it need *secure* time?

Similarly, why the normative reference to DNS TSIG [36] and other DNS
Security RFCs? 

In general, normative references relate to MAY, SHOULD, MUST, MUST NOT,
etc. clauses in the spec.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Jan 2002 16:56:59 +0200

> synchronization? If so, does it need *secure* time?

[S stands for Simple, not Secure.]

But the reason why I thought this should be normative was
that section 4.4, under "Time", describes that our Time Format
AVP values have some relationship to the format used in SNTP.

The text also indicates that there's an extension mechanism
described in the SNTP RFC that allows you to go beyond year
2036. Strangely, the text doesn't really say whether DIAMETER
nodes MUST/MAY/SHOULD support this mechanism.

I'm also not quite sure about the "some relationship" part,
we simply state "containing the four most significant octets
returned from NTP [18], in network byte order". This also
seems a bit strange definition. Perhaps we should say "MUST
contain a time value in the format defined in Section 3 of
[18]"?

> Similarly, why the normative reference to DNS TSIG [36] and other DNS

Section 5.2 states that "it is prudent to employ DNS Security
as a precaution". I'm pretty sure "it is prudent" is not a term
in RFC 2119... I'm less sure whether we should change it to a
MAY or or move the references to informative...

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jan 2002 07:11:43 -0800 (PST)

> AVP values have some relationship to the format used in SNTP.

OK.

> nodes MUST/MAY/SHOULD support this mechanism.

We should probably clarify this (can you open an issue?). We expect
Diameter to be around a while ;)

> contain a time value in the format defined in Section 3 of

Is the reference to NTP or SNTP? 

> in RFC 2119... 

In general, RFC 2119 terms should be upper case, to avoid confusion. So
"prudent" is not a normative term (e.g. not equivalent to SHOULD), and
such references would therefore not be normative.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Jan 2002 17:54:21 +0200

> Diameter to be around a while ;)

I'll do that. 

> Is the reference to NTP or SNTP?

Funny, the text says NTP and the reference is to SNTP... time
for an issue...

> such references would therefore not be normative.

OK, in that case we should simply put these things under the
informative section. Here's a revised reference classification.
However, we still need to work on the list: see for instance
section 5.2 where various things such as SRV records and SLPv2
are referenced. I'm not sure what the specs actually say about
these things. There's no MUST/MAY/SHOULDs anywhere, but a series
of "recommendations". Personally, I'd prefer making it very
explicit what is a mandatory requirement for DIAMETER and what
is not. For instance, the first item in the list in 5.2 is
propably a MUST item, while the others are MAY items?

Jari

Informative:
============

Normative:
==========

---

From: Jari Arkko <[email-masked]>
Date: Wed, 02 Jan 2002 18:18:38 +0200

Submitter: Jari Arkko <[email-masked]>
Date: January 2, 2002
Reference: 
Document: BASE-08
Comment type: T
Priority: S 
Section: 
Rationale/Explanation of issue: Unclear reference to SNTP

Current text reads as follows:

  The Time format is derived from the Unsigned32 AVP Base Format.
  This is 32 bit unsigned value containing the four most
  significant octets returned from NTP [18], in network byte
  order.

  This represent the number of seconds since 0h on 1 January 1900
  with respect to the Coordinated Universal Time (UTC).

  On 6h 28m 16s UTC, 7 February 2036 the time value will
  overflow.  NTP [18] describes a procedure to extend the time to
  2104.

This has two problems. First, it is unclear whether NTP or SNTP
is meant and what format is really used. Second, we don't
mandate the extension to year 2104.

Also, I find it easier to explain the format issue if Time
is derived from OctetString, not Unsigned32. Bits on the wire
are not changed.

Proposed change:

  The Time format is derived from the OctetString AVP Base
  Format. The string MUST contain four octets, in the same
  format as the four first bytes are in the NTP Timestamp
  Format. The NTP Timestamp format is defined in Chapter 3 of
  reference [18].

  This represents the number of seconds since 0h on 1 January 1900
  with respect to the Coordinated Universal Time (UTC).

  On 6h 28m 16s UTC, 7 February 2036 the time value will
  overflow.  SNTP [18] describes a procedure to extend the time to
  2104. This procedure MUST be used by all DIAMETER nodes.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jan 2002 08:31:12 -0800 (PST)

> There's no MUST/MAY/SHOULDs anywhere, but a series

Yes, I think that is a good idea. Otherwise, you could have some people
implementing one thing (SRV), others another thing (SLPv2) and problems in
interoperability. So this sounds like another issue.

---

From: Erik Guttman <[email-masked]>
Date: Wed, 2 Jan 2002 17:56:22 +0100 (MET)

> interoperability. So this sounds like another issue. 

It is more important for the information to be available
than for it to be used, from a requirements perspective.
Thus, if we RECOMMEND that SRV records are set up and
Diameter servers advertise themselves with SLPv2, there
is a good chance that Diameter clients can find servers
dynamically.  Whether they do so is a policy and technical
decision for the diameter client implementors.  

So I advocate:

  The location of Diamter servers SHOULD be made available
  through configuration of DNS SRV RRs and through Diameter
  servers advertising via SLPv2.  A Diameter client MUST
  support manual configuration, and MAY additionally support
  configuration of Diameter server location via either DNS SRV
  RR lookup or SLPv2.

Erik

---

From: "Jari Arkko" <[email-masked]>
Date: Wed, 2 Jan 2002 20:19:40 +0200

>   configuration of Diameter server location via either DNS SRV

Good point. Agreed.

Jari