i iia, iii
`
`DECLARATION OF SANDY GINOZA FOR IETF
`
`RFC 768: USER DATAGRAM PROTOCOL
`
`1, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`i.
`
`I am an'employee of Association Management Solutions, LLC (AMS), which
`
`acts under contract to the Internet Society (ISOC) 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 places files 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 AMS in this capacity on 6 January 2010.
`
`2.
`
`Among my responsibilities 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 (I81). I held various position titles with
`
`the RFC Editor project at ISI, ending with Senior Editor.
`
`4.
`
`The RFC Editor function was conducted by 181 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 of contracts with 181 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
`
`

`

`il
`l
`
`
`
`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 {Si 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 was published, 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 FT? 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 located it. In particular, the RFCs were indexed and placed in a public repository.
`
`8.
`
`The RFCs are 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 of its 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, 1 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 RFC is 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 America that the foregoing is true and correct
`
`and that the foregoing is based upon personal knowledge and information and is believed to be
`
`true.
`
`Date:
`
`ll
`
`9
`
`48278757379691
`
`7’0“”
`
`By:
`61
`ATTACHED CALIF. ACKNOWLEDGMENT g0 hill?
`
`Sa dy
`
`za
`
`Apple Inc.
`Ex. 1027 - Page 3
`
`Apple Inc.
`Ex. 1027 - Page 3
`
`

`

` CALIFORNIA ALL-PURPOSE ACKNOWLEDGMENT
`CIVIL CODE § 1189
`
`
`A notary pubiic or other officer completing this certificate verifies oniy 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.
`
`
`
`State of Caiifornia
`‘
`.,
`County ofW )
`On
`September trims/beam,
`cs. b'dgodlilw Name Nblic
`
`Here insert Name and Title of the Officer
`Date
`
`gmii
`personally appeared
`Ell/W191
`X Namefis)‘ofSignerjsj'
`who proved to me on the basis of satisfactory evidence to be the pe:on‘(sj whose namaéékB/‘afis'
`
`subs
`
`ibed to the within instrument and acknowled ed to me that he/ he
`
`executed the same In
`
`the instrument the persogis’),
`his .her heir authorized capacity/(Les), and that lay-his he theicsignaturefi
`ort
`entity upon behalf of which the person?) acts , executed the instrument.
`
`
`
`§
`s s. DFLGADILLO
`I
`
`2
`Notary Public California
`g
`Los Angeles County
`
`F
`COMmission it 2221ii'20
`
`My Comm. Expires Dec 9. 2021
`'
`
`i certify under PENALTY OF PERJURY under the iaws
`of the State of Caiifornia that the foregoing paragraph
`is true and correct.
`
`WITNESS my hand and official seal.
`
`Signature
`
`8 -- S "
`
`(Add/U0
`
`Signature 0 Notary Pubiic
`
`Place Notan/ Seai Above
`
`OPTIONAL
`
`Though this section is optional, completing this information can deter aiteration of the document or
`frauduient reattachment of this form to an unintended document.
`
`Description of Attached Document
`
`Title or Type of Document: T60“than 9’1: Sand.
`
`01- V
`Document Date:
`Signer(s) Other Than Named Above: NM
`
`PFC wed/rad deifigriii’l
`Gil/111151 ‘f‘rf
`[EVE
`
`Number of Pages:
`
`5
`
`Capacityfies) Claimed by Signer(s)
`Signer’s Name:
`l3 Corporate Officer — Title(s):
`[3 Partner — l] Limited
`C] General
`
`Signer’s Name:
`:1 Corporate Officer — Title(s):
`3 Partner - E] Limited
`E] Generai
`
`
`
`’Cl Attorney in Fact
`:3 Individual
`l3 Attorney in Fact
`El Individual
`{:1 Trustee
`El Guardian or Conservator
`l3 Trustee
`[I] Guardian or Conservator
`
`[:2] Other:
`Cl Other:
`
`Signer ls Representing: Signer is Representing:
`
`
`@2016 National Notary Association-www.i\iationalNotary.org-1—800—US NOTARY (1800-8766827)
`Item #5907
`
`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
`
`