Subject: Re: [NSIS] consensus probe on one aspect of NTLP operation

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 21 Feb 2003 10:55:10 +0100

| Well, you can always define that an implementation MUST 
| support transport protocol X and MAY support other 
| transport protocols, too. 

Agreed.

| "Transport protocol X" could be something (very) simple
| and probably unreliable.

Simplicity is always welcome. But unreliable signaling 
transport causes me a headache. Is there any experience
with other signaling protocols indicating that 
unreliable signaling transport is the best way of 
conveying this type of information? 

Regards, Rudiger
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Ping Pan <[email-masked]>
Date: Fri, 21 Feb 2003 16:48:54 -0800

> conveying this type of information? 

I think when people want to design a protocol initially, they don't want 
to be too bothered with message reliability issue. In many cases, they 
can get away with it, such as RTP/RTCP. Sometimes, what they have 
defined would eventually work, e.g., SNMP, OSPF etc. Sometimes, people 
just regret it. I wonder if SIP is a such example. :-)

As a developer, I certainly have not been happy with RSVP refreshes. We 
attempted to fix it once, and got it working. Then, one day, Henning 
challenged me about our work 5 years ago. At the end of the day, we 
thought if we had to do it all over again, TCP would be a better 
alternative.

The point here is that if we already know some design decisions are 
problematic, should we continue to follow the same design later on?

2 cents,

- Ping