[ + spud list ]
> On 2. jul. 2015, at 22.07, Black, David <[email protected]> wrote: > >>>>> cases where the latter doesn't happen. >>>> >>>> Got it now, sorry for the confusion. >>>> So I don't really care much about the middlebox behind a NAT on the other >> side - it's *my* side I care about. The usage examples in the draft refer to >> talking people in my institution or at the airport where I'm sitting. I don't >> expect to be (or care about being) able to talk to a middlebox far, far >> away... chances are, the message is dropped long before anyway. >>> >>> It's a limitation; it might be useful to explain the limitation and why >>> the remainder is still useful. >> >> ok > > And specify boundaries at which these text messages SHOULD be dropped because > they are likely to be irrelevant beyond that point. For the airport or > university example, this may be where the airport or university network hands > off to the ISP that provides connectivity to the Internet. ok > I also concur with Joel's and Diego's observation that an operator with > strongly > structured procedures (e.g., ticketing system) is going to have some > difficulty > dealing with this sort of problem report, especially as it's unauthenticated - > the fact that one can get an ICMP packet into the operator's network does not > automatically entitle one to draw upon the operator's support resources. This was also said by Diego Lopez - such operators may just not be a suitable target for this type of message (rather, smaller ones, then). But "entitle to draw upon the resources" is a bit exaggerated when we're talking about sending an ascii message. Nobody's obliged to listen to it, after all. Anyway, I have to say I'm getting some very good feedback here - in particular, I like Dan Wing's observation (on the spud list) that applications could auto-generate this (e.g. "Tried QUIC but failed UDP, falling back to TCP"); he suggested a machine-parsable format but now I wonder how to do this? All of a sudden, this seems to become more reasonable and make more sense than I ever expected :-) Thanks! Michael _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
