Hi Anima WG (only), We need to resolve this issue quickly, to get a new draft out in the next few days, before the IESG meeting next week.
So, since I haven't seen any opinions on the issue below, I propose to delete the UDP paragraph as suggested below. Note that this does not prevent us adding a UDP mode later, but it removes the confusion that we have in the text today. If you don't agree please send alternative text in the next 24 hours. (Also see: https://www.ietf.org/mail-archive/web/ops-dir/current/msg02653.html ) Regards Brian On 11/05/2017 00:34, Spencer Dawkins at IETF wrote: > Hi, Brian, > > On Tue, May 9, 2017 at 9:49 PM, Brian E Carpenter < > [email protected]> wrote: > >> Spencer, >> On 10/05/2017 05:13, Spencer Dawkins at IETF wrote: >> >> <snip> The bits where we can simply do what you suggest </snip> >> >>> Grrr, but please see below. >>> >>>> >>>>> >>>>> I'm really confused by this text. >>>>> >>>>> Nevertheless, when running within a secure ACP on reliable >>>>> infrastructure, UDP MAY be used for unicast messages not exceeding >>>>> the minimum IPv6 path MTU; however, TCP MUST be used for longer >>>>> messages. In other words, IPv6 fragmentation is avoided. If a node >>>>> receives a UDP message but the reply is too long, it MUST open a TCP >>>>> connection to the peer for the reply. Note that when the network is >>>>> under heavy load or in a fault condition, UDP might become >>>>> unreliable. Since this is when autonomic functions are most >>>>> necessary, automatic fallback to TCP MUST be implemented. The >>>>> simplest implementation is therefore to use only TCP. >> >> Editor hat off. >> >> I agree. I think it's very naive to think that for this application, >> intended to be used internally within an enterprise network, in >> a NAT-free and proxy-free addressing realm, UDP has any value. >> In fact, it's just a nuisance, since the programmer has to do a lot >> of the work that TCP does. The performance gain, even if it's real, >> is unimportant - autonomic traffic will be a tiny fraction of total >> traffic. There will be no gain in footprint, since autonomic nodes >> will carry full TCP stacks anyway. [If we wanted to put GRASP in >> constrained nodes, we'd probably be talking about GRASP-over-COAP >> anyway.] So here's what I would do: >> >> OLD >> All other GRASP messages are unicast and could in principle run over >> any transport protocol. An implementation MUST support use of TCP. >> It MAY support use of another transport protocol. However, GRASP >> itself does not provide for error detection or retransmission. Use >> of an unreliable transport protocol is therefore NOT RECOMMENDED. >> >> Nevertheless, when running within a secure ACP on reliable >> infrastructure, UDP MAY be used for unicast messages not exceeding >> the minimum IPv6 path MTU; however, TCP MUST be used for longer >> messages. In other words, IPv6 fragmentation is avoided. If a node >> receives a UDP message but the reply is too long, it MUST open a TCP >> connection to the peer for the reply. Note that when the network is >> under heavy load or in a fault condition, UDP might become >> unreliable. Since this is when autonomic functions are most >> necessary, automatic fallback to TCP MUST be implemented. The >> simplest implementation is therefore to use only TCP. >> >> NEW >> All other GRASP messages are unicast and could in principle run over >> any transport protocol. An implementation MUST support use of TCP. >> It MAY support use of another transport protocol, but the details >> are out of scope for this specification. However, GRASP itself does >> not provide for error detection or retransmission. Use of an >> unreliable transport protocol is therefore NOT RECOMMENDED. >> END NEW >> >> That doesn't slam the door, but it removes what I now feel is >> a very misleading paragraph. Of course, anybody is at liberty to >> draft a full description of GRASP-over-UDP as a separate >> document. >> >> Again, that was personal opinion. I won't edit that part of >> the draft without community input. >> > > Thanks, and I agree with not making changes unless there's community > agreement. > > I do suspect that if UDP is not at least NOT RECOMMENDED, some developers > may not use TCP at all. A quick Google search turned up e-mail from 2015 > asking "if we REALLY have to support TCP in our (micro-)DNS server", and > TCP to accommodate response TrunCation has been a requirement for DNS since > at least RFC 1035 in 1987. > > But I don't know the future, of course. :D > > Spencer > > >> Brian >> > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
