RE: [NSIS] RE: normative/informative references

[[e-mail]]

Hi all,

If I were to split the references, I would do it as follows. This is a suggestion,
your milage may vary.  (note - the two normative documents are documents
that I think are needed to understand why certain decisions have been
made in the framework).

John

Normative

   2  Brunner, M., "Requirements for Signaling Protocols", draft-ietf-
      nsis-req-09.txt (work in progress), August 2003 
    
   7  Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp-
      sec-properties-02.txt (work in progress), June 2003 
    

Non-Normative


   1  Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource 
      ReSerVation Protocol (RSVP) -- Version 1 Functional 
      Specification", RFC 2205, September 1997 
    
   3  Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", 
      draft-ietf-nsis-threats-02.txt (work in progress), June 2003 
    
   4  Chaskar, H. (editor), " Requirements of a Quality of Service (QoS) 
      Solution for Mobile IP", RFC 3583, September 2003 
    
   5  Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox 
      Communications (midcom) Protocol Requirements", RFC 3304, August 
      2002 
    
   6  Manner, J., X. Fu, P. Pan, "Analysis of Existing Quality of 
      Service Signaling Protocols", draft-ietf-nsis-signalling-analysis-
      02.txt (work in progress), June 2003 
    
   8  Katz, D., "IP Router Alert Option", RFC2113, February 1997 
    
   9  Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, 
      October 1999 
    
   10 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of 
      RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001 
               
   11 Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on 
      Security Considerations", RFC 3552, July 2003 
    
   12 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne, 
      "NSIS Authentication, Authorization and Accounting Issues", draft-
      tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003 
    
   13 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini, 
      "RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001 
    
   14 Ji, P., Z. Ge, J. Kurose, D. Townsley, "A Comparison of Hard-State 
      and Soft-State Signaling Protocols", Computer Communication 
      Review, Volume 33, Number 4, October 2003 
    
   15 Floyd, S., "Congestion Control Principles", RFC 2914, September 
      2000 
    
   16 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda, 
      T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC 
      2676, August 1999 
    
   17 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt, 
      P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy 
      Protocol", RFC2338, April 1998 
    
   18 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ 
      Resource Management in IP-based Radio Access Networks", 
      Proceedings of 4th International Symposium on Wireless Personal 
      Multimedia Communications-WPMC'01, September 9 - 12, 2001 
    
   19 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y. 
      Khouaja, "Evaluation of Mobility and QoS Interaction", Computer 
      Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163 
    
   20 Johnson, D., C. Perkins, J. Arkko, "Mobility Support in IPv6", 
      draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003 
    
   21 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in 
      candidate access router discovery for seamless IP-level handoffs", 
      draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress), 
      October 2002 
    
   22 Kempf, J., "Problem Description: Reasons For Performing Context 
      Transfers Between Nodes in an IP Access Network", RFC3374, 
      September 2002 
    
   23 Srisuresh, P. and M. Holdrege, "IP Network Address Translator 
      (NAT) Terminology and Considerations", RFC2663, August 1999 
    
   24 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", 
      RFC2765, February 2000 
    
   25 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple 
      Traversal of User Datagram Protocol (UDP) Through Network Address 
      Translators (NATs)", RFC3489, March 2003 
   
   26 Terzis, A., J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation 
      Over IP Tunnels", RFC 2746, January 2000 
    
   27 Braden, R., D. Clark, S. Shenker, "Integrated Services in the 
      Internet Architecture: an Overview", RFC 1633, June 1994 
         
   28 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A., 
      Partain, D., Pop, O., Rexhepi, V., Szabo, R., Takacs, A., 
      "Resource Management in Diffserv (RMD): A Functionality and 
      Performance Behavior Overview", Seventh International Workshop on 
      Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002 
    
   29 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for 
      Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-
      072, November 1992 
    
   30 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated 
      Services Architecture for the Internet", RFC 2638, July 1999 
        
   31 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H. 
      Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and Framework", 
      draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003 
    
   32 Aoun, C., "NSIS Network Address Translator implications", draft-
      aoun-nsis-nat-imps-01.txt (work in progress), March 2003 

> -----Original Message-----
> From: ext Hancock, Robert [mailto:[e-mail]]
> Sent: 16 October, 2003 16:19
> To: Roland Bless
> Cc: [e-mail]
> Subject: [NSIS] RE: normative/informative references
> 
> 
> hi roland,
> 
> my view is that even the requirements doc is not normative - 
> you don't need to understand the requirements document to
> 'implement' the framework (whatever 'implement' means in this
> context). you might want to read the requirements document
> to understand why the framework addresses the problems it
> does (i.e. the requirements are informative).
> 
> in other words, my view is that the framework has no 
> normative references. but i'm waiting for w.g. chair guidance
> on that.
> 
> cheers,
> 
> r.
> 
> > -----Original Message-----
> > From: Roland Bless [mailto:[e-mail]]
> > Sent: Thursday, October 16, 2003 14:23
> > To: Hancock, Robert
> > Cc: [e-mail]
> > Subject: normative/informative references
> > 
> > 
> > Hi Robert,
> > 
> > On Mon, 13 Oct 2003 09:29:30 +0100 "Hancock, Robert" 
> > <[e-mail]> wrote:
> > 
> > > some people have asked whether they can still make last call
> > > comments on the mailing list on this draft. the answer is:
> > > yes (in which case I will enter them myself). the tracking
> > > tool is intended to be a convenience for the editor and anyone
> > > else trying to disentangle N parallel conversations, it's not
> > > intended to restrict the discussion in any way.
> > 
> > Mainly an editorial related comment.
> > 
> > The tracking tool lists as open issue:
> > ] Deferred from v3:
> > ]
> > ] References should be split normative and informative
> > ] (according to some criteria, presumably).
> > ]
> > ] We need to decide which in-progress WG documents to refer to
> > ] as background (e.g. midcom and qos NSLP drafts?)
> > 
> > I'd like at least to give a hint to the RFC editor's criteria below.
> > According to my perception of the distinction between normative and
> > informative references (from the definition below), there are 
> > nearly no 
> > normative references in the framework (except for the 
> > requirements doc).
> > 
> > Quoting from http://www.rfc-editor.org/policy.html#policy.refs:
> > Normative references specify documents that must be read to 
> understand
> > or implement the technology in the new RFC, or whose 
> > technology must be
> > present for the technology in the new RFC to work. An informative
> > reference is not normative; rather, it only provides additional
> > information. For example, an informative reference might provide
> > background or historical information. Informative references are not
> > required to implement the technology in the RFC.
> > 
> > Regards,
> >  Roland
> > 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis