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

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
charter-ietf-atp-00-00: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-atp/



----------------------------------------------------------------------
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).

## 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”.

## 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

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

CURRENT:
 The streaming protocol should allow for alternative network transports

# 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.


----------------------------------------------------------------------
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?

# 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.

Cheers,
Med