<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY><!-- Converted from text/plain format -->
<P><FONT size=2></FONT> </P>
<P><FONT color=#0000ff size=2>Greg et al,</FONT></P>
<P><FONT size=2><FONT color=#0000ff>Apologies for the late response.  Here 
are my thoughts on this:<BR></FONT><BR>>>APPROVE WITH CONDITIONS:  1 
(33.33%) (Durst)<BR>>><BR>>>In section 2.2, it is unclear what the 
conformance requirements<BR>>>are.  There are two protocols (Space 
Packet and Encapsulation Packet)<BR>>>under a single service 
interface.  Are both required for conformance?<BR>><BR>>**Both 
protocols can be used to encapsulate other protocols.<BR>>For 
example,<BR>>CFDP can be encapsulated into space packets by using 
APID=2045<BR>>or into an<BR>>Encapsulation packet by using PID = '110'. I 
need to know more<BR>>about what<BR>>you are expecting in terms of 
"conformance requirements". The<BR>>encapsulation<BR>>service specifies 
the inputs, what protocols are used to do the<BR>>encapsulating, and 
references the Space Link Identifiers<BR>>document, which<BR>>supplies all 
of the IDs one needs in order to carry out the service.**<BR><BR><FONT 
color=#0000ff>The conformance requirements I am asking about are whether 
an<BR>implementation is "conformant" if it only implements one of these<BR>two 
protocols (SPP or Encapsulation Packet).  If so, please say so.<BR>If not, 
please explain how you ensure interoperability between two<BR>conformant 
applications that invoke this service (when, for example,<BR>one is hosted on a 
node that implements SPP and the other is hosted<BR>on a node that implements 
only Encapsulation). <BR></FONT><BR>>>The document requires a SANA 
Implications section to address<BR>>registered<BR>>>APIDs and PIDs, and 
to define procedures to register new<BR>>APIDs and PIDs.<BR>><BR>>** 
All of the IDs used by the Encapsulation Service are defined in the<BR>>Space 
Link Identifiers spec. This is true for all of the link layer<BR>>protocols. 
Therefore, it is the Space Link Identifiers book<BR>>that requires 
a<BR>>SANA implication section, not Encap. service.  APIDs and 
PIDs<BR>>are defined<BR>>in the Space Link Identifiers book which is 
referenced in<BR>>section 2.3 **<BR><BR><FONT color=#0000ff>OK.  Does 
the Space Link Identifiers book have such a section?  My<BR>comment will be 
successfully resolved if either of these documents has a<BR>SANA 
section.<BR></FONT><BR><BR>>>The document requires a security implications 
section.<BR>><BR>>** I will work with Howie on how to accomplish this 
**<BR><BR><FONT color=#0000ff>OK.  When added, this comment will be 
resolved.<BR></FONT><BR>>>Section  It is unclear to me 
whether and how a user of the<BR>>>service is expected to know the correct 
GVCID and PVN to use.<BR>> Are these<BR>>>statically assigned?  
Assigned on a per-mission basis?  What are the<BR>>>implications on 
interoperability?<BR>><BR>>** GVCID = SCID + VCID. SCID is statically 
assigned. VCID is<BR>>an enterprise<BR>>or project managed parameter. 
CCSDS recognizes certain PVNs.<BR>>All of these<BR>>IDs are defined and 
their values are listed (if not a managed<BR>>parameter) in<BR>>the Space 
Link Identifiers spec. For things like PVN it's very<BR>>static. 
For<BR>>APIDs, an enterprise has to really manage these across 
the<BR>>enterprise in<BR>>order for interoperability to happen. Global 
enterprise APIDs begin to<BR>>happen in these cases. **<BR><BR><FONT 
color=#0000ff>This explanation is helpful.  I know that the book is 
normative, rather than informative, but it would be nice to have this explained 
in there.<BR></FONT><BR>>>Section 4.1, item b)  the APID "shall be 
one of the reserved APIDs"<BR>>>defined in reference [8].  Are there 
guidelines or further<BR>>restrictions on<BR>>>how a particular APID is 
chosen?  Does interoperability<BR>>depend on 
this<BR>>>choice?  In Table 5-2 of reference [8], there appear to 
be<BR>>two degrees of<BR>>>"reserved" -- reserved and assigned to a 
particular protocol,<BR>>and reserved<BR>>>but unassigned.  Are 
any of these fair game?  Or was it intended that<BR>>>these be drawn 
from the 2040-2044 range?<BR>><BR>>** Again APIDs are a managed parameter 
by an enterprise except<BR>>for the ones<BR>>defined in the CCSDS Space 
Link Identifiers book. There are no further<BR>>restrictions except the ones 
managed by the enterprise. Yes,<BR>>interoperability is an issue for the 
management of those apids. It is<BR>>intended that 2040-2044 be used for 
encapsulation by space packets. **<BR><BR><FONT color=#0000ff>Could you please 
clarify these points in the document?<BR><BR>I think that it would be useful to 
summarize the "managed parameters" somewhere, to make it clear specifically what 
bilateral agreements are required to ensure interoperability.  This may be 
part of the "lore" within the CCSDS community, but if we want other folks to use 
this, making it clear what needs to be agreed upon out-of-band seems 
important.<BR></FONT><BR>>>Section, item g -- this is a poorly 
worded summary of section<BR>>>  Recommend rewording to 
"Packet Length (0, 1, 2, or<BR>>4 octets) --<BR>>>See Figure 
4-2.<BR>><BR>>** Agreed. It will be changed to Packet Length (0, 1, 2, or 
4<BR>>octets). **<BR><BR><FONT 
color=#0000ff>Thanks</FONT>.<BR><BR>>>Section -- "The value 
'110'..." does this require a<BR>>RID against<BR>>>135.0-B-2 (or 
whatever)?<BR>><BR>>** The PID value '110" needs to be added to Space 
Link<BR>>Identifiers blue<BR>>book via a new pink sheet **<BR><BR><FONT 
color=#0000ff>OK, thanks. <BR></FONT><BR>>>Section -- "The 
extended protocol IDs..."  I didn't<BR>>see this in<BR>>>reference 
[8].  Does it require a RID?<BR>><BR>>** A new table called "Extended 
Protocol IDs" needs to be added to the<BR>>Space Link Identifiers blue book 
via the new pink sheet. **<BR><BR><FONT 
color=#0000ff>OK.<BR></FONT><BR>>>As a note to the secretariat, I'd 
suggest that we add an<BR>>Annex for red<BR>>>books that require 
modifications to other documents that consolidates<BR>>>and  
summarizes those external dependencies. ** I agree **<BR><BR><FONT 
color=#0000ff>Perhaps also another annex that summarizes the "managed 
parameters" that the protocol specifies that must be agreed among peers in order 
to ensure interoperability?<BR><BR>Thanks, and again, sorry for the 
delay.<BR><BR>Bob</FONT></FONT><FONT color=#0000ff> </FONT></P></BODY></HTML>