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

[Orie <[e-mail]>]

Hi Med,

Thanks for your comments.

Proponents, please feel free to reply here and to the suggestions in GitHub.

Inline with OS>:


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


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


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


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

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


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


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


>
> Cheers,
> Med
>
>
>
> _______________________________________________
> Atp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>