Subject: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question

From: Brett Tate <[email-masked]>
Date: Mon, 13 Jun 2016 14:51:34 -0400

Hi,

The following are a few comments concerning
draft-sunil-sankar-dispatch-sip-incr-00.

Thanks,
Brett

------

1) The draft should clarify the relation to SHOULD and MUST within other
RFCs concerning header inclusion.  Section 6.1 appears to indicate that
you can ignore MUST statements within other RFCs concerning the need to
include a specific a header.  However, I'm currently unsure if section 4
next-to-last sentence supports or conflicts with that mandate.

2) You might want to reword section 4 to use normative language.

3) How would this draft interact with RFC 4028 from refresh -versus-
deactivation perspective?

4) How would this draft interact with draft-ietf-insipid-session-id since
the presence of the Session-ID is to help debug the call flow?

5) You should clarify that transaction specific headers such as Supported,
Require, Proxy-Require, and Content-Length need to be included again.

---

From: "Neelakantan, Neel" <[email-masked]>
Date: Mon, 13 Jun 2016 20:32:46 +0000

Hi,

There are number of issues with this draft.  

1) The CSeq should be contiguous, but 3261 allow the UAS to accept non-contiguous CSeq if higher than the previous ones.

2) As others have pointed out, there are number of use cases, that rely on adding or removing a header in subsequent examples (Session Exipres, Route/Record-Route, Authentication headers, etc).

3) If UDP fragmentation is an issue, then TCP shall be used.

4) When new headers are introduced in a newer RFC, it provides a way to deal with headers that are absent.  This proposal may have to deal with such future extensions.

Thanks,
Neel.

> -----Original Message-----
> From: dispatch [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: Monday, June 13, 2016 1:52 PM
> To: Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE
> LIMITED at Cisco) <[email-masked]>; [email-masked]
> Subject: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and
> question
> 
> Hi,
> 
> The following are a few comments concerning draft-sunil-sankar-dispatch-
> sip-incr-00.
> 
> Thanks,
> Brett
> 
> ------
> 
> RFCs concerning header inclusion.  Section 6.1 appears to indicate that you
> can ignore MUST statements within other RFCs concerning the need to
> include a specific a header.  However, I'm currently unsure if section 4 next-
> to-last sentence supports or conflicts with that mandate.
> 
> 4) How would this draft interact with draft-ietf-insipid-session-id since the
> presence of the Session-ID is to help debug the call flow?
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Ranjit Avasarala <[email-masked]>
Date: Mon, 13 Jun 2016 16:30:09 -0500

Hi Sunil

my initial comments on this draft

Section 1

1. the intial SIP message e.g REGISTER or INVITE contains atleast 7
mandatory headers and not 6.  E.g  To, From, Call-ID, CSeq, Contact,
    Max-Forwards and Via.  In addition there could be more headers like
Content-Type, Content-Length, etc
2. Instead of jointly - which actually is used for 2 headers and not for
many.  so you should use the word - together or all of them .
3. Also I don't think the main motivation of providing more headers in a
SIP message is to actually find a facility though the actual intent is to
better
    describe the session or indicate support for a certain capability or
service and mandate some feature (long list...)
4. Also I do not think we can conclude whether the headers are needed or
not before and after session is established.  every header that is part of
the
    SIP message has certain significance and it is put if there is a need.
so we can not generalize saying that prior to session establishment more
headers
    are needed and after session less.
5. if you think it is burden on the bandwidth, the messages can be
compressed.

More comments as I review

Thanks
Ranjit

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 28 Jun 2016 14:02:53 +0000

Does Cisco or anyone else plan to implement this draft in their products? I’m skeptical this would improve performance over cached parsing approaches. 

> On Jun 13, 2016, at 9:51 PM, Brett Tate <[email-masked]> wrote:
> 
> Hi,
>

---

From: sunil sinha <[email-masked]>
Date: Thu, 30 Jun 2016 11:10:52 +0530

Hi,

I don't think at this point Cisco or anyone else plan to implement this
draft in their product.

Thanks & Regards
sunil

On Tue, Jun 28, 2016 at 7:32 PM, Cullen Jennings (fluffy) <[email-masked]>
wrote:

>
> Does Cisco or anyone else plan to implement this draft in their products?
> I’m skeptical this would improve performance over cached parsing approaches.
>
>
>