Update on BAG OGC Community Standard Process

[selimnairb]

OGC OAB met on 2025-02-04 to decide whether to recommend BAG OGC Community Standard to the OGC Technical Committee (TC) for adoption. The OAB voted to do so.

Below are abbreviated notes from the meeting. Updates on the BAG OGC Community Standard adoption process will be given at ONSWG-US-HYDRO-25.

2025-02-04: OAB meeting

• BAG as community standard
  • Greg Buehler, chair
• Discussion
  • Questions
    • Joan Maso (CREAF)
      • Seems like a best-practice for how to use HDF to store bathymetry information, with a little bit of ISO metadata
        • What's the value of having this as a community standard rather than an OGC best practice?
          • Scott: We do have a community practice document type, something like BAG is more akin for something like LAS for storing point-cloud
          • Calder: Because of the extra components (e.g., the DSA scheme), it's more than just an HDF5 implementation, and therefore should probably be a community standard rather than best practice. It's also true that HDF5 is just one encoding; it would in theory be possible to encode in different forms.
    • Frank
      • Digital signature part of the specification
        • It's nice to have the opportunity to sign data
        • Hasn't been changed since 2006, but it's quite liberal in allowing you to pick signature standard
        • What bothers me is total byte size for signature block, is this enough for modern keys?
          • Current DSA, RSA signatures would already take up entire block
          • With larger key sizes this would not be big enough
      • Calder: The signature block size was set for FIPS DSA, which has a fixed key size, and the expectation is only to have a single signature (the most recent one) since the purpose is to demonstrate the latest authorisation for use. So the key block should be large enough for now. However, since acceptable sizes for keys do increase with time, it's probably not a bad idea to increase the block size. The flexibility in algorithm choice was due to lack of preference at the time of design, and a recognition that each agency might need to do its own implementation. With an IHO S-100 DSA algorithm being developed, this might no longer be the case, but that still needs to be determined.
      • In acronyms it lists RSA, but RSA is never used. Calder: That's an easy fix.
    • Keith Ryden
      • How stable is the BAG format specification? Are there any plans for major/minor changes in the next 12-36 months that would have implications for the potential deviation of BAG today vrs BAG in the future if OGC adopted this as a community standard? Calder: It's remarkably stable, even over 22 years. No major changes expected in the next 2-3 years.
      • Encryption of the data would be a red flag due to export controls, digital signature is okay
        • This is a carve-out
        • Calder: Encryption is not expected to be added, although IHO does have a scheme for encryption, primarily for Digital Rights Management, for S-100 standards. The main concern for the WG is the libraries that we use for the reference implementation, which are typically full encryption libraries. This isn't a concern for the community standard, however.
    • Joan Maso
      • There are 44 mentions in the document of the library. Usually OGC standards should not mention implementations, they are implementation neutral. How flexible can community standards be with regard to this?
        • Must ensure that we are not favoring any particular implementation
        • Keith's retort:
          • Having proof of implementation is part of the Community Standard requirement. I think it's just a question of how the reference implementations are mentioned in the document - having them is very important.
        • Calder: There is reason to prefer the reference implementation, since it correctly interprets the data through additional business logic (which might not be the case if you just use a generic HDF5 library to read the file). However, changing the FSD to say "reference implementation" rather than library would be relatively simple. This is mostly a reflection of the development process where the FSD and the implementation grew up together.
    • Keith Ryden
      • Is this the proper repo? hydroffice/hyo2_bag
        • Did not like the LGPL license
      • Calder: No. It's here: https://github.com/OpenNavigationSurface/BAG. Reference implementation has BSD 3-clause license.
  • Vote
    • Moved and seconded; passed nem. con.
    • Will be moved on to TC public comment
  • TODO
    • Remove RSA from acronyms since it isn't used
    • Refer to library as a reference implementation
    • Scott will follow up with next steps for public comment period.

[giumas]

In relation to:

Keith Ryden
Is this the proper repo? hydroffice/hyo2_bag

I have added a note in hyo2_bag to avoid future confusion: