Subject: [Sip] Comments on bis-06

From: William Marshall <[email-masked]>
Date: Fri, 1 Feb 2002 00:22:15 -0500 (EST)

I'm continuing a detailed review of bis-06, but wanted to post
the comments so far, so that they can get into bis-07.
Line numbers refer to the pdf version.

Minor technical issues and comments:

section 6
  Definition of Proxy-Server should make a reference to Back-to-Back-UA
for a element that goes beyond the specific parts of the request message
that a proxy is allowed to rewrite before forwarding.

Section 7, lines 758-9
  The definition of notation [HX.Y] is buried here.  I suggest the
notation be defined in section 3, Terminology.

Section 7.3.1, line 870
  The MUST in this statement is stating a requirement on future
extensions, not something that is testable for this specification.
The statement is fine as a lower case must, but not as a spec word.

Section 8.1.1.9 (line 1072) and 8.2.4 (line 1322)
  The need for option tags being defined in standards track RFCs is
discussed in draft-tsvarea-sipchange-00.  As I stated at IETF52, there
are problems with this requirement related to various carrier-
required functions that will not be standardized in IETF, like 
electronic surveillance, which was not considered in sipchange-00.
I'm still looking forward to sipchange-01, and the last-call
promised on the revised version, to resolve this problem.  In the
meantime, I do not believe 2543bis needs to duplicate the requirement,
however it may be resolved.  I'd suggest wording like "The option tags
listed MUST only refer to extensions defined in accordance with [ref to
draft-tsvarea-sipchange-xx]." to replace paragraph starting in 1072, and
the last sentence at line 1322.

Section 18.2, lines 3451-3455
  This paragraph should at lease mention that a forking request may lead
to multiple provisional responses, each sent reliably, which requires the
UAC to maintain a separate value of RSeq for each dialog resulting from
the initial request.

Section 26.2, line 5733, and lines 6781-3
  The call flow examples draft has expired, but that is a separate issue.
As for bis, I question whether this should be a normative reference.  There
is no text that separates normative from informative refs, so the 
assumption will be that all are normative.  While a number of the references
really are just informative, I have no problem with them except [39].

Editorial nits:

line 22:	ontop -> on top
Figure 1:	corrupted in pdf version
line 1135,1138,1142	quotes around the sip urls are corrupted
line 2056:	2xx -> All 2xx (i.e. don't start sentence with "2xx")
line 2059:	"usage for construction offers and answers" -> "usage
			for construction __of__ offers and answers"
line 2319:	since there is no 15.2, drop the 15.1 heading and
			promote 15.1.1 and 15.1.2 to 15.1 and 15.2
line 2864:	wrong font for "OPEN ISSUE #7", but hopefully that will
			be removed in next version
line 3401:	"MUSTinclude" -> "MUST include"
line 3430:	"MUSTbe" -> "MUST be"
line 5734-5:	dreg?
line 5848:	illegal character in front of "From" in third line
line 5854:	excessive space in front of "non-urgent" on 4th line
line 5911:	"optio" -> "option"
line 5913:	need closing right bracket at end of line.  Probably the
			note is to the RFC Editor, not IANA.

That's the list so far.  More to come.

Bill Marshall
[email-masked]

_______________________________________________
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