[Atp] Re: Mohamed Boucadair's Block on charter-ietf-atp-00-00: (with BLOCK and COMMENT)

[[e-mail]]

Hi Daniel, Orie,

Thank you for the follow-up. I also checked the various changes made in the PR. I really think that this is heading in a good direction.

Pease see inline as well.

Cheers,
Med

De : Daniel Holmgren <daniel=[e-mail]>
Envoyé : mercredi 14 janvier 2026 17:46
À : Orie <[e-mail]>
Cc : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]
Objet : Re: [Atp] Re: Mohamed Boucadair's Block on charter-ietf-atp-00-00: (with BLOCK and COMMENT)


Hi Med,

Thanks for the detailed review. Orie, thanks for hopping in with some suggestions.

Responses inline with DH>:

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Hi all,

Thanks for the effort to put this charter together.

Please find below some comments for discussion:

# Clarity: "Account", "streaming", and "network"

## There are parts of the charter text that I think need some clarification.
For example, it is not clear what "account" are being discussed here. I
understand that these accounts are not application-specific (given that "Any
social application semantics" is out of scope).

This can be fixed by first introducing the concept (and without assuming
familiarity with draft-holmgren-at-repository or the arch spec).

OS> I added a bit here: https://github.com/ietf-artarea/charters/pull/60/files#r2690431353
I'm not sure network or streaming need more motivation, I'll address streaming with your comment below.

DH: I added a sentence to the intro paragraph that introduces the notion of accounts: https://github.com/ietf-artarea/charters/pull/60/changes#r2691195196
[Med] Thanks


## Likewise, "streaming synchronization protocol" is listed as deliverable but
the narrative text does not introduce it. At least, I'm lacking context to
understand why the qualifier "streaming" is added here compared to simply
reason about "synchronization protocol".

OS> I welcome proponents to answer the "why streaming" question. My intuition is that in 2026, streaming is an expected feature of media distribution systems.

DH: The context is "data streaming" or "event streaming", but we are not wedded to "streaming" specifically. The important characteristic is low-latency/real-time synchronization. We can revise to "low-latency synchronization protocol".
[Med] ACK.


## What is meant by "network" here?

CURRENT:
  The network will give small independent participants global visibility and
  distribution without prior coordination

Also, how is that related to the "organizational boundaries" mentioned in the
following, for example:

CURRENT:
  The protocol enables synchronization of public data across organizational
  boundaries

 OS> This is actually well covered here: https://www.rfc-editor.org/rfc/rfc9518#section-2, I have proposed to strengthen the introduction a bit: https://github.com/ietf-artarea/charters/pull/60/files#r2690524760

DH: Orie, I like the strengthening of the intro. I also proposed an addition to the intro paragraph that I think further clarifies what is meant by "the network": https://github.com/ietf-artarea/charters/pull/60/changes#r2691199416.
[Med] Both changes are really an enhancement.



## What is a "network transport" in the context of ATP?

CURRENT:
 The streaming protocol should allow for alternative network transports

OS>  This is discussed in this draft: https://datatracker.ietf.org/doc/html/draft-newbold-at-architecture-00#section-4 ... I hesitate to define this in charter, what do you propose?

DH: This refers to transport-layer flexibility. The synchronization protocol should not be tightly coupled to a specific transport (e.g. could be implemented over WebSockets, HTTP/2 streams, QUIC, etc.). We can revise that line to "The synchronization protocol should allow for alternative transport layers". Is that more clear?
[Med] It is definitely!

One companion comment, given the support of multiple transports and the objective to provide a low-latency resolution, some transport selection may be needed, when several candidates are offered. You may at least list HAPPY WG (https://datatracker.ietf.org/wg/happy/about/) as an additional WG that can consult for transport selection matters.



# Manageablity and operation

RFC 2418 says the following:

      To facilitate evaluation of the intended work and to provide on-
      going guidance to the working group, the charter must describe the
      problem being solved and should discuss objectives and expected
      impact with respect to:

         - Architecture
         - Operations
         - Security
         - Network management
         - Scaling
         - Transition (where applicable)

The current charter includes requirements about scalability and backward
compatibility. However, and given that the "protocol enables synchronization of
public data across organizational boundaries", wouldn't, e.g. some mechanisms
be needed to verify and check correct operation across these boundaries? Other
OAM tasks may be needed as well.

Also, there might be additional operational considerations to "give small
independent participants global visibility and distribution without prior
coordination", etc.

I'm not asking to answer these now, but suggest to add a mention that
operational (including manageability and OAM in general) applicability will be
provided as part of the work.

OS> Given the charter text and the 2 drafts mentioned in the BoF
-  https://datatracker.ietf.org/doc/draft-newbold-at-architecture/
- https://datatracker.ietf.org/doc/bofreq-newbold-authenticated-transfer

Can you suggest some text, or give the proponents a pointer to a charter that does this well?
Off the top of my head, considering limitations on CPU, network or storage might impact the ability for some repositories to process certain content...
Choice of cryptographic algorithm or serialization may preclude some IoT use cases... Is this what you are looking for?

DH:  We're open to adding language here but would appreciate some guidance as to the level of detail expected for a repository/synchronization protocol.
Does it suffice to keep this vague, but gesture at operational considerations? Something like: "Document(s) describing operational considerations for deployment and interoperability testing."
[Med] Yes, adding that sentence would suffice. Thank you.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# I support the points raised by Andy.

# Business as usual

CURRENT:
 All existing work must undergo a consensus process

Per our process, any work (adoption) is subject to consensus. Is there any
reason why this mention is included here?

OS> I suggest to remove it: https://github.com/ietf-artarea/charters/pull/60/files#r2690500746

DH: Agreed, thanks.
[Med] ACK.


# Centralization considerations: is this about RFC 9518?

CURRENT:
  Privacy and Centralization considerations will be documented (eg, per RFC
  6973) and will inform design decisions.

Not sure which "Centralization considerations" you have in mind? If you are
referring to RFC 9518, then consider citing it.

OS> Great suggestion, I've done that here: https://github.com/ietf-artarea/charters/pull/60/files#r2690510106

DH: Agreed. RFC 9518 is what we had in mind.
[Med] ACK.


Cheers,
Med



_______________________________________________
Atp mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Atp mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.