Subject: [Sipping] Resend: Post WGLC Review: draft-ietf-sipping-sbc-funcs-01.txt

From: "Mary Barnes" <[email-masked]>
Date: Fri, 2 Mar 2007 21:02:46 -0600

I'm resending this as I made the mistake of starting the email based on
the IETF draft announcement and it seems that SPAM filters are having a
fit with that email.  I apologize to folks for whom this might be a
duplicate.

------------------------------------------------------------------------
----------------------------
Hi folks,

The SBC requirements document has been updated reflecting all the
feedback received during WGLC in December: 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-01.txt

A link the previous reviews is available in the (slightly out-of-date)
spreadsheet at:
http://www.softarmor.com/sipping/process/wg-review/sipping-rt.html  (the
reviews are accessed by the 
clicking on the reviewer name)

We'd like to give the WG two weeks to review the changes to the
document.  Thus feedback in the form of a statement of whether the
document is ready to forward to the AD for progression to the IESG and
any detailed comments are appreciated by March 16, 2007. 

The diff is available at:
http://tools.ietf.org/wg/sipping/draft-ietf-sipping-sbc-funcs/draft-ietf
-sipping-sbc-funcs-01-from-00.diff.html

Thanks,
Mary.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Michael Procter" <[email-masked]>
Date: Mon, 12 Mar 2007 09:35:37 -0700

All my previous comments except for 2 appear to be reflected in this
draft.  There is one new comment on some newly added text.

3.1.3:
Given the discussion of Via handling, it would be useful to see this
used
in the example, in addition to Record-Routes.

3.5.3:
The missing ACKs in the diagram are minor, but such things have caused
confusion in the past. (Fig 12, although fig 14 also is missing the
ACKs) 

3.5.3: Newly added text:
'The identification can be done, for example, already in the
registration
phase'
might read more clearly as:
'This might be achieved using information gathered during registration,
or by other means.'

Regards,

Michael Procter

> -----Original Message-----
> From: Mary Barnes [mailto:[email-masked]]
> Sent: 03 March 2007 03:03
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sipping] Resend: Post WGLC
Review:draft-ietf-sipping-sbc-funcs-
> 01.txt

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Wed, 14 Mar 2007 15:02:34 +0200

Hi Michael,

Thank you for the comments, please see my inline replies:

Michael Procter wrote:
> used in the example, in addition to Record-Routes.

I had two reasons why not to add the Via handling example: 1) It would 
be very similar than the current Record-Route handling example, and 2) I 
have tried to give only one example per function in each section.

> confusion in the past. (Fig 12, although fig 14 also is missing the

Ok. So far I have preferred brevity over completeness in the examples, 
but I can add the ACKs to the next revision.

> registration phase' might read more clearly as:

I agree, that is a better wording. I'll do the change to the next revision.

-- 
Jani

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 14 Mar 2007 06:30:30 -0700

Hi Jani,

Thanks for your response.  I've added a few clarifications inline:

> have tried to give only one example per function in each section.

I agree that it would be very similar.  I wasn't expecting a second
example showing Via hiding, I was really expecting Vias and
Record-Routes both featuring in the same example, e.g.

     INVITE sip:[email-masked] SIP/2.0
     Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK-4
     Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK-3
     Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK-2
     Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK-1
     Contact: sip:[email-masked]
     Record-Route: <sip:p3.middle.example.com>
     Record-Route: <sip:p2.example.com;lr>
     Record-Route: <sip:p1.example.com;lr>

             Figure 4: INVITE Request Prior to Topology Hiding

     INVITE sip:[email-masked] SIP/2.0
     Via: SIP/2.0/UDP p4.middle.example.com;branch=z9hG4bK-5
     Contact: sip:[email-masked]
     Record-Route: <sip:p4.domain.example.com;lr>

             Figure 5: INVITE Request After Topology Hiding

My branch IDs are not very random, but you get the idea, I hope.  Whilst
this adds a couple of lines to the draft overall, I feel that the
additional benefit of seeing what happens to the mandatory headers is
worth it.  I discuss this a little more in the next section.

> but I can add the ACKs to the next revision.

If you prefer to keep it brief, I'd be happy for you to simply add a
comment along the lines of 'ACKs omitted for brevity'.  In my experience
(at SIPits and other events), it is very easy for an inexperienced
implementor to use one diagram out of context to justify some bizarre
behaviour.  I don't want somebody waving this document at me in the
future saying 'but for SBCs, you don't need ACKs!'  For the sake of a
couple of lines, or an extra sentence, let's avoid this problem.

Regards,

Michael

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Wed, 14 Mar 2007 15:31:12 +0200

Hi Michael,

Ok, I'll add the Via handling example to the current example, and add 
the ACKs as well.

-- 
Jani