Subject: [straw] Coming up: WGLC for draft-ietf-straw-sip-traceroute-01.txt

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Oct 2013 09:08:42 +0000

(As co-chair)

Hi,

As you may have seen, a new version (-01) of the trace-route draft was submitted a few days ago. One major change was that the draft no longer uses a new response code (202), based on the list discussions.

The chairs believe that the draft is now ready for WGLC, and unless people have issues with that we intend to start the WGLC *after* the upcoming IETF meeting in Vancouver.

As always, we would like to ask for volunteers, committing to performing a WGLC review. Please contact the chairs if you would like to volunteer.

But, anyone is of course welcome to comment at any time - no need to wait until the WGLC has "officially" started :)

Please note that the IANA considering sections still says the following:

"This document makes no request of IANA yet - if a new parameter or
                field needs to be inserted when answering the INVITE, then it will
                be registered in IANA."

The text is a left-over from when we were still considering a new 202 response code etc. It will be corrected in the next version of the draft, as there now is no request of IANA.

Thanks!

Regards,

Christer & Victor

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 26 Oct 2013 17:37:00 -0400

You may consider these to be WGLC comments on this draft:

(I'm sorry not to be providing precise text changes for these comments. 
But I think they require some substantial rewriting, not just surgical 
edits.)

Section 3 and is sub-sections have some problems that derive from its 
evolution. Originally a new header, B2bua-Hops was used. We have since 
decided to use Max-Forwards instead. There is still a reference to 
B2bua-Hops in this section.

Also, while instructions for the receiving B2BUA are given, the 
instructions for the UAC are skimpy. I think something should say that 
it should first send the request with Max-Forwards:0, and then increment 
it one by one until it gets an error unrelated to the Max-Forwards, or a 
success that doesn't have the special reason code. And during that 
process it may get 483 responses (from proxies or B2BUAs that don't 
support this mechanism) and must ignore those.

Section 3.2 is confusing to be in the way it conflates B2BUA and UAS. 
ISTM this section should distinguish between a device that judges itself 
to be the intended destination of the request, and one that judges 
itself to be a B2BUA intermediary. If it is the intended destination, 
then it acts normally, without regard to Max-Forwards. If it judges 
itself to be an intermediary, then it checks Max-Forwards. If its zero 
then either it answers 483, or else it responds 200 with the special 
Reason and sets up the loopback.

Also in 3.2, note that:

    When the final UAS answers a loopback-based INVITE with a Max-
    Forwards greater than 0, the Reason header would not be added to the
    response and the UAC will know the traceroute is complete.

is off by one. It should say "greater than or equal to 0". But 
addressing my other comments will probably cause it to be rewritten anyway.

Since we decided not to do the 205 response, the Reason header becomes 
key. I'm a little uncomfortable with specifying that we use reason 483 
with a *specific* reason-text value. I think we either say the 483 
reason means this regardless of the reason-text, or else register a new 
reason code for this. (But registering a new reason code seems like 
overkill.)

	Thanks,
	Paul

On 10/24/13 5:08 AM, Christer Holmberg wrote:
> (As co-chair)
>
> Hi,
>
> As you may have seen, a new version (-01) of the trace-route draft was
> submitted a few days ago. One major change was that the draft no longer
> uses a new response code (202), based on the list discussions.
>
> The chairs believe that the draft is now ready for WGLC, and unless
> people have issues with that we intend to start the WGLC **after** the
> upcoming IETF meeting in Vancouver.
>
> As always, we would like to ask for volunteers, committing to performing
> a WGLC review. Please contact the chairs if you would like to volunteer.
>
> But, anyone is of course welcome to comment at any time – no need to
> wait until the WGLC has “officially” started :)
>
> “This document makes no request of IANA yet - if a new parameter or
>
>                  be registered in IANA.”
> The text is a left-over from when we were still considering a new 202
> response code etc. It will be corrected in the next version of the
> draft, as there now is no request of IANA.
>
> Thanks!
>
> Regards,
>
> Christer & Victor
>
>
>
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw
>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 27 Oct 2013 09:44:12 +0000

Hi Paul,

Thank You very much for your comments!

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <[email-masked]> wrote:

Also in 3.2, note that:

        Thanks,
        Paul

---

From: Brett Tate <[email-masked]>
Date: Mon, 28 Oct 2013 18:30:08 +0000

> Section 3 and is sub-sections have some problems 
> that derive from its evolution. Originally a new 
> header, B2bua-Hops was used. We have since decided 
> to use Max-Forwards instead. There is still a 
> reference to B2bua-Hops in this section.

Yes; I provided the same comment off list on 6/19.

> Since we decided not to do the 205 response, the 
> Reason header becomes key. I'm a little uncomfortable 
> with specifying that we use reason 483 with a 
> *specific* reason-text value. I think we either 
> say the 483 reason means this regardless of the 
> reason-text, or else register a new reason code 
> for this. (But registering a new reason code seems 
> like overkill.)

I agree that requiring the specific reason-text value might not desirable.  This is because I view the text parameter to be similar to the status-line's reason-phrase.  If something is needed instead of just 483 for automation reasons, the reason-params potentially could be expanded to include a new parameter such as "traceroute".

The following is an RFC 3261 section 7.2 snippet.

"The Status-Code is a 3-digit integer result code that indicates the
 outcome of an attempt to understand and satisfy a request.  The
 Reason-Phrase is intended to give a short textual description of the
 Status-Code.  The Status-Code is intended for use by automata,
 whereas the Reason-Phrase is intended for the human user.  A client
 is not required to examine or display the Reason-Phrase."