Subject: [dispatch] Updated STRAW Charter v2

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Mar 2012 07:32:59 +0000

Howdy,
Updated charter below...

Description of STRAW Working Group
====================================
Name: Sip Traversal Required for Applications to Work (STRAW)

Problem Statement: 
Within the context of the SIP protocol and architecture, a Back-to-Back User Agent (B2BUA) is any SIP device in the logical path between two User Agents performing a role beyond that of a Proxy as defined in RFC 3261.  The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order to terminate dead sessions by generating BYEs; or it may be a 3PCC-style agent only modifying SDP; or it may be a Session Border Controller performing such functions as in RFC 5853; or it may be an Enterprise PBX terminating REFERs and such; or it may be a complete UAS and UAC implementation with a PRI loopback in-between. 

In its most extreme form, the scope of the SIP protocol ends at the UAS of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In practice, however, users expect some SIP protocol aspects to go beyond the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA was not an end unto itself; this is similar to the expectation that emails work when they cross from POP and IMAP to/from SMTP.

It is impossible to normatively define all the behaviors of B2BUAs in general, or even subsets of them such as SBCs or PBXs. Unlike consumer NATs, B2BUAs perform widely varying functions for purposes which may be unique to their environment, unique to their architecture, or unique to the wishes of their administrator.  Instead of defining all things a given type of B2BUA must do, a more practical objective would be to define what very few things any B2BUA must do to make a specific SIP mechanism work, and let the market decide whether to do those things.

The name of this working group reflects that practical objective: if there were a thin straw between the SIP UAS and UAC of a B2BUA, what must be passed through that straw and used on each side.  Or viewed another way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and if we could extend ISDN, what information would we carry in ISDN across the PRI for a specific SIP mechanism to work end-to-end.

For example, the WG could produce a document which specifies that the Max-Forwards header field value should be copied and decremented across the B2BUA, if the B2BUA wishes to prevent infinite loops.  Administrators could then tell their B2BUA vendors to comply with the document, if the administrator so wishes.

Objectives:
The objectives of the STRAW Working Group are to publish normative documents which define which SIP header fields, parameters, MIME bodies, body content fields/information, or media-plane characteristics are required to traverse between the User Agent "sides" of a B2BUA for specific functions to work.  

The specific functions covered are expected to relate to already-published RFCs or existing RAI area work, as opposed to all future IETF work.  In other words, the Working Group is not meant to be a never-ending source for B2BUA requirements in the RAI area.

Deliverables would indicate which types of B2BUAs would apply or not.  For example, a document defining the requirements for end-to-end DTLS-SRTP would not apply to B2BUAs which terminate media, such as transcoders or recorders.

Initial Deliverables:
1) A taxonomy document defining role-types of B2BUAs, as a reference for other deliverables.
2) A framework document for defining requirements and considerations for traversing B2BUAs.
3) A document defining the requirements for B2BUAs with respect to loop detection/prevention.
4) A document defining the requirements for B2BUAs to support end-to-end and hop-by-hop media-loopback test calls.
5) A document defining the requirements for B2BUAs to support DTLS-SRTP (RFC 5764) end-to-end.
6) A document defining the requirements for B2BUAs to support STUN message transactions end-to-end.
7) A document defining the requirements for B2BUAs to support RTCP end-to-end.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 29 Mar 2012 13:20:41 +0200

Hi,

I support this work, and after a quick look the proposed charter looks good, but I have a question for clarification regarding the suggested deliverable 2).

A question for clarification (my appologies if it has already been clarified).

"2) A framework document for defining requirements and considerations for traversing B2BUAs."

Deliverables 3) - 7) talk about requirements in order for specific features to "survive" a B2BUA, but I am not sure what requirements 2) is talking about?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
Sent: 29. maaliskuuta 2012 10:33
To: [email-masked] list
Subject: [dispatch] Updated STRAW Charter v2

Howdy,
Updated charter below...

Problem Statement: 

Objectives:

Initial Deliverables:

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Daryl Malas <[email-masked]>
Date: Thu, 29 Mar 2012 07:43:03 -0600

Christer,

Deliverable "2" will be used to create documents defining the requirements
for B2BUAs to support future/undefined "specific features." It allows the
working group to not persist indefinitely.

I am assuming the deliverables are not listed as a prioritized list.  I
would expect the framework to be completed towards the end, based on
previous experience.

Framework Examples:

http://tools.ietf.org/html/rfc6117

http://tools.ietf.org/html/rfc6390

--Daryl

On 3/29/12 1:20 PM, "Christer Holmberg" <[email-masked]>
wrote:

>
>Hi,
>
>I support this work, and after a quick look the proposed charter looks
>good, but I have a question for clarification regarding the suggested
>deliverable 2).
>
>Deliverables 3) - 7) talk about requirements in order for specific
>features to "survive" a B2BUA, but I am not sure what requirements 2) is
>talking about?
>
>Regards,
>
>Christer
>
>
>
>
>Within the context of the SIP protocol and architecture, a Back-to-Back
>User Agent (B2BUA) is any SIP device in the logical path between two User
>Agents performing a role beyond that of a Proxy as defined in RFC 3261.
>The B2BUA may be as simple as a session-stateful Proxy becoming a B2BUA
>in order to terminate dead sessions by generating BYEs; or it may be a
>3PCC-style agent only modifying SDP; or it may be a Session Border
>Controller performing such functions as in RFC 5853; or it may be an
>Enterprise PBX terminating REFERs and such; or it may be a complete UAS
>and UAC implementation with a PRI loopback in-between.
>
>In its most extreme form, the scope of the SIP protocol ends at the UAS
>of the B2BUA, and a new SIP protocol scope begins on its UAC side.  In
>practice, however, users expect some SIP protocol aspects to go beyond
>the scope of the B2BUA's UAS side, and be traversed onto its UAC side, as
>if the B2BUA was not an end unto itself; this is similar to the
>expectation that emails work when they cross from POP and IMAP to/from
>SMTP.
>
>It is impossible to normatively define all the behaviors of B2BUAs in
>general, or even subsets of them such as SBCs or PBXs. Unlike consumer
>NATs, B2BUAs perform widely varying functions for purposes which may be
>unique to their environment, unique to their architecture, or unique to
>the wishes of their administrator.  Instead of defining all things a
>given type of B2BUA must do, a more practical objective would be to
>define what very few things any B2BUA must do to make a specific SIP
>mechanism work, and let the market decide whether to do those things.
>
>The name of this working group reflects that practical objective: if
>there were a thin straw between the SIP UAS and UAC of a B2BUA, what must
>be passed through that straw and used on each side.  Or viewed another
>way, if a B2BUA were in fact a UAS and UAC connected with a PRI loopback
>circuit, and if we could extend ISDN, what information would we carry in
>ISDN across the PRI for a specific SIP mechanism to work end-to-end.
>
>For example, the WG could produce a document which specifies that the
>Max-Forwards header field value should be copied and decremented across
>the B2BUA, if the B2BUA wishes to prevent infinite loops.  Administrators
>could then tell their B2BUA vendors to comply with the document, if the
>administrator so wishes.
>
>
>Objectives:
>The objectives of the STRAW Working Group are to publish normative
>documents which define which SIP header fields, parameters, MIME bodies,
>body content fields/information, or media-plane characteristics are
>required to traverse between the User Agent "sides" of a B2BUA for
>specific functions to work.
>
>The specific functions covered are expected to relate to
>already-published RFCs or existing RAI area work, as opposed to all
>future IETF work.  In other words, the Working Group is not meant to be a
>never-ending source for B2BUA requirements in the RAI area.
>
>Deliverables would indicate which types of B2BUAs would apply or not.
>For example, a document defining the requirements for end-to-end
>DTLS-SRTP would not apply to B2BUAs which terminate media, such as
>transcoders or recorders.
>
>
>Initial Deliverables:
>4) A document defining the requirements for B2BUAs to support end-to-end
>and hop-by-hop media-loopback test calls.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 29 Mar 2012 10:43:11 -0400

Daryl,

That sounds like signing a blank check.
Will certain implementations be declared non-compliant to the RFC for some
unknown future feature?

Would this also require future SIP features to add a section, say just
prior to the Security section,
that would need to declare handling by B2BUAs?

Mike

---

From: Daryl Malas <[email-masked]>
Date: Thu, 29 Mar 2012 08:55:53 -0600

Michael,

I do not view it this way.  If someone develops a requirements document based on the framework, it would still need to be approved by a directorate (only used as an example, may not really apply) or something similar.  The mailing list could also be kept open for these.  There are existing examples of processes for this.

With regards to the considerations, the document would provide details of variables to include in a considerations section.  Again, the considerations section, part of an Internet Draft, would still need to be reviewed and processed by the working group, AD's, IESG, etc.

--Daryl

From: Michael Hammer <[email-masked]<mailto:[email-masked]>>
Date: Thu, 29 Mar 2012 08:43:11 -0600
To: Daryl Malas <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> list" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dispatch] Updated STRAW Charter v2

Daryl,

That sounds like signing a blank check.
Will certain implementations be declared non-compliant to the RFC for some unknown future feature?

Would this also require future SIP features to add a section, say just prior to the Security section,
that would need to declare handling by B2BUAs?

Mike

On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <[email-masked]<mailto:[email-masked]>> wrote:
Christer,

Framework Examples:

--Daryl

On 3/29/12 1:20 PM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>>
wrote:

>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>Behalf Of Hadriel Kaplan
>To: [email-masked]<mailto:[email-masked]> list
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Mar 2012 16:59:39 +0200

> that would need to declare handling by B2BUAs?

That seems like the only sustainable approach I can envision.

	Thanks,
	Paul

>     On 3/29/12 1:20 PM, "Christer Holmberg"
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>      >
>      >Hi,
>      >
>      >"2) A framework document for defining requirements and
>     considerations for
>      >traversing B2BUAs."
>      >
>      >From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>      >Behalf Of Hadriel Kaplan
>      >To: [email-masked] <mailto:[email-masked]> list
>      >1) A taxonomy document defining role-types of B2BUAs, as a
>     reference for
>      >other deliverables.
>      >2) A framework document for defining requirements and
>     considerations for
>      >traversing B2BUAs.
>      >3) A document defining the requirements for B2BUAs with respect to
>     loop
>      >detection/prevention.
>      >5) A document defining the requirements for B2BUAs to support
>     DTLS-SRTP
>      >(RFC 5764) end-to-end.
>      >[email-masked] <mailto:[email-masked]>
>      >[email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Mar 2012 16:22:19 +0000

Hey Mike,
comments inline…

> Will certain implementations be declared non-compliant to the RFC for some unknown future feature?

I'm not quite sure in what way you meant that - which RFC your above sentence refers to.  

Do you mean: "Assume we publish this Framework as RFC X, would a B2BUA that is not compliant to RFC X also not be compliant to future SIP features/extensions in other future RFCs?"  If you meant that, I certainly don't expect that to be the case.  First, I don't even think it would be possible to define a Framework that stipulated how B2BUAs should behave for any given future SIP extension.  To me a "Framework" in this case is more of a guidelines and recommendations for future RFCs to consider how their new extension might be impacted by B2BUAs, and how they could/should address it in the future RFCs.

Or did you mean: "assume we publish this Framework as RFC X, and some future IETF RFC Y includes a B2BUA considerations section based on RFC X's guidelines, then would a B2BUA not following those considerations in RFC Y be non-compliant to RFC Y?"  If you meant that, then yes that's likely.  I mean if a future RFC Y defined for a B2BUA to behave a certain way to support some extension working, and a B2BUA didn't do it, then by definition the B2BUA wouldn't be compliant to RFC Y.

> that would need to declare handling by B2BUAs?

I don't believe it would "require" it, at least not in the same sense that the Security section is required.  Personally I'd rather it be a guidelines type thing, and that individual RAI-area RFCs get to ignore it.  For example if it's just not relevant to RTCWeb nor VIPR.  But it's up to the A-D's or RAI area to decide how applicable it would be, presumably.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Mar 2012 16:29:12 +0000

Daryl,
Do you mind if I remove that deliverable from the Charter?  The STRAW Working Group can always add it back in, once the WG's established and there's a candidate draft to look at and think about.  I think I understand what you're looking for and I like the idea, but I too am not sure if we're all on the same page, or if we can actually produce such a document.  So I'd prefer to just delay that one until we have such a draft written up, and so we can get STRAW created sooner.  As you said it would be timed toward the end anyway, so there's no urgency.

-hadriel

On Mar 29, 2012, at 4:55 PM, Daryl Malas wrote:

Michael,

--Daryl

Daryl,

Mike

Framework Examples:

--Daryl

---

From: Daryl Malas <[email-masked]>
Date: Fri, 30 Mar 2012 11:00:16 -0600

Hadriel,

I guess in the end it doesn't matter; however, I would argue that working group deliverable intentions does not mean the work is not scrapped at a later point either.  In fact, working group drafts and working groups have been scrapped due to a number of different reasons…some you have described below.  The reason I am a proponent of keeping it in the list, is that it provides a reminder to attempt putting this together towards the end.  I admit that I'm not 100% sure it is a feasible deliverable, but I think it helps avoid the potential situation of continuously dealing with "features" for many years to come.  All of this being said, if it is the only remaining controversial item, then I am not that bent on having it in there now.  The overall work is more valuable that quibbling over this one deliverable.

--Daryl

From: Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>
Date: Fri, 30 Mar 2012 10:29:12 -0600
To: Daryl Malas <[email-masked]<mailto:[email-masked]>>
Cc: Michael Hammer <[email-masked]<mailto:[email-masked]>>, Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> list" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dispatch] Updated STRAW Charter v2

Daryl,

-hadriel

Michael,

--Daryl

Daryl,

Mike

Framework Examples:

--Daryl

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Mar 2012 17:25:27 +0000

Cool, thanks!
I am sure you will be happy to remind us and the eventual chairs about it, at every opportunity. :)
I too want such a draft written, as I said during the DISPATCH presentation that it's my personal belief we have to get future RFCs to do their own B2BUA considerations/requirements, and having a document to point to would be the only way to get that.

-hadriel

On Mar 30, 2012, at 7:00 PM, Daryl Malas wrote:

Hadriel,

--Daryl

Daryl,

-hadriel

Michael,

--Daryl

Daryl,

Mike

Framework Examples:

--Daryl

---

From: Michael Hammer <[email-masked]>
Date: Fri, 30 Mar 2012 16:34:48 -0400

My concern was generally around the practicality of predicting future
events, i.e. new SIP headers in new RFCs,
and the tendency to include mandatory RFCs in RFPs.  So, just trying to
contemplate how future compatibility is handled.

I am happy if this is more the nature of guidelines and suggested guidance
on text addressing B2BUAs in future RFCs.

Mike

On Fri, Mar 30, 2012 at 1:25 PM, Hadriel Kaplan <[email-masked]>wrote:

> I too want such a draft written, as I said during the DISPATCH
> presentation that it's my personal belief we have to get future RFCs to do
> their own B2BUA considerations/requirements, and having a document to point
> to would be the only way to get that.
>
>  -hadriel
>
>  I guess in the end it doesn't matter; however, I would argue that
> working group deliverable intentions does not mean the work is not scrapped
> at a later point either.  In fact, working group drafts and working groups
> have been scrapped due to a number of different reasons…some you have
> described below.  The reason I am a proponent of keeping it in the list, is
> that it provides a reminder to attempt putting this together towards the
> end.  I admit that I'm not 100% sure it is a feasible deliverable, but I
> think it helps avoid the potential situation of continuously dealing with
> "features" for many years to come.  All of this being said, if it is the
> only remaining controversial item, then I am not that bent on having it in
> there now.  The overall work is more valuable that quibbling over this one
> deliverable.
>
>  --Daryl
>
>   From: Hadriel Kaplan <[email-masked]>
> To: Daryl Malas <[email-masked]>
> Cc: Michael Hammer <[email-masked]>, Christer Holmberg <
> [email-masked]>, "[email-masked] list" <
> [email-masked]>
> Do you mind if I remove that deliverable from the Charter?  The STRAW
> Working Group can always add it back in, once the WG's established and
> there's a candidate draft to look at and think about.  I think I understand
> what you're looking for and I like the idea, but I too am not sure if we're
> all on the same page, or if we can actually produce such a document.  So
> I'd prefer to just delay that one until we have such a draft written up,
> and so we can get STRAW created sooner.  As you said it would be timed
> toward the end anyway, so there's no urgency.
>
>  -hadriel
>
>
>  I do not view it this way.  If someone develops a requirements document
> based on the framework, it would still need to be approved by a directorate
> (only used as an example, may not really apply) or something similar.  The
> mailing list could also be kept open for these.  There are existing
> examples of processes for this.
>
>  With regards to the considerations, the document would provide details
> of variables to include in a considerations section.  Again, the
> considerations section, part of an Internet Draft, would still need to be
> reviewed and processed by the working group, AD's, IESG, etc.
>
>  --Daryl
>
>   From: Michael Hammer <[email-masked]>
> To: Daryl Malas <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, Hadriel Kaplan <
> [email-masked]>, "[email-masked] list" <[email-masked]>
> On Thu, Mar 29, 2012 at 9:43 AM, Daryl Malas <[email-masked]>wrote:
>
>> Christer,
>>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 31 Mar 2012 09:56:20 +0000

As I mentioned in IETF-83 Dispatch meeting, the draft has to be written for B2BUA considerations for new SIP/SDP headers.  I understand Hadriel concern about the timeline for the closure of STRAW charter with existing undefined RFC's and so, let the initial draft of B2BUA consideration be in Dispatch.

I will volunteer to write the initial draft for B2BUA consideration. I noticed that lot of folks shows interest during STRAW charter discussion. So, I'm interested in hearing other folks opinion for this activity.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Saturday, March 31, 2012 2:05 AM
To: Hadriel Kaplan
Cc: [email-masked] list
Subject: Re: [dispatch] Updated STRAW Charter v2

My concern was generally around the practicality of predicting future events, i.e. new SIP headers in new RFCs,
and the tendency to include mandatory RFCs in RFPs.  So, just trying to contemplate how future compatibility is handled.

I am happy if this is more the nature of guidelines and suggested guidance on text addressing B2BUAs in future RFCs.

Mike

On Fri, Mar 30, 2012 at 1:25 PM, Hadriel Kaplan <[email-masked]<mailto:[email-masked]>> wrote:

Cool, thanks!

-hadriel

Hadriel,

I guess in the end it doesn't matter; however, I would argue that working group deliverable intentions does not mean the work is not scrapped at a later point either.  In fact, working group drafts and working groups have been scrapped due to a number of different reasons...some you have described below.  The reason I am a proponent of keeping it in the list, is that it provides a reminder to attempt putting this together towards the end.  I admit that I'm not 100% sure it is a feasible deliverable, but I think it helps avoid the potential situation of continuously dealing with "features" for many years to come.  All of this being said, if it is the only remaining controversial item, then I am not that bent on having it in there now.  The overall work is more valuable that quibbling over this one deliverable.

--Daryl

Daryl,

-hadriel

Michael,

--Daryl

Daryl,

Mike

Christer,

Framework Examples:

--Daryl