As per Relevance of the word copyright, we have this rfc below:
Network Working Group R.
Request for Comments: 3097
Updates: 2747 L.
Category: Standards Track
April 2001
RSVP Cryptographic Authentication --
Updated Message Type
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo resolves a duplication in the assignment of RSVP
Types, by changing the Message Types assigned by RFC 2747
Challenge and Integrity Response messages
1.
RFC 2747 ("RSVP Cryptographic Authentication") [RFC2747] assigns
Message Type 12 to an Integrity Response message, while RFC 2961
("RSVP Refresh Overhead Reduction Extensions") [RFC2961] assigns
same value to a Bundle message. This memo resolves the conflict
RSVP Message Type 12 by assigning a different value to the
Type of the Integrity Response Message in RFC 2747. It is
that the protocol defined by RFC 2961 entered use in the field
the RFC's publication and before the conflicting Message Type
noticed, and that it may be easier to install new software
environments that have deployed the Integrity object than in
that have deployed the refresh reduction extension
To simplify possible interoperability problems caused by this change
we also assign a new value to the Message Type of RFC 2747'
Challenge message, to which the Integrity Response message is
reply
Braden & Zhang Standards Track [Page 1]
RFC 3097 RSVP Cryptographic Authentication April 2001
2.
Message Types defined in the RSVP Integrity extension [RFC 2747]
shall be changed as follows
o Challenge message has Message Type 25.
o Integrity Response message has Message Type 25+1.
3.
Two communicating nodes whose Integrity implementations
conformant with this modification will interoperate, using
Type 12 for Bundle messages and Message Types 25 and 26 for
Integrity handshake. A non-conformant implementation of
Integrity extension will not interoperate with a
implementation (though two non-conformant implementations
interoperate as before).
There is no possibility of an Integrity handshake
accidentally due to this change, since both sides of the
use the new numbers or the old numbers. Furthermore, the
Response message includes a 32-bit cookie that must match a cookie
the Challenge message, else the challenge will fail. Finally,
non-conformant implementation should never receive a Bundle
that it interprets as an Integrity Response message, since RFC 2961
requires that Bundle messages be sent only to a Bundle-capable node
4.
[RFC2747] Baker, F., Lindell, R. and M. Talwar, "RSVP
Authentication", RFC 2747, January 2000.
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F
and S. Molendini, "RSVP Refresh Overhead
Extensions", RFC 2961, April 2001.
Security
No new security considerations are introduced beyond RFC 2747
and the compatibility issues above
Braden & Zhang Standards Track [Page 2]
RFC 3097 RSVP Cryptographic Authentication April 2001
Authors'
Bob
USC Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: (310) 822-1511
EMail: Braden@ISI.
Lixia
UCLA Computer Science
4531G Boelter
Los Angeles, CA 90095-1596
Phone: 310-825-2695
EMail: lixia@cs.ucla.
Braden & Zhang Standards Track [Page 3]
RFC 3097 RSVP Cryptographic Authentication April 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Braden & Zhang Standards Track [Page 4]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
