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

[Daniel Holmgren <[e-mail]>]

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

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


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


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


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

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

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

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