I strongly agree with the proposed change. Bill Atwood
On 15/05/2017 4:30 PM, Brian E Carpenter wrote: > 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 > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:[email protected] 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
