Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 7 Jun 2006 11:39:08 +0100

I worked through this document and identified the following points for consideration.

Technical
---------

1)	Section 2.2, final indented paragraph. Firstly, can we emphasise that this applies to any method, e.g. by inserting the words: "Any 483 response, to any method, SHOULD..." Secondly, if we are going to use SHOULD here, can we insert some informative text relating to why it is only a SHOULD and not a MUST, and therefore giving the reader the understanding of why it does not always apply.

2)	Section 2.2 and elsewhere, I am not convinced that the use of the Warning header is consistent with RFC 3261. The clear implication of RFC 3261 is that Warning headers relate only to the session description contained in the request.

3)	Section 2.4. The 3rd (final) paragraph clearly indicates this as a normative requirement, with SHOULD strength. The second paragraph contains a similar requirement, but no keyword. Either rephrase to include a "SHOULD", or change the "It is suggested..." to It is RECOMMENDED...".

NITS
----

a)	Wherever we indicate "483 error response" in the text, can we follow the style of RFC 3261 and change it to "483 (Too Many Hops) response code"?

b)	Instead of "sender" and "receiver" (relating to a request) can we use RFC 3261 terminology "UAC" and "UAS". Occurences at least in the abstract (where they will need expansion) and in the introduction"?

c)	In the Abstract delete the paragraph relating to "Comments are solicited..." It's an I-D after all.

d)	In the examples, I note they all use "pingtel.com". Should these be changed to a more usual example URI.
regards

e)	In section 2.2, Can we make the two sets of bullets more apparent? 

f)	In section 2.2, 1st bullet of 1st bullet list, the reference to RFC 3261 needs to have the reference identifier.

g)	When referring to the "Max Forwards value" use "Max Forwards header field value", i.e. consistent with RFC 3261 usage.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 02 June 2006 20:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt 
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Session Initiation Protocol 
> Working Group of the IETF.
> 
> 	Title		: Diagnostic Responses for SIP Hop Limit Errors
> 	Author(s)	: S. Lawrence, et al.
> 	Filename	: draft-ietf-sip-hop-limit-diagnostics-02.txt
> 	Pages		: 12
> 	Date		: 2006-6-2
> 	
> The SIP protocol imposes a limit on the number of hops a request may
> make from a sender to the recipient.  When this limit is reached, a
> 483 error response is returned.  The present form of the 483 response
> does not provide enough information for the sender or proxies on the
> path to diagnose failures whose symptom is that the hop limit is
> reached.  This document proposes additional diagnostic information to
> be returned in a 483 response.
> 
> Comments are solicited, and should be directed to the SIP working
> group list at [email-masked]'.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sip-hop-limit-d
> iagnostics-02.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of the message.  
> You can also visit 
https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-hop-limit-diagnostics-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-hop-limit-diagnostics-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 08 Jun 2006 11:44:20 -0400

> I worked through this document and identified the following points for consideration.

Thanks.

> Technical
> ---------
> 
> 1)	Section 2.2, final indented paragraph. Firstly, can we emphasise
> that this applies to any method, e.g. by inserting the words: "Any 483
> response, to any method, SHOULD..." Secondly, if we are going to use
> SHOULD here, can we insert some informative text relating to why it is
> only a SHOULD and not a MUST, and therefore giving the reader the
> understanding of why it does not always apply.

Why do you think that the method needs to be mentioned?  I don't see any
ambiguity in "any 483 response".

> 2)	Section 2.2 and elsewhere, I am not convinced that the use of the
> Warning header is consistent with RFC 3261. The clear implication of
> RFC 3261 is that Warning headers relate only to the session
> description contained in the request.

It didn't seem worth the trouble to define a new header, or to require
some multipart body just to identify the last server - I'm open to
suggestions.  It seems a valuable part of the diagnostic information.

> 3)	Section 2.4. The 3rd (final) paragraph clearly indicates this as a
> normative requirement, with SHOULD strength. The second paragraph
> contains a similar requirement, but no keyword. Either rephrase to
> include a "SHOULD", or change the "It is suggested..." to It is
> RECOMMENDED...".

Good catch - I'll make that change.

> NITS
> ----
> 
> a)	Wherever we indicate "483 error response" in the text, can we
> follow the style of RFC 3261 and change it to "483 (Too Many Hops)
> response code"?

I started to make that change, and it seemed to me that this got pretty
repetitive if done everywhere.  Given that the entire draft is on this
one response, I'm not sure this actually improves the clarity.

> b)	Instead of "sender" and "receiver" (relating to a request) can we
> use RFC 3261 terminology "UAC" and "UAS". Occurences at least in the
> abstract (where they will need expansion) and in the introduction"?
> 

Yes, that should have come out in this version...

> changed to a more usual example URI.

They were originally actual messages copied verbatim from traces, but
yes, in the final draft they should be changed... done.

> e)	In section 2.2, Can we make the two sets of bullets more apparent? 

I think so.

> f)	In section 2.2, 1st bullet of 1st bullet list, the reference to RFC
> 3261 needs to have the reference identifier.

Done.

> g)	When referring to the "Max Forwards value" use "Max Forwards header
> field value", i.e. consistent with RFC 3261 usage.

Done.

Thanks for the careful reading.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: "Dale R. Worley" <[email-masked]>
Date: Thu, 15 Jun 2006 09:06:47 -0400

> solicited..." It's an I-D after all.

But after the document becomes a Request For Comments, comments on it
will no longer be solicited!  ;-)

Dale