Frontmatter Section Committee RC2 changes

content/coverpage.tex

@@ -60,6 +60,7 @@ \subsection*{\openshmem 1.6}
 \item Aurelien Bouteiller, \ac{UTK}
 \item Mark Brown, Intel
 \item Bob Cernohous, \ac{HPE}
+\item Matthew Davis, Georgia Tech
 \item James Dinan\footnotemark[1], NVIDIA
 \item Megan Grodowitz, Arm Inc.
 \item Max Grossman, Georgia Tech

content/library_handles.tex

@@ -25,8 +25,8 @@
 Handle of type \CTYPE{shmem\_team\_t} that corresponds to a team of \acp{PE}
 that share a memory domain.  \LibHandleRef{SHMEM\_TEAM\_SHARED} refers to
 the team of all PEs that would mutually return a non-null address from a
-call to \FUNC{shmem\_ptr} for all symmetric heap objects.  That is,
-\FUNC{shmem\_ptr} must return a non-null pointer to the local PE for all
+call to \FUNC{shmem\_ptr} or \FUNC{shmem\_team\_ptr} for all symmetric heap objects.  That is,
+\FUNC{shmem\_ptr} and \FUNC{shmem\_team\_ptr} must return a non-null pointer to the local PE for all
 symmetric heap objects on all target \acp{PE} in the team.  This means that
 symmetric heap objects on each \ac{PE} are
 directly load/store accessible by all \acp{PE} in the team.

content/programming_model_overview.tex

@@ -2,7 +2,10 @@
 mechanisms to share information among \openshmem processes, or \acp{PE}, and
 private data objects that are accessible by only the \ac{PE} itself. The \ac{API}
 allows communication and synchronization operations on both private (local to
-the \ac{PE} initiating the operation) and remotely accessible data objects. The key
+the \ac{PE} initiating the operation) and remotely accessible data objects. A
+remote \ac{PE} is defined as any \ac{PE} whose remotely accessible data objects
+are accessible to the \ac{PE} initiating an operation and may include the
+initiating \ac{PE}. The key
 feature of \openshmem is that data transfer operations are
 \emph{one-sided} in nature. This means that a local \ac{PE} executing
 a data transfer routine does not require the participation of the remote \ac{PE}