The AIP consists of all (cloud-based) LTA service elements which are necessary to implement the LTA ICD. Behind this, the LTA may consist of other elements taking care of safe preservation. Since these are not relevant for the ICD, and not depicted/described here, this architecture should only refer to the AIP, not the full LTA. (see also Jolyons comment)

This applies also to many requirement definitions in section 3, "LTA instance" → "AIP instance"

Diagram updated.

Do we change "LTA client" to "AIP client" too ?

The .zmetadata file is a non-standard extension to the Zarr v2 specification made by EOPF and might by subject to change when EOPF adopts Zarr v3. Whats the relevance of mentioning it in this ICD anyway?

It's the same in PRIP ICD. I propose to keep it like this to ensure consistency

Since a EOPF Zarr store can contain thousands of files this would be very inefficient. Instead, an on-the-fly zipper approach should be considered.

JM: This will change with Zarr V3 and the sharding opportunities.  I would tend to resist the on-the-fly zipper approach as an un-necessary complication (but still for discussion)

The table does not contain all entities of the LTA Data Model, and some are named differently.

can you precise : 

missing entities : order, JobStatus ?
named differently : Product attributes ?

This diagram is misleading. The data model of the LTA service is defined by the STAC Core model and the STAC extensions listed as applicable at the
beginning of this document.

The diagram at the begining of the document is a general STAC diagram (with both parts API and Core).

The Data model in page 17 details the structure of a AIP/LTA product in the meaning of STAC. It's the same as for PRIP ICS 

What is meant with "production additional data"? Maybe provide an example here.

The Order STAC extension seems not adequate to describe the product online/offline status in the AIP. The "order:status" represents the status of an order linked to a product. There could also be multiple orders in parallel for the same product.

Instead, consider

• adding a dedicated boolean property e.g. "online" to the "Product" extension or similar
• remove all order related properties from the STAC item since they can be retrieved at the Processes API

3.2.4 / p.28

STAC-LTA-ITEM-REQ-0065

Differing meaning of $.properties.order:date

Meaning of $.properties.order:date differs from what´s defined in the table on page 24.

Also, is $.properties.order:date relevant information for a user interested in a product or is it sufficient for a user to know if a product is online or offline? Note that the time when an offline item has been ordered is already part of the order itself.

The STAC specification states: "The ID should be unique within the Collection that contains the Items". It follows that even if uniqueness within a collection is enforced (which is strongly recommended), it is not guaranteed across collections, which poses a problem when an order references a product, see comment to OGC-AIP-PRO-REQ-030. It should thus explicitly be stated in the LTA ICD that $.id MUST be unique across all collections and implementations MUST prevent the creation of STAC items with the same ID in mutliple collections.

Please clarify the difference between $.properties.eopf:origin_datetime and $.properties.created from STAC Common Metadata. If there is no difference, should "created" be used instead of "eopf:origin_datetime"?

The timestamps extension specifies "published", "expires" and "unpublished" properties. Please clarify the exact semantics of this properties in the context of the LTA service e.g.

• What is the use case for "published" and "unpublished"?
• What happens to "expires" when the product goes Offline?

In general, please define which and how timestamps should be set/updated when

• a product is added to the LTA service in Online or Offline status
• the product changes its state from Online to Offline and vice versa.

Please clarify how $.properties.platform relates to platformShortName and platformSerialIdentifier defined in the OData interface. This will have an impact on e.g. metrics.

STAC- LTA-ITEM-REQ-0070

STAC- LTA-ITEM-REQ-0087

Should all assets be included in the STAC item or only the "product" asset (i.e. link to Zarr product, because all other assets can be determined by harnessing the Zarr layout)? What's the use case behind an archive service to provide individual or group of bands of the product as assets? Since the EOPF format specifies no assets at all, the assets to expose should be driven by the use case of the LTA clients.

Have the fields $.assets.<asset_name>.file:size and $.assets.<asset_name>.file:checksum been omitted deliberately?

The requirement states that "mission" should be part of the bucket name. Where does the mission come from? It is not part of the required properties of an item as listed in STAC-LTA-ITEM-REQ-0050. Maybe use the collection id in the bucket name instead or include mission in the item from STAC Common Metadata.

Are there any plans to include a thumbnail in the EOPF product?

Some remarks:

1. Setting "order:status" to "succeeded" seems incorrect if no order has been processed yet.

2. Shouldn't it be possible to create orders even in "shipping" and "succeeded" status? More generally, shouldn't it be allowed that different users create orders for the same product? This approach provides several benefits, e.g. users can cancel their orders without affecting other users, $.properties.expires may be updated if a new order is created to reflect the new user's expiration requirements, users may get individually notified upon order completion etc.

Also see comment "order status versus product status".

Please specify, how the assets href should be set for an Offline product. We see two possibilities:

1. same as for the Online product, leaving the client to handle the 404 in case it wants to download
2. setting the href property to null, explicitly indicating that the product cannot be downloaded and needs to be ordered 

Is it really required for a client to be authenticated for the discovery operations (search and browse)? Usually, only retrieval and ordering are subject to authentication/authorization.

Where are these quotas defined? Since the IAM is going to be centralized, are they also going to be defined there e.g. with OPA?

1. It is unclear what kind of checksum feature of the S3 infrastructure shall be leveraged. There are several options:
a) The S3 client does not provide a checksum to the S3 SDK: In this case, the S3 SDK computes a checksum when uploading the file. The checksum algorithm may be specified by the S3 client. This checksum feature also supports multipart uploads, so the limitation to singe part uploads seems unjustified.
b) The S3 client provides a checksum to the S3 SDK: Multipart uploads are only supported for checksum algorithms supporting full object checksums (see https://docs.aws.amazon.com/AmazonS3/latest/userguide/checking-object-integrity.html).
2. Currently no checksum is defined in the assets, so 1. a) is more likely.
3. The maximum size of a single part is 5GB. Therefore, if it cannot be guaranteed (also for the future) that an individual asset of a Zarr product is less than 5GB, multipart uploads must be allowed.

Does "stac_extensions" contain the same values for all STAC items? This may be important for implementations in order to prevent storing redundant information.

A FeatureCollections contains "numberMatched". We propose to state in the ICD that this may be an approximation and does not need to reflect the exact number of matched STAC items. Otherwise, query performance may be negatively affected.

IDs are not named consistently, e.g. "productOrder" and "BulkCreate" and in OGC-AIP-PRO-REQ-060, it says "bulkCreate". We recommend consistent naming, e.g. "ProductOrder", "BulkOrder" and "BatchOrder".

Note that even if not allowed for a user to cancel an order, it should at least be allowed for an operator. Furthermore, can the status names of the OData interface be retained? Also note that the status names differ from the ones in OData and also $.properties.order:status, e.g. we have "completed" (OData), "succeeded" (STAC item), "successful" (OGC) or "in_progress" (OData), "shipping" (STAC item), "running" (OGC). This only contributes to confusion so we strongly advise to harmonize and abandon the STAC order extension. Why is the OGC Processing API used in the first place? What are the limitations of the currently used Order API?

See also comment to $.id, otherwise "productId" is not guaranteed to be unique. Of course, a collection could be stored alongside "productId", but this is discouraged.

In the example in section 3.5.1.3 (Example of process description) the spelling does neither reflect the spelling in this requirement nor is it consistent (e.g. "productLink" vs "EvictionDate"). It is strongly advised to be consistent in attribute naming.

Please clarify what happens if some products could be ordered successfully and some products failed.

The access to a product after successful order differs from the specification in section 3.3.1. It is especially unclear to which assets/files the "productLink" in the job result output would point to, since the orderable unit is always the full product.

The "productLink" could better point to a STAC item to which the access can occur as defined in section 3.3.1.

The "evictionDate" seems semantically the same as $.properties.expires of the corresponding STAC item. Please specify that after a successful order the expires attribute of the item must be updated accordingly. In this case it should also be considered to remove the "evictionDate" from the process output to avoid duplication of information.

Suggest to also add collections and datetime as explicit parameters, like in STAC item search with simple filtering (https://api.stacspec.org/v1.0.0/item-search/#tag/Item-Search/operation/getItemSearch)

Align process inputs with OGC-AIP-PRO-REQ-070