[Sip] RE: Hop limit diagnostics

[Sean Olson <[e-mail]>]

Yes, I think that would be appropriate.  I hate to throw out features/improvement just because they don't work over UDP.

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[e-mail]]
Sent: Thursday, July 12, 2007 6:23 AM
To: Sean Olson; [e-mail]
Subject: RE: Hop limit diagnostics

So to explore further.

If the final hop is TCP and a preceding hop is UDP, does it just get
thrown away at the transport protocol boundary in this solution.

Regards

Keith



> -----Original Message-----
> From: Sean Olson [mailto:[e-mail]]
> Sent: Wednesday, July 11, 2007 7:33 PM
> To: DRAGE, Keith (Keith); [e-mail]
> Subject: RE: Hop limit diagnostics
>
> Why not:
>
> D) Define a diagnostic information mechanism that works with
> TCP and accept that it will not work with UDP
>
>
>
> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[e-mail]]
> Sent: Wednesday, July 11, 2007 7:07 AM
> To: [e-mail]
> Subject: [Sip] Hop limit diagnostics
>
> (As WG chair)
>
> We have a couple of related milestones on our charter that we
> are stuck
> on:
>
> Jul 2007    Diagnostic Responses for SIP Errors to WGLC (PS)
> Nov 2007    Diagnostic Responses for SIP Errors to IESG (PS)
>
> The draft associated with this expired some way back, but you
> can find it at:
>
> http://tools.ietf.org/html/draft-ietf-sip-hop-limit-diagnostics-03
>
> The charter item is for a more general document that covers
> other error situations as well as hop limit issues.
>
> However the editor's hit the intractable problem in that any
> transport decision is made on the request on any particular
> hop, and if UDP is used on the request, it will also be used
> on the response on any particular hop. This was specified
> based on the assumption that any response would not be
> significantly larger than the request, but as soon as we
> start putting lots of useful diagnostic information in the
> response, this no longer applies.
>
> So we are now looking for the way forward. Options include:
>
> A)      It is not worth the extra cycles - delete the milestone.
>
> B)      Limit the diagnostic information (to say around 100
> bytes in the
> worst case). If so will it contain enough useful information
> to make it usable.
>
> C)      Solve the transport problem. And no, we do not have a debate
> here on deprecating UDP. We've been there and done that.
>
> Unless people can come up with something that looks
> achievable, the working group chairs are currently favouring A) above.
>
> Comments please.
>
>
> Keith
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip
>


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip