Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

The reason for using syslog is because it is widely deployed by ISPs.

Not all the ISPs have other ways of collecting data.

So, it is a matter of simplicity towards deploying it, not looking for the "state of the art" measurement system.

What we can do is to provide instead of just syslog, support for IPPM systems and let the ISPs to choose what they have in their own network.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Tommy Pauly <tpauly@apple.com>
Fecha: viernes, 30 de noviembre de 2018, 0:01
Para: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
CC: "v6ops@ietf.org list" <v6ops@ietf.org>
Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs

    Even with non-customer traffic, is syslog really the state of the art for sending data back to servers? Do you want anyone and everyone to see this information?

    Regarding the active measurements themselves, I think the draft would benefit from referencing some of the RFCs and drafts from the IPPM Working Group. We have various documents on one-way and two-way active measurements (OWAMP/TWAMP). You can also take a look at some standard ways of reporting the metrics themselves, as described here: draft-ietf-ippm-initial-registry-08.

    Thanks,
    Tommy

    > On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> wrote:
    > 
    > Hi Mikael,
    > 
    > I got the impression that when I originally proposed this, syslog was a privacy issue because it is sending data from "customers traffic" from their own devices to the ISP.
    > 
    > But in the actual proposal, the data is NOT from any customer, neither identifying the customer at all.
    > 
    > So not sure to understand if we have failed to clearly describe the way we are measuring, or you'd in mind the previous document?
    > 
    > Regards,
    > Jordi
    > 
    > 
    > 
    > -----Mensaje original-----
    > De: v6ops <v6ops-bounces@ietf.org> en nombre de Mikael Abrahamsson <swmike@swm.pp.se>
    > Organización: People's Front Against WWW
    > Fecha: martes, 27 de noviembre de 2018, 12:45
    > Para: Ron Bonica <rbonica@juniper.net>
    > CC: "v6ops@ietf.org list" <v6ops@ietf.org>
    > Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs
    > 
    >    On Mon, 26 Nov 2018, Ron Bonica wrote:
    > 
    >> This week, please review and comment on 
    >> draft-xie-v6ops-network-happyeyeballs.
    > 
    >    I think it's a great idea to tell the operator about problems, that kind 
    >    of telemetry can really help in operating the network.
    > 
    >    However, the proposed method of doing it (syslog) and the information it 
    >    reports (IP addresses and domains the user is communicating with) has huge 
    >    privacy implications. Also you have no idea who might be grabbing this 
    >    information before it even makes it to the ISP).
    > 
    >    I think at a minimum there needs to be an encrypted and verified mechanism 
    >    (https perhaps?) for doing the reporting, so you know where the report 
    >    goes.
    > 
    >    I see three entities that have interest in this information, it's the ISP, 
    >    the operating system manufacturer, and the web site which is having 
    >    problems. If HE fails, I see very little harm (privacy) in telling the 
    >    website about it using the address family that actually did work. So that 
    >    could be included. For the device manufacturer, they have "send 
    >    diagnostics information to vendor", so here customers can opt in. For the 
    >    ISP, I have no idea. Here it might be better to define an API between the 
    >    device vendor and the ISP, so that the device vendor can report problems 
    >    seen, at an aggregate? I have personally been involved in getting 
    >    operational people from my employer talking to device vendors to figure 
    >    out what might be wrong, and automating this would be great.
    > 
    >    Also, the DNSSEC implications are glossed over grossly. We should take for 
    >    granted that end devices are running validating resolvers and handle that 
    >    use-case.
    > 
    >    So I'm supportive of the problem statement and it would help ISPs greatly 
    >    if they could get telemetry from end devices, I just have great concerns 
    >    over the method proposed in this draft.
    > 
    >    -- 
    >    Mikael Abrahamsson    email: swmike@swm.pp.se
    > 
    >    _______________________________________________
    >    v6ops mailing list
    >    v6ops@ietf.org
    >    https://www.ietf.org/mailman/listinfo/v6ops
    > 
    > 
    > 
    > 
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > http://www.theipv6company.com
    > The IPv6 Company
    > 
    > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
    > 
    > 
    > 
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://www.ietf.org/mailman/listinfo/v6ops

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.