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

From: Brett Tate <[email-masked]>
Date: Wed, 7 Oct 2015 09:29:33 -0400

Hi,

The following are some comments and questions concerning
draft-ietf-insipid-session-id-15.

Additional comments/questions were sent on October 2 as part of
draft-ietf-insipid-session-id-14 discussion.

http://www.ietf.org/mail-archive/web/insipid/current/msg01069.html

Thanks,
Brett

------

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.

Section 2 paragraph 3: If it matters, there are devices which can behave
as both endpoints and intermediaries from the perspective of this
paragraph/draft.  There are situations where a request will need to be
processed without complete information to know if section 6 or section 7
should apply.  This can occur when receive a request for unknown dialog.
I guess that the implementer will decide if better to follow section 6 or
section 7 within such situations.

Section 5 paragraph 6: Concerning "that send provisional responses" within
the last sentence, "provisional" can be removed (or become "provisional
and other") since not limited to provisional responses.

Section 6 paragraph 4: Within sentence 1, 5xx is potentially missing from
"3xx and 4xx" discussion.

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.

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?

Section 7 paragraph 9: "of am endpoint" should be "of an endpoint".

Section 7 paragraph 10" "previous two paragraph" should be "previous two
paragraphs".

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 19 Oct 2015 16:01:34 +0000

Brett,

>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).

If a proxy rejects an INVITE with 407, it would follow Section 7 since 
it is not an endpoint.  It has a few choices.  If it does not implement 
this spec, it just returns 407 without a Session-ID header.  If it 
implements this spec, it would return {N,A}.  And it's finished.   It 
may then clear state (aside from holding onto the message to respond to 
retries.)

>section 7 within such situations.

Yeah, I don't know.  If it's acting like an endpoint, then it should 
behave as one.  Otherwise, it sounds like it might be like a 3PCC 
device, which we also cover.  That's one example that acts like both.  I 
guess it's useful to think about the intent of the spec in spirit, which 
is to convey an end-to-end identifier primarily for the purposes of 
diagnostics.  One should not run billing of of this, but there should be 
an aim to ensure the right values are there to help track problems with 
calls.

>and other") since not limited to provisional responses.

Correct.  I'll make that change.

>"3xx and 4xx" discussion.

Actually, I question why we put 4xx there.  The whole point of that text 
is to deal with redirection or initiation of a subsequent call after the 
first call failed.  I think we should remove 4xx from that paragraph.  
UUIDs are still maintained betwen INVITE/4xx/INVITE, but that is not 
what that paragraph is about.

>potentially apply to "disaggregated media" which was a topic discussed 

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.

>MAY within paragraphs 6 and 7 to become MUST for such transferring

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 6 is totally unrelated.  If an SBC gets an INVITE from an 
endpoint without a Session-ID header, it *may* fabricate one for the 
endpoint.  It's not obligated.  If it does, then it needs to 
consistently convey it.

Paragraph  7 appears to be redundant with paragraph 6, but it has 
language about  the B2BUA acting like an endpoint.  Let me work to merge 
these two.

>Section 7 paragraph 9: "of am endpoint" should be "of an endpoint".

Thanks!

>Section 7 paragraph 10" "previous two paragraph" should be "previous 

Thanks!

I'll try to get a new draft out before the deadline.

Paul