Re: [Apn] Further revised draft Charter

[Donald Eastlake <[e-mail]>]

Hi Adrian,

On Wed, Jan 18, 2023 at 4:18 PM Adrian Farrel <[e-mail]> wrote:
>
> Thanks for doing that work, Donald.
>
> I’m not sure what the status of APN is now. It’s all been very quiet since Andrew’s email on the 20th of October. At that time he said “I will have having discussions with the proposed chairs and some of the proponents at 115 regarding the possible way forward from here and will advise in due course” so I guess we’ve been waiting to find out what the next steps are.
>
> But I think you’re right to resume the discussions and see whether we have momentum. I’d certainly like to see more clarity around the use cases (really, more simple statements of the problems that need to be solved), so hopefully this will come out of these discussions.
>
> I’m looking at your edited text with a view to seeing what might confuse or bother people coming at it from outside the routing and forwarding sphere…
>
> The initial couple of paragraphs talk about “services”. “Routing as a service” is something we might be familiar with, but, in general, when people talk about services they are thinking about services provided to traffic flows, to applications, or to users. Looking for an alternative word that might be less likely to cause confusion, I wondered about “treatments”.
>
> When you list “routing”, do you really mean “forwarding” or possibly “routing and forwarding”?

It seems to me that forwarding a packet to the next node in its path
is a service and selecting that node is routing. But I'm fine with
going for "routing and forwarding". And maybe with "treatments" to
avoid the false implication of application level services.

> I think that the paragraphs “The Appropriate Performance Networking (APNET) WG goal…” and “The APNET Field…” may be presenting the work in the wrong order. To me, the order of events seems to be…
>
> 1. Determine use cases where it would be advantageous to access additional information within the network to deliver services such as those listed
> 2.Build an information model to list all of the additional information needed
> 3. Write a framework for a common (abstract) data plane field/structure to carry this information and how it would be used

A use cases document is mentioned in the draft charter as something
the WG can adopt. But the charter does not have a milestone to push
the WG to submit it to the IESG for RFC publication. It is my
understanding that the consensus in the RTGWG was that the WG should
be narrowly focused on producing a framework document. See, for
example,
https://mailarchive.ietf.org/arch/msg/rtgwg/eJdAYu2EArziHsiT87UTaXqhtJw/

> 4. Determine whether some or all of the information can be carried in existing fields or encapsulations

Maybe the above could be included in the Charter document.

> 5. Depending on the outcome of 4., devise a common encoding for carrying the necessary information regardless of the data plane in use; and then…

This seems clearly outside a framework and thus, based on the RTGWG
consensus, should be out of scope for this Charter.

> 6. Specify encapsulations to carry the common encoding in different Internet data planes

Similarly, out of scope for this charter and, in any case, where there
exists another WG for the protocol to be extended, as there almost
always is, this would be work done there.

> Given the continued (legitimate) concerns about privacy (and to some extent, security), it would be a good idea to draw this out in an explicit paragraph. Something like…
>
> “Privacy and security are of increasing concern for Internet users and for the networks that carry the traffic. Encoding additional information within packets in order that the network can make informed decisions about how to handle the packets will necessarily expose that information to outside observers that may have malign intentions. It is, therefore, a fundamental part of the APNET WG’s work to carefully consider the risks introduced especially in regards to how packet flows and behaviors may be additionally visible to external observers.”

The use of the APNET Field inside an APNET network domain would not
generally expose it to "outside observers" unless all the traffic in
the domain was so exposed which I think is something that would rarely
happen rather than "necessarily" happen. But some more could be said
about privacy and security

> It may help to say why inter-domain is out of scope. Is it “…because the objective is the imposition and removal of APNET information at domain boundaries, and therefore inter-domain is out of scope. Further, assignment of meaning to APNET fields is a matter of local domain policy.”?

That sounds like a good idea.

> The middle out-of-scope bullet and an additional deliverable could, I believe be extended to cover items 4 and 5 in my list, above.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> Thanks for the work.
> Adrian
>
>
>
> From: Apn <[e-mail]> On Behalf Of Donald Eastlake
> Sent: 18 January 2023 02:04
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Apn] Further revised draft Charter
>
>
>
> I've gotten some comments and I've re-read some of the AD DISCUSSES and comments. Based on that I've updated the draft Charter as attached.  Comments are welcome.
>
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]