Authenticated Transfer
charter-ietf-atp-01

[Ballot comment]
Hi,

Thanks for the continuous work on this charter. This looks good to me modulo the point below:

What is the purpose/motivation for this new mention: ", and not be overly fit to the current WebSocket transport layer"

Cheers,
Med

[Ballot comment]
“The network comprises independent hosts and other participants that synchronize public data across organizational boundaries, while preserving authenticity of content and attribution to the accounts that published the content.”

-- If there are “independent hosts” in the architecture, are there different types of “hosts”?  What does “independent” imply, constraint, or add?  Is it independent from something, maybe themselves?

-- What/who is an “other participants” that isn’t a host?  Is that a user/actor? Humans?

“The network will give small independent participants global visibility and distribution without prior coordination, and will not depend on the existence of any single privileged entity.”

-- Same as above.

-- What makes something "small" or "independent"?

“Account migration between network locations (eg, hosting providers) does not break references or graph relationships”

-- No existence of “references or graph relationships” in prior text. draft-holmgren-at-repository mentions graphs once in Section 2.2.

"The working group will specify interface requirements and selection criteria for account identifier systems."
-- What is an "interface requirement"? Is this an API definition?
-- On "selection criteria", is this about deciding between the current identifier systems and future identifier systems?
-- What actor is using this interface?

[Ballot block]
** Per:
“The working group will specify interface requirements and selection criteria for account identifier systems.”

“Document(s) describing interface requirements and selection criteria for account identifier resolution systems, and defining a public registry and update process for recommending specific account identifier resolution systems”

-- “interface requirements” between what components?

-- where does the criteria to inform the selection criteria originate?  Is that a WG item?  Is this task about describing when/where a particular account identifier resolution system might work? 

-- how is this work going to be done if the WG isn’t defining any account identifier resolution systems?

** “The synchronization protocol should allow for alternative transport layers”

-- Alternative to what?  What is the base transport layer?

[Ballot comment]
In my review, the charter text seems to assume architectural context not explicitly documented.  Fully appreciating that an architecture can't be documented in the charter and the text should focus only on what is needed to properly scope the work, below is a list of text which raised questions for me:

“An account represents a user or actor's identity, can migrate between hosting locations over time, and is identified by a persistent globally-resolvable account identifier.”

-- What is the distinction between a user and an actor?  If there is no distinction, why doesn’t the text read “user or user’s identity” or “actor and actor’s identity”?

-- Is a “hosting location” the same as a “network location” (which is used in the “key goals for the ATP are” section)

“The network comprises independent hosts and other participants that synchronize public data across organizational boundaries, while preserving authenticity of content and attribution to the accounts that published the content.”

-- If there are “independent hosts” in the architecture, are there different types of “hosts”?  What does “independent” imply, constraint, or add?  Is it independent from something, maybe themselves?

-- What/who is an “other participants” that isn’t a host?  Is that a user/actor? Humans?

“The network will give small independent participants global visibility and distribution without prior coordination, and will not depend on the existence of any single privileged entity.”

-- Same as above. Is a “participant" someone with an account? User?

-- What does “small independent” add to “participants”?  Does it constrain or define the notional architecture/charter scope?  Are there "participants" who are not "small" or "independent"?

-- “Global visibility” into what?

-- "Distribution" of what?

-- is that "privileged entity" a host or a participant (the only architecture elements defined in the text to date)?

“The working group will focus on a general purpose data repository structure for public user data records, and mechanisms for synchronizing repositories across the network.”

-- What’s a “public user data record”?

-- What use is this repository format in the goal of “enabl[ing] [the] creation of decentralized global networks for publication of self-certifying data.”?

“Repositories are cryptographically verifiable and publicly published.”

-- Cryptographically verifiable by “participants”?

“Cryptographic verification of repository signatures requires a system for resolving account identifiers to public signing keys.”

-- What’s the underlying security property here?

-- Repositories have multiple signatures?  How are those related to accounts?

“Account identifiers are also used to resolve the current hosting location.”

-- Is a “hosting location” the same as a “network location” (which is used in the “key goals for the ATP are” section)

“Account migration between network locations (eg, hosting providers) does not break references or graph relationships”

-- No existence of “references or graph relationships” is a newly introduced construct.

[Ballot comment]
Hi all,

The latest version [1] addresses all the comments raised my previous ballot [2].

Thank you Orie and Daniel for taking care of the comments.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-atp%2Fwithmilestones-00-00.txt&url2=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fcharter-ietf-atp%2Fwithmilestones-00-01.txt&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/atp/VUs9ZPxdU4dwAAqB2NuWVz6XeOE/

[Ballot comment]
I see this WG being called "Authenticated Transfer WG" and " Authenticated Transfer Protocol WG" - pick one :)

What is so special here that a new streaming/syncing protocol needs to be developed? I mean, Kafka is pretty common. Or DNS XFR? Or rsync ? or generic database replication ?

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

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

[Ballot block]
Please keep in mind that a BLOCK is the same as a DISCUSS on a document. In other words, this is about discussing changes to the charter text and not a firm block of the charter.

## Item 1

Text:
"All existing work must undergo a consensus process, and changes may be necessary, but gratuitous changes will be avoided when possible."

The word "gratuitous" is too subjective. Is the intent to say "non-breaking"?

## Item 2

"A public registry and update process for recommending specific account identifier resolution systems"

The working group doesn't setup the registry, IANA does. This deliverable should be a document defining the public registry and how it is managed using the guidelines of RFC 8126.

Added charter milestone "Adopt an informational draft describing interface requirements and selection criteria for account identifier resolution systems, and defining a public registry and update process for recommending specific account identifier resolution systems"