zilinlin/RFC2PSM huggingface dataset:
Section 5. Acknowledgments

The author thanks the many (and too numerous to mention!) members of
   the DHC WG for their tireless and ongoing efforts in the development
   of DHCP and this document.
   The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
   Mendonca in organizing DHCP interoperability testing sessions are
   gratefully acknowledged.
   The development of this document was supported in part by grants from
   the Corporation for National Research Initiatives (CNRI), Bucknell
   University and Sun Microsystems.
Section 6. References

[1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
       1983.
   [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
       Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
       University, October 1993.
   [3] Braden, R., Editor, "Requirements for Internet Hosts --
       Communication Layers", STD 3, RFC 1122, USC/Information Sciences
       Institute, October 1989.
   [4] Braden, R., Editor, "Requirements for Internet Hosts --
       Application and Support, STD 3, RFC 1123, USC/Information
       Sciences Institute, October 1989.
   [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
       (DRARP)", Work in Progress.
   [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
       Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
       Communications Review), 20(4):50--59, 1990.
   [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
       Stanford and SUN Microsystems, September 1985.
   [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
       PARC, September 1991.
   [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
       Bucknell University, October 1993.
   [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
   [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
        Mechanism for Distributed File Cache Consistency", In Proc. of
        the Twelfth ACM Symposium on Operating Systems Design, 1989.
   [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
   [13] Mockapetris, P., "Domain Names -- Implementation and
        Specification", STD 13, RFC 1035, USC/Information Sciences
        Institute, November 1987.
   [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
        November 1990.
   [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
        Hosts", Work in Progress.
   [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
        USC/Information Sciences Institute, September 1981.
   [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
        USC/Information Sciences Institute, August 1993.
   [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
        USC/Information Sciences Institute, October 1994.
   [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
        Assignment of IP Addresses for use on an Ethernet. (Available
        from the Athena Project, MIT), 1989.
   [20] Sollins, K., "The TFTP Protocol (Revision 2)",  RFC 783, NIC,
        June 1981.
   [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
Section 7. Security Considerations

DHCP is built directly on UDP and IP which are as yet inherently
   insecure.  Furthermore, DHCP is generally intended to make
   maintenance of remote and/or diskless hosts easier.  While perhaps
   not impossible, configuring such hosts with passwords or keys may be
   difficult and inconvenient.  Therefore, DHCP in its current form is
   quite insecure.
   Unauthorized DHCP servers may be easily set up.  Such servers can
   then send false and potentially disruptive information to clients
   such as incorrect or duplicate IP addresses, incorrect routing
   information (including spoof routers, etc.), incorrect domain
   nameserver addresses (such as spoof nameservers), and so on.
   Clearly, once this seed information is in place, an attacker can
   further compromise affected systems.
   Malicious DHCP clients could masquerade as legitimate clients and
   retrieve information intended for those legitimate clients.  Where
   dynamic allocation of resources is used, a malicious client could
   claim all resources for itself, thereby denying resources to
   legitimate clients.
Section A. Host Configuration Parameters

IP-layer_parameters,_per_host:_
   Be a router                     on/off                 HRC 3.1
   Non-local source routing        on/off                 HRC 3.3.5
   Policy filters for
   non-local source routing        (list)                 HRC 3.3.5
   Maximum reassembly size         integer                HRC 3.3.2
   Default TTL                     integer                HRC 3.2.1.7
   PMTU aging timeout              integer                MTU 6.6
   MTU plateau table               (list)                 MTU 7
   IP-layer_parameters,_per_interface:_
   IP address                      (address)              HRC 3.3.1.6
   Subnet mask                     (address mask)         HRC 3.3.1.6
   MTU                             integer                HRC 3.3.3
   All-subnets-MTU                 on/off                 HRC 3.3.3
   Broadcast address flavor        0x00000000/0xffffffff  HRC 3.3.6
   Perform mask discovery          on/off                 HRC 3.2.2.9
   Be a mask supplier              on/off                 HRC 3.2.2.9
   Perform router discovery        on/off                 RD 5.1
   Router solicitation address     (address)              RD 5.1
   Default routers, list of:
           router address          (address)              HRC 3.3.1.6
           preference level        integer                HRC 3.3.1.6
   Static routes, list of:
           destination             (host/subnet/net)      HRC 3.3.1.2
           destination mask        (address mask)         HRC 3.3.1.2
           type-of-service         integer                HRC 3.3.1.2
           first-hop router        (address)              HRC 3.3.1.2
           ignore redirects        on/off                 HRC 3.3.1.2
           PMTU                    integer                MTU 6.6
           perform PMTU discovery  on/off                 MTU 6.6
   Link-layer_parameters,_per_interface:_
   Trailers                       on/off                 HRC 2.3.1
   ARP cache timeout              integer                HRC 2.3.2.1
   Ethernet encapsulation         (RFC 894/RFC 1042)     HRC 2.3.3
   TCP_parameters,_per_host:_
   TTL                            integer                HRC 4.2.2.19
   Keep-alive interval            integer                HRC 4.2.3.6
   Keep-alive data size           0/1                    HRC 4.2.3.6
Key:
   MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
   RD = Router Discovery (RFC 1256, Proposed Standard)