<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<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> >> >>In section 2.2, it is unclear what the
conformance requirements<BR>>> >>are. There are two protocols
(Space Packet and<BR>>Encapsulation Packet)<BR>>> >>under a
single service interface. Are both required
for<BR>>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<BR>>service.**<BR>>><BR>>>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>><BR>><BR>>** An implementation is conformant if it
only implements one<BR>>of these two<BR>>protocols. I will modify the
document to say this explicitly. **<BR><BR><FONT face=Arial color=#0000ff>While
this is probably the pragmatic approach, the implication of this is that two
implementors can provide the same CCSDS service in a way that is not, and cannot
be configured to be, interoperable. I find this disturbing. This
possibility at least needs to be noted, and added to the list of
parameters that are managed among implementors. This seems like a rather
serious flaw to me. I would much rather see a requirement to implement
both and an option to use either on a per-mission basis. Failing that, I'd
like to see a Protocol Implementation Conformance Statement developed and made
mandatory, so that there is no ambiguity about what an implementor has
implemented.<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<BR>>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>>>OK. Does the Space Link Identifiers book have
such a section? My<BR>>>comment will be successfully resolved if
either of these<BR>>documents has a<BR>>>SANA
section.<BR>><BR>>** I will add it to the Space Link Identifiers book
**</FONT></P>
<DIV><FONT size=2><FONT face=Arial color=#0000ff>OK, thanks.</FONT></DIV>
<P>>> ><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<BR>>APIDs begin to<BR>>> >happen in these cases.
**<BR>>><BR>>>This explanation is helpful. I know that the
book is<BR>>normative, rather<BR>>>than informative, but it would be
nice to have this explained<BR>>in there.<BR>><BR>><BR>>** OK, I
will see if I can weave these explanation in without<BR>>being wordy **</P>
<P><FONT face=Arial color=#0000ff>Thanks.</FONT><BR></P>
<P>>> >>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<BR>>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<BR>>no further<BR>>> >restrictions except the ones managed by
the enterprise. Yes,<BR>>> >interoperability is an issue for the
management of those<BR>>apids. It is<BR>>> >intended that 2040-2044
be used for encapsulation by space<BR>>packets.
**<BR>>><BR>>>Could you please clarify these points in the
document?<BR>><BR>>** OK **</P>
<P><FONT face=Arial color=#0000ff>Thanks.</FONT></P>
<P>>>I think that it would be useful to summarize the "managed
parameters"<BR>>>somewhere, to make it clear specifically what
bilateral<BR>>agreements are<BR>>>required to ensure
interoperability. This may be part of the "lore"<BR>>>within the
CCSDS community, but if we want other folks to use<BR>>this,
making<BR>>>it clear what needs to be agreed upon out-of-band seems
important.</P>
<P><FONT face=Arial color=#0000ff>Didn't see any comment on this (but then, my
comment didn't require any). Any thoughts on an annex to summarize
these?</FONT></FONT></P></BODY></HTML>