}iii iii
`
`DECLARATION OF SANDY GINOZA FORIETF
`RFC _768: USER DATAGRAM PROTOCOL
`
`I, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`Tam anemployee ofAssociation Management Solutions, LLC (AMS), which
`
`acts under contract to the Internet Society (SOC)as the operator of the RFC Production
`
`Center. The RFC Production Center is part of the "RFC Editor" function, which prepares
`
`documents for publication and placesfiles in an online repository for the authoritative
`
`Request for Comments (RFC) series of documents (RFC Series), and preserves records
`
`relating to these documents. The RFC Series includes, among other things, the series of
`
`Internet standards developed by the Internet Engineering Task Force (IETF), an organized
`
`activity of ISOC. I hold the position of Director of the RFC Production Center. I began
`
`employment with AMSin this capacity on 6 January 2010,
`
`2.
`
`Among myresponsibilities as Director of the RFC Production Center, I act as
`
`the custodian of records relating to the RFC Series, and I am familiar with the record keeping
`
`practices relating to the RFC Series, including the creation and maintenance of such records.
`
`3.
`
`From June 1999 to 5 January 2010, I was an employee of the Information
`
`Sciences Institute at University of Southern California (IST). I held various position titles with
`
`the RFC Editor project at ISI, ending with Senior Editor.
`4.
`The REC Editor function was conducted by ISI under contract to the United
`
`States government prior to 1998, In 1998, ISOC,in furtherance of its IETF activity, entered into
`the first in a series ofcontracts with ISI providing for ISI's performance ofthe RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`Apple Inc.
`Ex. 1027 - Page 1
`
`Apple Inc.
`Ex. 1027 - Page 1
`
`

`

`||
`L
`
`|i
`
`ii
`
`
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`function and, in particular, the IETF Administrative Oversight Committee). The business records
`
`of the RFC Editor function as it was conducted by ISI are currently housed on the computer
`
`systems of AMS,as contractor to ISOC.
`
`5.
`
`I make this declaration based on my personal knowledge and information
`
`contained in the business records of the RFC Editor as they are currently housed at AMS,or
`
`confirmation with other responsible RFC Editor personnel with such knowledge.
`
`6,
`
`Prior to 1998, the RFC Editor's regular practice was to publish RFCs, making
`
`them available from a repository via FTP. When a new RFC waspublished, an announcement
`
`of its publication, with information on how to access the RFC, would be typically sent out
`
`within 24 hours of the publication.
`
`7.
`
`Any RFC published on the RFC Editor website or via FTP was reasonably
`
`accessible to the public and was disseminated or otherwise available to the extent that persons
`
`interested and ordinarily skilled in the subject matter or art exercising reasonable diligence could
`
`have locatedit. In particular, the RFCs were indexed and placed in a public repository.
`
`8.
`
`The RFCsare kept in an online repository in the course of the RFC Editor's
`
`regularly conducted activity and ordinary course of business. The records are made pursuant to
`
`established procedures and are relied upon by the RFC Editor in the performance ofits functions.
`
`9,
`
`It is the regular practice of the RFC Editor to make and keep the RFC records.
`
`10.
`
`Based on the business records of the RFC Editor and the RFC Editor’s course of
`
`conduct in publishing RFCs, i have determined that the publication date of RFC 768 was no
`
`later than October 1992, at which time it was reasonably accessible to the public either on the
`
`Apple Inc.
`Ex. 1027 - Page 2
`
`Apple Inc.
`Ex. 1027 - Page 2
`
`

`

`RFC Editor website or via FTP from a repository. A copy of that RFCis attached to this
`
`declaration as an exhibit.
`
`Pursuant to Section 1746 of Title 28 of United States Code, I declare under penalty of
`
`perjury under the laws of the United States of Americathat the foregoingis true and correct
`
`and that the foregoing is based upon personal knowledge and information and is believed to be
`
`true.
`
`Date:
`
`i
`
`&
`
`4827-8757-7969,t
`
`B9\9
`ATTACHED CALIF. ACKNOWLEDGMENT Ap
`
`By:
`4
`| UL
`
`Sawdy
`
`Za
`
`Apple Inc.
`Ex. 1027 - Page 3
`
`Apple Inc.
`Ex. 1027 - Page 3
`
`

`

`State of California
`County of LUS Ores
`on
`Septomber tit" 21%,.for0 me,
`Date
`personally appeared
`
`
`
`
`
`OS. pelgudlitio- Neary public
`mereInsert Name and Title of the Officer
`Candy
`Giy24
`> Name(sofSigner{af
`who proved to me on the basis of satisfactory evidence to be the Cobre whose nameléyishater
`
`
`
` CALIFORNIA ALL-PURPOSE ACKNOWLEDGMENT CIVIL CODE8 1189
`
`A notary public or other officer completing this certificate verifies only the identity of the individual who signed the
`document to which this certificate is attached, and not the truthfulness, accuracy, or validity of that document.
`
`)
`)
`
`
`
`executed the same in
`subse¢ribed to the within instrument and acknowledged to me that Rejshe
`-his(herjthenr authorized capacity(ies), and that by Hisshef/thel-signatures)onthe instrument the person{e),
`or the’entity upon behalf of which the person(pj acted;“executed the instrument.
`I certify under PENALTY OF PERJURY underthe laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`
`
`,
`8.8.DELGADILLO
`
`Notary Public ~ California
`=
`Los Angeles County
`Commission # 3224790
`:
`y)
`
`My Comm. Expires Dee 9, 2021
`ff
`
`
`WITNESS my hand andi official seal.
`
`Signature
`
`S S al
`“st
`I
`i
`Signature of Notary Public
`
`Place Notary Seal Above
`
`GPTIONAL
`Though this section is optional, completing this information can deter alteration of the document or
`
`4 tag aw
`fraudulent reatlachment of this form to an unintended document.
`Tee Veer AAG
`Description of Attached Document
`at
`4
`Title orType of Document: pe AtTagion if Sand
`Clintza To ETE Re
`
`Number of Pages:
`Alt
`Document Date:
`4
`Signer(s) Other Than Named Above:__NOAS-
`
`Capacity(ies) Claimed by Signer(s)
`Signer’s Name:
`Signer’s Name:
`_} Corporate Officer — Title(s):
`Ci Corporate Officer — Title{s):
`[J Partner — (] Limited
`(1) General
`(J Partner — (] Limited 1 General
`[J Individual
`i] Attorney in Fact
`LI Individual
`C1 Attorney in Fact
`i] Trustee
`C} Guardian or Conservator
`C3 Trustee
`C] Guardian or Conservator
`
`C] Other:
`L] Other:
`
`
`
`SignerIs Representing: Signer is Representing:
`
`©2016 Nationalal Notary /‘Association « www.v NationalNotary.0org:
`“800-US NOTARYY
`(1-800-876-"6827)
`
`
`
`
`item 45907
`
`Apple Inc.
`Ex. 1027 - Page 4
`
`Apple Inc.
`Ex. 1027 - Page 4
`
`

`

`RFC 768 J. Postel
` ISI
` 28 August 1980
`
` User Datagram Protocol
` ----------------------
`
`Introduction
`------------
`
`This User Datagram Protocol (UDP) is defined to make available a
`datagram mode of packet-switched computer communication in the
`environment of an interconnected set of computer networks. This
`protocol assumes that the Internet Protocol (IP) [1] is used as the
`underlying protocol.
`
`This protocol provides a procedure for application programs to send
`messages to other programs with a minimum of protocol mechanism. The
`protocol is transaction oriented, and delivery and duplicate protection
`are not guaranteed. Applications requiring ordered reliable delivery of
`streams of data should use the Transmission Control Protocol (TCP) [2].
`
`Format
`------
`
` 0 7 8 15 16 23 24 31
` +--------+--------+--------+--------+
` | Source | Destination |
` | Port | Port |
` +--------+--------+--------+--------+
` | | |
` | Length | Checksum |
` +--------+--------+--------+--------+
` |
` | data octets ...
` +---------------- ...
`
` User Datagram Header Format
`
`Fields
`------
`
`Source Port is an optional field, when meaningful, it indicates the port
`of the sending process, and may be assumed to be the port to which a
`reply should be addressed in the absence of any other information. If
`not used, a value of zero is inserted.
`
`Postel [page 1]
`
`Apple Inc.
`Ex. 1027 - Page 5
`
`

`

`
` 28 Aug 1980
`User Datagram Protocol RFC 768
`Fields
`
`Destination Port has a meaning within the context of a particular
`internet destination address.
`
`Length is the length in octets of this user datagram including this
`header and the data. (This means the minimum value of the length is
`eight.)
`
`Checksum is the 16-bit one’s complement of the one’s complement sum of a
`pseudo header of information from the IP header, the UDP header, and the
`data, padded with zero octets at the end (if necessary) to make a
`multiple of two octets.
`
`The pseudo header conceptually prefixed to the UDP header contains the
`source address, the destination address, the protocol, and the UDP
`length. This information gives protection against misrouted datagrams.
`This checksum procedure is the same as is used in TCP.
`
` 0 7 8 15 16 23 24 31
` +--------+--------+--------+--------+
` | source address |
` +--------+--------+--------+--------+
` | destination address |
` +--------+--------+--------+--------+
` | zero |protocol| UDP length |
` +--------+--------+--------+--------+
`
`If the computed checksum is zero, it is transmitted as all ones (the
`equivalent in one’s complement arithmetic). An all zero transmitted
`checksum value means that the transmitter generated no checksum (for
`debugging or for higher level protocols that don’t care).
`
`User Interface
`--------------
`
`A user interface should allow
`
` the creation of new receive ports,
`
` receive operations on the receive ports that return the data octets
` and an indication of source port and source address,
`
` and an operation that allows a datagram to be sent, specifying the
` data, source and destination ports and addresses to be sent.
`
`[page 2] Postel
`
`Apple Inc.
`Ex. 1027 - Page 6
`
`

`

`
`
`28 Aug 1980
`RFC 768 User Datagram Protocol
` IP Interface
`
`IP Interface
`-------------
`
`The UDP module must be able to determine the source and destination
`internet addresses and the protocol field from the internet header. One
`possible UDP/IP interface would return the whole internet datagram
`including all of the internet header in response to a receive operation.
`Such an interface would also allow the UDP to pass a full internet
`datagram complete with header to the IP to send. The IP would verify
`certain fields for consistency and compute the internet header checksum.
`
`Protocol Application
`--------------------
`
`The major uses of this protocol is the Internet Name Server [3], and the
`Trivial File Transfer [4].
`
`Protocol Number
`---------------
`
`This is protocol 17 (21 octal) when used in the Internet Protocol.
`Other protocol numbers are listed in [5].
`
`References
`----------
`
`[1] Postel, J., "Internet Protocol," RFC 760, USC/Information
` Sciences Institute, January 1980.
`
`[2] Postel, J., "Transmission Control Protocol," RFC 761,
` USC/Information Sciences Institute, January 1980.
`
`[3] Postel, J., "Internet Name Server," USC/Information Sciences
` Institute, IEN 116, August 1979.
`
`[4] Sollins, K., "The TFTP Protocol," Massachusetts Institute of
` Technology, IEN 133, January 1980.
`
`[5] Postel, J., "Assigned Numbers," USC/Information Sciences
` Institute, RFC 762, January 1980.
`
`Postel [page 3]
`
`Apple Inc.
`Ex. 1027 - Page 7
`
`