Re: [Tsv-art] TSV Triage team: Review of IETF LC documents as of 10/11

[Mirja Kühlewind <[e-mail]>]

Hi Joe,

On 12.10.2017 15:25, Joe Touch wrote:
> 
> 
> On 10/12/2017 1:34 AM, Mirja Kühlewind wrote:
>> Hi Joe,
>>
>> not sure, what your actual request is to the triage team but they
>> usually don't assign tsv document for tsv-art review.
> I was responding to Martin's request, not making one of my own.Sorry I missed that request.

> 
>> Also your concern seems to be quite fundamentally about the approach
>> taken by the working group and it seems simply too late to change
>> anything about this now as the document(s) are in IETF last call.
> Any review - at any stage, for any reason - can bring up issues with the
> need for an approach and the utility of the approach provided.
Sure, you can bring up new issues but issues regarding the selection of this 
approach have been discussed before and I don't think it will be use useful 
to revisit that argument at this stage.

> 
>> However, let me provide you some more input as responsible AD and
>> previous chair. The TLS-based proposal was not rejected at all. There
>> was, however, not enough energy in the group to follow on with that
>> approach now,
> I disagree; what I saw were "votes" to pick *a* solution, not multiple
> ones. In particular, working on multiple solutions was deemed to
> undermine the goal of "we have one that everyone will use".

This was before I took over the group as chair. These (kind of weird) votes 
didn't lead to any conclusion. When I took over the group we adopted both 
proposals but the author of the TLS one later explained that he would not 
have the time commitment to follow on, so the group concentrated on 
finalizing the tcpcrypt approach.

> 
>> so the only option to finish up any time soon was to go with tcpcrypt.
>> However, the reason why there is tcpeno, is that this mechanism can
>> still be used to negotiate the use of TLS and the hope it that this
>> proposal will still be finished at some point of time. I personally
>> think that just having a negotiation mechanism in TCP for TLS could
>> provide a stronger incentive for adoption but as far as I can tell
>> there is currently anyway not a huge interest in deploying tcpinc
>> (probably also because QUIC could provide a alternative if you want an
>> encrypted transport).
> QUIC is basically TLS for UDP: https://www.chromium.org/quic
> In fact, the project claims to want to adopt TLS 1.3 in place of its
> interim approach.

QUIC as standardized in the IETF currently is using TLS1.1 (as explicitly 
stated in the charter I believe).
> 
> I don't know if ENO will support anything other than TCPCRYPT; it may be
> intended that way, but the jury is out exactly because nobody else is
> using it.

ENO explicitly was designed to to support other approaches, especially TLS. 
There was even a registration for the TLS in the ENO draft. I told the 
authors to remove that because that registration should be done by the TLS 
draft itself (if it every gets finished).

> 
>> I hope that addresses your concerns at least a bit.
> It doesn't.
> 
> I was giving my impression as context, but basically encouraging someone
> else from TRIAGE to volunteer to give these docs a pass. If that's not
> useful, perhaps you should let Martin know he didn't need to ask for that.
Sorry again, I missed that. I personally think we don't need further tsv 
reviews at this stage. But of course any additional review can help.

@Martin: David is the chair of the tcpinc group and shepherd of one of the 
drafts, so he has certainly reviewed it already :-)

Mirja


> 
> Joe
> 
>> Thanks for your feedback though! I really appreciate your (and some
>> others) efforts to have an eye on what's going on! Honestly thanks!
>>
>> Mirja
>>
>>
>>
>> On 12.10.2017 06:21, Joe Touch wrote:
>>> Hi Martin (et al.),
>>>
>>> I’ve (unfortunately) tracked TCPCRYPT and ENO since their
>>> introduction to the IETF. I remain unclear on what problem they’re
>>> trying to solve, other than to integrate TLS into the TCP 3WHS (an
>>> alternate, more direct approach along those lines by Eric R ?? was
>>> rejected, FWIW). It doesn’t protect the TCP layer at all.
>>>
>>> IMO, both would benefit from at least a cursory pass by fresh eyes,
>>> though. Besides, at this point I doubt anything I have to say hasn’t
>>> been said (and largely ignored) before.
>>>
>>> Joe
>>>
>>>> On Oct 11, 2017, at 1:07 AM, Martin Stiemerling <[e-mail]>
>>>> wrote:
>>>>
>>>> Dear TSVers,
>>>>
>>>> I did work through all documents that are in IETF LC, IESG
>>>> processing or being requested for publication as of 10/11, 10:00 am
>>>> CEST.
>>>>
>>>> Please find below all documents checked and what to do with these
>>>> documents.
>>>>
>>>> There are a two documents out of TCPINC that are important and
>>>> probably should be reviewed by the TSVART, if not somebody has
>>>> already reviewed those as part of the regular TCPINC WG review:
>>>> draft-ietf-tcpinc-tcpeno-10
>>>> draft-ietf-tcpinc-tcpcrypt-07
>>>>
>>>> Any volunteers or did someone out of the TSVART (David probably?)
>>>> any read it?
>>>>
>>>>
>>>> Documents that require TSV attention:
>>>> draft-ietf-i2nsf-framework-08 -- Martin
>>>> draft-ietf-dhc-relay-port-06 -- Jörg (changed, was assigned to Colin)
>>>> draft-ietf-sunset4-ipv6-ietf-01 -- Michael Tuexen
>>>> draft-ietf-nvo3-mcast-framework-10 -- Colin, as he did review -09
>>>> draft-ietf-mboned-interdomain-peering-bcp-11 -- Yoshifum (AD request
>>>> by Mirja)
>>>>
>>>>
>>>> Documents that do not require TSV attention:
>>>> draft-ietf-netconf-rfc6536bis-06
>>>> draft-ietf-lime-yang-connectionless-oam-methods-09
>>>> draft-ietf-lime-yang-connectionless-oam-11
>>>> draft-ietf-acme-acme-07
>>>> draft-schaad-curdle-oid-registry-02
>>>> draft-ietf-rmcat-scream-cc-11 -- TSV owned
>>>> draft-ietf-sidrops-bgpsec-rollover-02
>>>> draft-ietf-uta-email-deep-09
>>>> draft-ietf-ospf-segment-routing-extensions-19
>>>> draft-ietf-dnssd-hybrid-07
>>>> draft-ietf-anima-voucher-05
>>>> draft-ietf-anima-prefix-management-05
>>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>    Martin
>>>>
>>>> _______________________________________________
>>>> Tsv-art mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tsv-art
>>>
>>> _______________________________________________
>>> Tsv-art mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tsv-art
>>>
> 
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art
>