E i iEE E i :
`
`
`
`
`
`
`
`DECLARATION OF SANDY GINOZA FOR IETF
`
`RFC: 1918 ADDRESS ALLOCATION FOR PRIVATE INTEREETS
`
`1, Sandy Ginoza, based on my personal knowledge and information, hereby declare as
`
`follows:
`
`1.
`
`I am an employee of Association Management Solutions, LLC (AMS), which
`
`act under contract to the IETF Administration LLC (IETF) 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 IETF. 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 Productiou 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, Iwas an employee of the Information
`
`Sciences Institute at University of Southern Caiifornia (ISI). I held various position titles with
`
`the RFC Editor project at ISI, ending with Senior Editor.
`
`4.
`
`The RFC 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 of contracts with ISI providing for ISI‘s performance of the RFC Editor
`
`function. Beginning in 2010, certain aspects of the RFC Editor function were assumed by the
`
`RFC Production Center operation of AMS under contract to ISOC (acting through its IETF
`
`Apple Inc.
`EX. 1017 - Page 1
`
`Apple Inc.
`Ex. 1017 - Page 1
`
`

`

`
`
`
`
` i
`-i
`l'l
`
`function and, in particular, the IETF Administrative Oversight Committee (now the IETF
`
`Administration LLC (IETF)). The business records of the RFC Editor function as it was
`
`conducted by 131 are currently housed on the computer systems of AMS, as contractor to the
`
`IETF.
`
`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'sregular 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 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 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 for the RFC Editor and the RFC Editor’ 5 course of
`
`conduct in publishing RFCs, I have determined that the publication date of RFC 1918 was no
`
`later than August 1998, at which time it was reasonably accessible to the public either on the
`
`Apple Inc.
`EX. 1017 - Page 2
`
`Apple Inc.
`Ex. 1017 - 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:
`
`NW N 4/“?
`
`4845-2237-4265. l
`
`By:
`
`and
`
`'oza
`
`'
`
`meatsBAUEACKNOWLEDGMEN"&Q \\ \\O\\\O
`
`'
`
`Q
`
`3 '
`
`25
`
`lil li2i
`
`Apple Inc.
`Ex. 1017 - Page 3
`
`Apple Inc.
`Ex. 1017 - Page 3
`
`

`

`CIVEL CODE § 1189
`CALIFORNlA ALL-PURPOSE ACKNOWLEDGMENT
`
`
`A notary public or other officer completing this certificate verifies only the identity of the individuai who signed the
`document to which this certificate is attached, and not the truthfulness, accuracy, or validity of that document.
`
`State of California
`
`)
`
`log 'PYX‘LCQ‘EW
`Countyof
`)
`M L DIEM/j: NOW§%\(RU/JMC
`H “0‘ E ‘25
`beforerne,
`K?
`personally appeared
`Nam
`f Signer©L
`
`
`Date
`
`Here insert Name and Title of the Office
`
`
`
`whose namegggéié
`0
`who proved to me on the basis of satisfactory evidence to be the
`
`executed the sa 6 in
`t
`sub ribed to the within instrument and acknowlue ed to me that "1
`Whgiauthorized capacitylm and that byIhr“@tfiir signatur
`- he instrument the persom
`-.
`
`ort = -ntity upon behalf of which the personllsia- ,executed the instrument.
`
`I
`
`.. myom-Eipi'ES-‘mptmozi Signature
`
`i certify under PENALTY OF PERJURY under the laws
`of the State of California that the foregoing paragraph
`is true and correct.
`
`.
`,
`WITNESS my hand and otiIcial seal.
`
`.
`Signature of otary P a
`
`
`
`
`
`
`
`M.L.PEREZ
`Notary Public—Califomfa
`Lcs Angeies County
`Commission II 2213639
`
`'
`
`Place Notary Seal Above
`
`OPTIONAL
`
`Though this section is optional, completing this information can deter alteration of the document or
`fraudulent reattachment of this form to an unintended document.
`
`Description of Attached D ume t
`
`Title or Type of Document:
`Document Date:
`
`
`“M 0-1th LETFD
`0
`Ir
`(00'6“ n OILS— G Numblarof Pages.
`Ht
`
`
`
`Signer(s) Other Than Name Above.
`
`
`
`Capacityties) Claimed by Signer(s)
`Signer’s Name:
`EL] Corporate Officer — Titie(s):
`III Partner — 1:] Limited
`El General
`
`Signer’s Name:
`El Corporate Officer — Title(s):
`III Partner — D Limited
`El Generai
`
`El Individual
`III Attorney in Fact
`Ci lndividuai
`
`:I Trustee
`El Guardian or Conservator
`3 Trustee
`
`:l Other:
`El Other:
`
`Signer is Representing: Signer ls Representing:
`
`E] Attorney in Fact
`El Guardian or Conservator
`
`
`©2016 Nationai Notary Association- www.NationalNotaryorg- 1-800-US NOTARY (1--800—8766827)
`item #5907
`
`Apple Inc.
`EX. 1017 - Page 4
`
`‘0
`
`
`
`Apple Inc.
`Ex. 1017 - Page 4
`
`

`

`Network Working Group Y. Rekhter
`Request for Comments: 1918 Cisco Systems
`Obsoletes: 1627, 1597 B. Moskowitz
`BCP: 5 Chrysler Corp.
`Category: Best Current Practice D. Karrenberg
` RIPE NCC
` G. J. de Groot
` RIPE NCC
` E. Lear
` Silicon Graphics, Inc.
` February 1996
`
` Address Allocation for Private Internets
`
`Status of this Memo
`
` This document specifies an Internet Best Current Practices for the
` Internet Community, and requests discussion and suggestions for
` improvements. Distribution of this memo is unlimited.
`
`1. Introduction
`
` For the purposes of this document, an enterprise is an entity
` autonomously operating a network using TCP/IP and in particular
` determining the addressing plan and address assignments within that
` network.
`
` This document describes address allocation for private internets. The
` allocation permits full network layer connectivity among all hosts
` inside an enterprise as well as among all public hosts of different
` enterprises. The cost of using private internet address space is the
` potentially costly effort to renumber hosts and networks between
` public and private.
`
`2. Motivation
`
` With the proliferation of TCP/IP technology worldwide, including
` outside the Internet itself, an increasing number of non-connected
` enterprises use this technology and its addressing capabilities for
` sole intra-enterprise communications, without any intention to ever
` directly connect to other enterprises or the Internet itself.
`
` The Internet has grown beyond anyone’s expectations. Sustained
` exponential growth continues to introduce new challenges. One
` challenge is a concern within the community that globally unique
` address space will be exhausted. A separate and far more pressing
` concern is that the amount of routing overhead will grow beyond the
`
`Rekhter, et al Best Current Practice [Page 1]
`
`Apple Inc.
`Ex. 1017 - Page 5
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
` capabilities of Internet Service Providers. Efforts are in progress
` within the community to find long term solutions to both of these
` problems. Meanwhile it is necessary to revisit address allocation
` procedures, and their impact on the Internet routing system.
`
` To contain growth of routing overhead, an Internet Provider obtains a
` block of address space from an address registry, and then assigns to
` its customers addresses from within that block based on each customer
` requirement. The result of this process is that routes to many
` customers will be aggregated together, and will appear to other
` providers as a single route [RFC1518], [RFC1519]. In order for route
` aggregation to be effective, Internet providers encourage customers
` joining their network to use the provider’s block, and thus renumber
` their computers. Such encouragement may become a requirement in the
` future.
`
` With the current size of the Internet and its growth rate it is no
` longer realistic to assume that by virtue of acquiring globally
` unique IP addresses out of an Internet registry an organization that
` acquires such addresses would have Internet-wide IP connectivity once
` the organization gets connected to the Internet. To the contrary, it
` is quite likely that when the organization would connect to the
` Internet to achieve Internet-wide IP connectivity the organization
` would need to change IP addresses (renumber) all of its public hosts
` (hosts that require Internet-wide IP connectivity), regardless of
` whether the addresses used by the organization initially were
` globally unique or not.
`
` It has been typical to assign globally unique addresses to all hosts
` that use TCP/IP. In order to extend the life of the IPv4 address
` space, address registries are requiring more justification than ever
` before, making it harder for organizations to acquire additional
` address space [RFC1466].
`
` Hosts within enterprises that use IP can be partitioned into three
` categories:
`
` Category 1: hosts that do not require access to hosts in other
` enterprises or the Internet at large; hosts within
` this category may use IP addresses that are
` unambiguous within an enterprise, but may be
` ambiguous between enterprises.
`
` Category 2: hosts that need access to a limited set of outside
` services (e.g., E-mail, FTP, netnews, remote login)
` which can be handled by mediating gateways (e.g.,
` application layer gateways). For many hosts in this
` category an unrestricted external access (provided
`
`Rekhter, et al Best Current Practice [Page 2]
`
`Apple Inc.
`Ex. 1017 - Page 6
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
` via IP connectivity) may be unnecessary and even
` undesirable for privacy/security reasons. Just like
` hosts within the first category, such hosts may use
` IP addresses that are unambiguous within an
` enterprise, but may be ambiguous between
` enterprises.
`
` Category 3: hosts that need network layer access outside the
` enterprise (provided via IP connectivity); hosts in
` the last category require IP addresses that are
` globally unambiguous.
`
` We will refer to the hosts in the first and second categories as
` "private". We will refer to the hosts in the third category as
` "public".
`
` Many applications require connectivity only within one enterprise and
` do not need external (outside the enterprise) connectivity for the
` majority of internal hosts. In larger enterprises it is often easy to
` identify a substantial number of hosts using TCP/IP that do not need
` network layer connectivity outside the enterprise.
`
` Some examples, where external connectivity might not be required,
` are:
`
` - A large airport which has its arrival/departure displays
` individually addressable via TCP/IP. It is very unlikely
` that these displays need to be directly accessible from
` other networks.
`
` - Large organizations like banks and retail chains are
` switching to TCP/IP for their internal communication. Large
` numbers of local workstations like cash registers, money
` machines, and equipment at clerical positions rarely need
` to have such connectivity.
`
` - For security reasons, many enterprises use application
` layer gateways to connect their internal network to the
` Internet. The internal network usually does not have
` direct access to the Internet, thus only one or more
` gateways are visible from the Internet. In this case, the
` internal network can use non-unique IP network numbers.
`
` - Interfaces of routers on an internal network usually do not
` need to be directly accessible from outside the enterprise.
`
`Rekhter, et al Best Current Practice [Page 3]
`
`Apple Inc.
`Ex. 1017 - Page 7
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
`3. Private Address Space
`
` The Internet Assigned Numbers Authority (IANA) has reserved the
` following three blocks of the IP address space for private internets:
`
` 10.0.0.0 - 10.255.255.255 (10/8 prefix)
` 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
` 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
`
` We will refer to the first block as "24-bit block", the second as
` "20-bit block", and to the third as "16-bit" block. Note that (in
` pre-CIDR notation) the first block is nothing but a single class A
` network number, while the second block is a set of 16 contiguous
` class B network numbers, and third block is a set of 256 contiguous
` class C network numbers.
`
` An enterprise that decides to use IP addresses out of the address
` space defined in this document can do so without any coordination
` with IANA or an Internet registry. The address space can thus be used
` by many enterprises. Addresses within this private address space will
` only be unique within the enterprise, or the set of enterprises which
` choose to cooperate over this space so they may communicate with each
` other in their own private internet.
`
` As before, any enterprise that needs globally unique address space is
` required to obtain such addresses from an Internet registry. An
` enterprise that requests IP addresses for its external connectivity
` will never be assigned addresses from the blocks defined above.
`
` In order to use private address space, an enterprise needs to
` determine which hosts do not need to have network layer connectivity
` outside the enterprise in the foreseeable future and thus could be
` classified as private. Such hosts will use the private address space
` defined above. Private hosts can communicate with all other hosts
` inside the enterprise, both public and private. However, they cannot
` have IP connectivity to any host outside of the enterprise. While not
` having external (outside of the enterprise) IP connectivity private
` hosts can still have access to external services via mediating
` gateways (e.g., application layer gateways).
`
` All other hosts will be public and will use globally unique address
` space assigned by an Internet Registry. Public hosts can communicate
` with other hosts inside the enterprise both public and private and
` can have IP connectivity to public hosts outside the enterprise.
` Public hosts do not have connectivity to private hosts of other
` enterprises.
`
`Rekhter, et al Best Current Practice [Page 4]
`
`Apple Inc.
`Ex. 1017 - Page 8
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
` Moving a host from private to public or vice versa involves a change
` of IP address, changes to the appropriate DNS entries, and changes to
` configuration files on other hosts that reference the host by IP
` address.
`
` Because private addresses have no global meaning, routing information
` about private networks shall not be propagated on inter-enterprise
` links, and packets with private source or destination addresses
` should not be forwarded across such links. Routers in networks not
` using private address space, especially those of Internet service
` providers, are expected to be configured to reject (filter out)
` routing information about private networks. If such a router receives
` such information the rejection shall not be treated as a routing
` protocol error.
`
` Indirect references to such addresses should be contained within the
` enterprise. Prominent examples of such references are DNS Resource
` Records and other information referring to internal private
` addresses. In particular, Internet service providers should take
` measures to prevent such leakage.
`
`4. Advantages and Disadvantages of Using Private Address Space
`
` The obvious advantage of using private address space for the Internet
` at large is to conserve the globally unique address space by not
` using it where global uniqueness is not required.
`
` Enterprises themselves also enjoy a number of benefits from their
` usage of private address space: They gain a lot of flexibility in
` network design by having more address space at their disposal than
` they could obtain from the globally unique pool. This enables
` operationally and administratively convenient addressing schemes as
` well as easier growth paths.
`
` For a variety of reasons the Internet has already encountered
` situations where an enterprise that has not been connected to the
` Internet had used IP address space for its hosts without getting this
` space assigned from the IANA. In some cases this address space had
` been already assigned to other enterprises. If such an enterprise
` would later connects to the Internet, this could potentially create
` very serious problems, as IP routing cannot provide correct
` operations in presence of ambiguous addressing. Although in principle
` Internet Service Providers should guard against such mistakes through
` the use of route filters, this does not always happen in practice.
` Using private address space provides a safe choice for such
` enterprises, avoiding clashes once outside connectivity is needed.
`
`Rekhter, et al Best Current Practice [Page 5]
`
`Apple Inc.
`Ex. 1017 - Page 9
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
` A major drawback to the use of private address space is that it may
` actually reduce an enterprise’s flexibility to access the Internet.
` Once one commits to using a private address, one is committing to
` renumber part or all of an enterprise, should one decide to provide
` IP connectivity between that part (or all of the enterprise) and the
` Internet. Usually the cost of renumbering can be measured by
` counting the number of hosts that have to transition from private to
` public. As was discussed earlier, however, even if a network uses
` globally unique addresses, it may still have to renumber in order to
` acquire Internet-wide IP connectivity.
`
` Another drawback to the use of private address space is that it may
` require renumbering when merging several private internets into a
` single private internet. If we review the examples we list in Section
` 2, we note that companies tend to merge. If such companies prior to
` the merge maintained their uncoordinated internets using private
` address space, then if after the merge these private internets would
` be combined into a single private internet, some addresses within the
` combined private internet may not be unique. As a result, hosts with
` these addresses would need to be renumbered.
`
` The cost of renumbering may well be mitigated by development and
` deployment of tools that facilitate renumbering (e.g. Dynamic Host
` Configuration Protocol (DHCP)). When deciding whether to use private
` addresses, we recommend to inquire computer and software vendors
` about availability of such tools. A separate IETF effort (PIER
` Working Group) is pursuing full documentation of the requirements and
` procedures for renumbering.
`
`5. Operational Considerations
`
` One possible strategy is to design the private part of the network
` first and use private address space for all internal links. Then plan
` public subnets at the locations needed and design the external
` connectivity.
`
` This design does not need to be fixed permanently. If a group of one
` or more hosts requires to change their status (from private to public
` or vice versa) later, this can be accomplished by renumbering only
` the hosts involved, and changing physical connectivity, if needed. In
` locations where such changes can be foreseen (machine rooms, etc.),
` it is advisable to configure separate physical media for public and
` private subnets to facilitate such changes. In order to avoid major
` network disruptions, it is advisable to group hosts with similar
` connectivity needs on their own subnets.
`
`Rekhter, et al Best Current Practice [Page 6]
`
`Apple Inc.
`Ex. 1017 - Page 10
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
` If a suitable subnetting scheme can be designed and is supported by
` the equipment concerned, it is advisable to use the 24-bit block
` (class A network) of private address space and make an addressing
` plan with a good growth path. If subnetting is a problem, the 16-bit
` block (class C networks), or the 20-bit block (class B networks) of
` private address space can be used.
`
` One might be tempted to have both public and private addresses on the
` same physical medium. While this is possible, there are pitfalls to
` such a design (note that the pitfalls have nothing to do with the use
` of private addresses, but are due to the presence of multiple IP
` subnets on a common Data Link subnetwork). We advise caution when
` proceeding in this area.
`
` It is strongly recommended that routers which connect enterprises to
` external networks are set up with appropriate packet and routing
` filters at both ends of the link in order to prevent packet and
` routing information leakage. An enterprise should also filter any
` private networks from inbound routing information in order to protect
` itself from ambiguous routing situations which can occur if routes to
` the private address space point outside the enterprise.
`
` It is possible for two sites, who both coordinate their private
` address space, to communicate with each other over a public network.
` To do so they must use some method of encapsulation at their borders
` to a public network, thus keeping their private addresses private.
`
` If two (or more) organizations follow the address allocation
` specified in this document and then later wish to establish IP
` connectivity with each other, then there is a risk that address
` uniqueness would be violated. To minimize the risk it is strongly
` recommended that an organization using private IP addresses choose
` randomly from the reserved pool of private addresses, when allocating
` sub-blocks for its internal allocation.
`
` If an enterprise uses the private address space, or a mix of private
` and public address spaces, then DNS clients outside of the enterprise
` should not see addresses in the private address space used by the
` enterprise, since these addresses would be ambiguous. One way to
` ensure this is to run two authority servers for each DNS zone
` containing both publically and privately addressed hosts. One server
` would be visible from the public address space and would contain only
` the subset of the enterprise’s addresses which were reachable using
` public addresses. The other server would be reachable only from the
` private network and would contain the full set of data, including the
` private addresses and whatever public addresses are reachable the
` private network. In order to ensure consistency, both servers should
` be configured from the same data of which the publically visible zone
`
`Rekhter, et al Best Current Practice [Page 7]
`
`Apple Inc.
`Ex. 1017 - Page 11
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
` only contains a filtered version. There is certain degree of
` additional complexity associated with providing these capabilities.
`
`6. Security Considerations
`
` Security issues are not addressed in this memo.
`
`7. Conclusion
`
` With the described scheme many large enterprises will need only a
` relatively small block of addresses from the globally unique IP
` address space. The Internet at large benefits through conservation of
` globally unique address space which will effectively lengthen the
` lifetime of the IP address space. The enterprises benefit from the
` increased flexibility provided by a relatively large private address
` space. However, use of private addressing requires that an
` organization renumber part or all of its enterprise network, as its
` connectivity requirements change over time.
`
`8. Acknowledgments
`
` We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-
` Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN
` Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne
` Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks),
` Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute),
` Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush
` (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg
` Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence),
` Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet
` Software Consortium) for their review and constructive comments.
`
`9. References
`
` [RFC1466] Gerich, E., "Guidelines for Management of IP Address
` Space", RFC 1466, Merit Network, Inc., May 1993.
`
` [RFC1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
` Allocation with CIDR", RFC 1518, September 1993.
`
` [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
` Inter-Domain Routing (CIDR): an Address Assignment and
` Aggregation Strategy", RFC 1519, September 1993.
`
`Rekhter, et al Best Current Practice [Page 8]
`
`Apple Inc.
`Ex. 1017 - Page 12
`
`

`

`
`RFC 1918 Address Allocation for Private Internets February 1996
`
`10. Authors’ Addresses
`
` Yakov Rekhter
` Cisco systems
` 170 West Tasman Drive
` San Jose, CA, USA
` Phone: +1 914 528 0090
` Fax: +1 408 526-4952
` EMail: yakov@cisco.com
`
` Robert G Moskowitz
` Chrysler Corporation
` CIMS: 424-73-00
` 25999 Lawrence Ave
` Center Line, MI 48015
` Phone: +1 810 758 8212
` Fax: +1 810 758 8173
` EMail: rgm3@is.chrysler.com
`
` Daniel Karrenberg
` RIPE Network Coordination Centre
` Kruislaan 409
` 1098 SJ Amsterdam, the Netherlands
` Phone: +31 20 592 5065
` Fax: +31 20 592 5090
` EMail: Daniel.Karrenberg@ripe.net
`
` Geert Jan de Groot
` RIPE Network Coordination Centre
` Kruislaan 409
` 1098 SJ Amsterdam, the Netherlands
` Phone: +31 20 592 5065
` Fax: +31 20 592 5090
` EMail: GeertJan.deGroot@ripe.net
`
` Eliot Lear
` Mail Stop 15-730
` Silicon Graphics, Inc.
` 2011 N. Shoreline Blvd.
` Mountain View, CA 94043-1389
` Phone: +1 415 960 1980
` Fax: +1 415 961 9584
` EMail: lear@sgi.com
`
`Rekhter, et al Best Current Practice [Page 9]
`
`Apple Inc.
`Ex. 1017 - Page 13
`
`