Subject: Re: [Insipid] draft-ietf-insipid-session-id-15: comments and questions

From: Brett Tate <[email-masked]>
Date: Tue, 27 Oct 2015 09:33:58 -0400

Hi,

Thanks for the response; reply is inline.

> >Section 2 paragraph 3: I'm not confident that I'm
> >interpreting the paragraph correctly.  If during
> >call setup a device that typically acts as a proxy
> >or B2BUA rejects the INVITE with a failure responses
> >(such as 407, 422, 403, 421, 400, et cetera) instead
> >of relaying the request, should it follow section 6
> >or section 7?  For instance within RFC 3665 section
> >3.2 F2, should the proxy follow section 6 or section
> >7 when sending the 407 response?  It was the final
> >hop for the request (and Alice might not try again
> >with Proxy-Authorization); however I'm not sure if
> >this paragraph/draft classifies the proxy as an
> >endpoint within this situation.  My current
> >interpretation is that the proxy follows section 7.
>
> I'm not sure which section you're referring to (but
> I'm sure it wasn't the terminology section).

Yes; I was referring to the conventions section.  The new paragraph attempts
to clarify the draft's use of endpoint and intermediary which impacts if a
device should follow section 6 or section 7.

> If a proxy rejects an INVITE with 407, it would
> follow Section 7 since it is not an endpoint.

I assume that was also your answer for "If during call setup a device that
typically acts as a proxy or B2BUA rejects the INVITE with a failure
responses (such as 407, 422, 403, 421, 400, et cetera) instead of relaying
the request, should it follow section 6 or section 7?"

Does this draft classify redirect servers as endpoints or intermediaries
(i.e. do they need to follow section 6 or 7)?  If it matters, some redirect
servers only generate 3xx or failure responses.  However, there are others
which may additionally act as a proxy or B2BUA within some situations.

> >Section 7 paragraph 4: You might want to explicitly
> >exclude 2xx from the mandate.  For instance, it looks
> >like the current wording could potentially apply to
> >"disaggregated media" which was a topic discussed in
> >March 2013.
>
> You're talking about the aggregated response section?
> I think we need to leave 2xx out of that.  I'm not
> sure how disagregated media fits into that.

"If the intermediary aggregates several responses from different
endpoints, as described in Section 16.7 of [RFC3261], the
intermediary MUST"

Since 2xx wasn't explicitly excluded from the above mandate, someone might
think that the MUST applies to the aggregation of 2xx responses for
"disaggregated media" situation.

However, leaving text as-is is good enough for me.

> >Section 7 paragraph 5: What is the relationship
> >of paragraph 5 to paragraphs 6 and 7?  For
> >instance, does the MUST within paragraph 5 cause
> >MAY within paragraphs 6 and 7 to become MUST for
> >such transferring intermediaries?
>
> Paragraph 5 places a requirement on PBXes --
> that's the main focus.  If they transfer a call,
> they need to properly convey Session-ID headers.

Paragraph 5 currently appears to apply to more than PBXs.  Thus I'm
attempting to understand the impacts in relation to some of the optional
things within section 7.

"Intermediary devices that transfer a call, such as by joining
together two different "call legs", MUST properly construct a
Session-ID header field that contains the correct UUID values and
correct placement of those values."

What does "MUST properly construct" mean?  For instance, does it mean that
the intermediary "MUST include a Session-ID header" or "MUST include correct
UUIDs if constructing Session-ID"?  Does it also mean that it can fix a
received Session-ID before relaying it?

If it means "MUST include a Session-ID header", when does the mandate apply
(during call setup or during the transfer process)?