[Sls-slp] RE: Encapsulation Service

[Durst, Robert C.]

Greg et al,

Apologies for the late response.  Here are my thoughts on this:

>>APPROVE WITH CONDITIONS:  1 (33.33%) (Durst)
>>
>>In section 2.2, it is unclear what the conformance requirements
>>are.  There are two protocols (Space Packet and Encapsulation Packet)
>>under a single service interface.  Are both required for conformance?
>
>**Both protocols can be used to encapsulate other protocols.
>For example,
>CFDP can be encapsulated into space packets by using APID=2045
>or into an
>Encapsulation packet by using PID = '110'. I need to know more
>about what
>you are expecting in terms of "conformance requirements". The
>encapsulation
>service specifies the inputs, what protocols are used to do the
>encapsulating, and references the Space Link Identifiers
>document, which
>supplies all of the IDs one needs in order to carry out the service.**

The conformance requirements I am asking about are whether an
implementation is "conformant" if it only implements one of these
two protocols (SPP or Encapsulation Packet).  If so, please say so.
If not, please explain how you ensure interoperability between two
conformant applications that invoke this service (when, for example,
one is hosted on a node that implements SPP and the other is hosted
on a node that implements only Encapsulation). 

>>The document requires a SANA Implications section to address
>registered
>>APIDs and PIDs, and to define procedures to register new
>APIDs and PIDs.
>
>** All of the IDs used by the Encapsulation Service are defined in the
>Space Link Identifiers spec. This is true for all of the link layer
>protocols. Therefore, it is the Space Link Identifiers book
>that requires a
>SANA implication section, not Encap. service.  APIDs and PIDs
>are defined
>in the Space Link Identifiers book which is referenced in
>section 2.3 **

OK.  Does the Space Link Identifiers book have such a section?  My
comment will be successfully resolved if either of these documents has
a
SANA section.


>>The document requires a security implications section.
>
>** I will work with Howie on how to accomplish this **

OK.  When added, this comment will be resolved.

>>Section 3.3.2.2:  It is unclear to me whether and how a user of the
>>service is expected to know the correct GVCID and PVN to use.
> Are these
>>statically assigned?  Assigned on a per-mission basis?  What are the
>>implications on interoperability?
>
>** GVCID = SCID + VCID. SCID is statically assigned. VCID is
>an enterprise
>or project managed parameter. CCSDS recognizes certain PVNs.
>All of these
>IDs are defined and their values are listed (if not a managed
>parameter) in
>the Space Link Identifiers spec. For things like PVN it's very
>static. For
>APIDs, an enterprise has to really manage these across the
>enterprise in
>order for interoperability to happen. Global enterprise APIDs begin to
>happen in these cases. **

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.

>>Section 4.1, item b)  the APID "shall be one of the reserved APIDs"
>>defined in reference [8].  Are there guidelines or further
>restrictions on
>>how a particular APID is chosen?  Does interoperability
>depend on this
>>choice?  In Table 5-2 of reference [8], there appear to be
>two degrees of
>>"reserved" -- reserved and assigned to a particular protocol,
>and reserved
>>but unassigned.  Are any of these fair game?  Or was it intended that
>>these be drawn from the 2040-2044 range?
>
>** Again APIDs are a managed parameter by an enterprise except
>for the ones
>defined in the CCSDS Space Link Identifiers book. There are no further
>restrictions except the ones managed by the enterprise. Yes,
>interoperability is an issue for the management of those apids. It is
>intended that 2040-2044 be used for encapsulation by space packets. **

Could you please clarify these points in the document?

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.

>>Section 4.2.2.1, item g -- this is a poorly worded summary of section
>>4.2.2.8.  Recommend rewording to "Packet Length (0, 1, 2, or
>4 octets) --
>>See Figure 4-2.
>
>** Agreed. It will be changed to Packet Length (0, 1, 2, or 4
>octets). **

Thanks.

>>Section 4.2.2.3 -- "The value '110'..." does this require a
>RID against
>>135.0-B-2 (or whatever)?
>
>** The PID value '110" needs to be added to Space Link
>Identifiers blue
>book via a new pink sheet **

OK, thanks. 

>>Section 4.2.2.6 -- "The extended protocol IDs..."  I didn't
>see this in
>>reference [8].  Does it require a RID?
>
>** A new table called "Extended Protocol IDs" needs to be added to the
>Space Link Identifiers blue book via the new pink sheet. **

OK.

>>As a note to the secretariat, I'd suggest that we add an
>Annex for red
>>books that require modifications to other documents that consolidates
>>and  summarizes those external dependencies. ** I agree **

Perhaps also another annex that summarizes the "managed parameters"
that the protocol specifies that must be agreed among peers in order to
ensure interoperability?

Thanks, and again, sorry for the delay.

Bob 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20060419/9e8bf7b6/attachment.html>