Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Tue, 27 Apr 2010 13:26:49 +0200

Hello Hadriel, All,
Thanks for the draft. Similar to the other comments, I think that
draft-kaplan-dispatch-session-id-01 should not be restricted to
troubleshooting. At least one other active draft discusses correlating
SIP dialogs (draft-loreto-dispatch-disaggregated-media-01.txt), and the
Session-ID header field could be thought of as correlating a series of
dialogs linked in series by B2BUAs. It might be that this header field
can be used for both purposes.

Could you please clarify the importance of making the draft "standards
track"? I had a look at what standards track means in RFC 4677 "The Tao
of the IETF" and I found that it means the author gives up control of
the draft, the draft needs IETF (not just working group) consensus and
that the standards track should distinguish specifications that have
been demonstrated to interoperate. Are these the reasons for suggesting
standards track?

I think the draft needs to be clear on the meaning of "pass the
identifier through" in section 1.1 Requirements:

REQ2: It must be possible to pass the identifier through SIP B2BUAs, 
      with as high a probability as possible.  This requirement drives
the 
      following requirements:

and also the meaning of "related requests" in section 4.5

4.5. B2BUA Behavior 
    
   A B2BUA compliant with this document MUST copy the Session-ID header 
   field it receives in requests as a UAS into the related requests it 
   generates as a UAC; and any Session-ID field it receives in 
   responses as a UAC into the correlated responses it generates as a 
   UAS.

As the draft says (section 8.2) "In general, B2BUA behavior cannot be
dictated by standards.  They do whatever their owners/operators wish
them to do, or whatever is necessary to make their applications work."
So to help B2BUAs behave predictably, I think the draft needs a more
detailed description and examples of when requests are related and when
they are not. 

I also have a few editorial comments:

Change:
"Abstract
    
   There is a need for having a globally unique session identifier for 
   the same SIP session, which can be consistently maintained across 
   Proxies, B2BUAs and other SIP middle-boxes, for the purpose of 
   Troubleshooting.  This draft proposes a new SIP header to carry such 
   a value: Session-ID."

To:
"Abstract
    
   There is a need for having a globally unique session identifier for 
   the same SIP session, which can be consistently maintained across 
   Proxies, B2BUAs and other SIP middle-boxes, for the purpose of 
   Troubleshooting.  This draft proposes a new SIP header field to carry
such 
   a value: Session-ID."

Change:
"1. Introduction  
The SIP [RFC3261] Call-ID header value is a globally unique 
   identifier, mandatory in all requests/responses, which identifies 
   SIP messages belonging to the same dialog or registration."

"1. Introduction  
The SIP [RFC3261] Call-ID header value is a globally unique 
   identifier, mandatory in all requests/responses, which is the same
for 
   SIP messages belonging to the same dialog or registration."

Change:
"4.5. B2BUA Behavior 
    
   A B2BUA compliant with this document MUST copy the Session-ID header 
   field it receives in requests as a UAS into the related requests it 
   generates as a UAC; and any Session-ID field it receives in 
   responses as a UAC into the correlated responses it generates as a 
   UAS. "

To:
"4.5. B2BUA Behavior 
    
   A B2BUA compliant with this document MUST copy the Session-ID header 
   field it receives in requests as a UAS into the related requests it 
   generates as a UAC; and any Session-ID header field it receives in 
   responses as a UAC into the correlated responses it generates as a 
   UAS. "

Best regards,
Peter

Message: 2

Date: Mon, 26 Apr 2010 06:19:30 -0400

From: Peter Musgrave <[email-masked]>

Subject: Re: [dispatch] New version:

draft-kaplan-dispatch-session-id-01

To: "Hutton, Andrew" <[email-masked]>

Cc: Roland Jesske <[email-masked]>, "[email-masked]"

<[email-masked]>, Laura Liess <[email-masked]>,

Hadriel Kaplan <[email-masked]>, Martin H?lsemann

<[email-masked]>

Message-ID:

<[email-masked]>

Content-Type: text/plain; charset=ISO-8859-1

Hi,

I too would like to see this standards track.

I already have plans to use it for some internal call logging (and I can
see it's value to siprec also).

Regards,

Peter

On Mon, Apr 26, 2010 at 5:50 AM, Hutton, Andrew
<[email-masked]> wrote:

> Hi,

> I also think this draft has many more uses than just troubleshooting I
know for example it has been discussed as being potentially useful to
the SIPREC work.

> For this reason I would like to see the draft published as Standards
Track.

> Regards

> Andy

>> -----Original Message-----

>> From: [email-masked]

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

>> Sent: 23 April 2010 16:55

>> To: Laura Liess

>> Cc: [email-masked]; Martin H?lsemann; Roland Jesske

>> Subject: Re: [dispatch] New version:

>> draft-kaplan-dispatch-session-id-01

>> Hi Laura,

>> Comments inline...

>> > -----Original Message-----

>> > From: Laura Liess [mailto:[email-masked]
<mailto:[email-masked]> ]

>> > Sent: Tuesday, April 20, 2010 8:27 AM

>> > To: Hadriel Kaplan

>> > I don't think that there is no interest for the draft to be 

>> > DISPATCHed. We had a lot of discussion on it in the past. It's just

>> > that people are busy and the current DISPATCH process requires a 

>> > lot of overhead (charter, chairs...).

>> Sorry I should have been clearer - I didn't mean no interest in it, I

>> meant no interest in DISPATCHing it to an existing WG. (and I 

>> definitely do NOT think it warrants a new WG :)

>> > Comment to the draft:

>> > - I am OK with allowing other algorithms than Call-ID hash. 

>> > However, the description of the hash algorithm in the 00 version 

>> > was very usefull and avoided problems with different algorithms 

>> > being used by the B2BUA and monitoring systems. I don't see any 

>> > reason for not including it as an implementation example.

>> The concept of specifying the algorithm was only to guarantee the 

>> value wouldn't reveal which vendor had created it. ?But it wouldn't 

>> have made it possible for a monitoring system to determine the 

>> session-id value for messages which don't already have a session-id, 

>> because the hash used a private key unique to every system. ?In other

>> words, two different systems would generate two different Session-IDs

>> for the same Call-ID. ?That was by design.

>> So since it was only to avoid revealing the vendor, I got comments 

>> back that a random number would be good enough for that, and reduce 

>> the work/performance-hit of doing a strong hash.

>> > - Chapter 3. Overview, 3-rd paragraph: "Instead this new

>> header field

>> > provides an identifier for troubleshooting uses only."

>> > ?Implementations and other SDOs (I know of 3GPP) already use 

>> > Session-ID for SIP-services as Conferencing, to correlate

>> both legs of

>> > a dialog across a B2BUA. There is no other SIP-identifier

>> they can use

>> > for this. So my proposal is to allow this in the Session-ID draft.

>> > Otherwise we either have inconcistency between IETF and IMS

>> documents.

>> Is there a doc I can go look at which describes how they're going to 

>> use it?

>> -hadriel

>> _______________________________________________

>> dispatch mailing list

>> [email-masked]

>> https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch> 

> _______________________________________________

> dispatch mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/dispatch
<https://www.ietf.org/mailman/listinfo/dispatch>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 27 Apr 2010 07:35:45 -0400

Re: standards track

Ah...thanks for the clarification.

I misinterpreted this to mean "get adopted by a working group" and
that was the idea I wanted to express support for.

Peter Musgrave

> been demonstrated to interoperate. Are these the reasons for suggesting
 <rest deleted>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 27 Apr 2010 15:02:49 +0200

Hi,

Have a look at http://www.ietf.org/iesg/informational-vs-experimental.html and read section 2.

This states:

An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.

For me this suggests that this specification which seems to be important and probably will be widely implemented should be a standards track specification.

Regards
Andy

> From: Peter Musgrave [mailto:[email-masked]] 
> Sent: 27 April 2010 12:36
> To: Dawes, Peter, VF-Group
> Cc: Hutton, Andrew; Cc: Roland Jesske; [email-masked]; 
> [email-masked]; Hadriel Kaplan; 
> [email-masked]
> Subject: Re: New version: draft-kaplan-dispatch-session-id-01
> 
> Re: standards track
> 
> > SIP dialogs 
> (draft-loreto-dispatch-disaggregated-media-01.txt), and the

---

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Wed, 28 Apr 2010 10:12:57 +0200

Hi Andy, Peter,
Thanks for the explaining the implications of standards track. After
checking http://www.ietf.org/iesg/informational-vs-experimental.html and
RFC 2026, I think that this draft should be standards track. When the
updated draft-kaplan-dispatch-session-id was announced, it was pointed
out that RFC 5727 allows new header fields to be introduced by
Informational RFCs but RFC 5727 says "The proposed header field MUST be
of a purely informational nature and MUST NOT significantly change the
behavior of SIP entities that support it." which does not seem to apply,
particularly if Session-ID is not for troubleshooting only.
 
Regards,
Peter

-----Original Message-----
From: Hutton, Andrew [mailto:[email-masked]] 
Sent: 27 April 2010 14:03
To: Peter Musgrave; Dawes, Peter, VF-Group
Cc: Cc: Roland Jesske; [email-masked]; [email-masked];
Hadriel Kaplan; [email-masked]
Subject: RE: New version: draft-kaplan-dispatch-session-id-01

Hi,

Have a look at
http://www.ietf.org/iesg/informational-vs-experimental.html and read
section 2.

This states:

An "Informational" specification is published for the general
information of the Internet community, and does not represent an
Internet community consensus or recommendation.

For me this suggests that this specification which seems to be important
and probably will be widely implemented should be a standards track
specification.

Regards
Andy