Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture
draft-andreasen-sipping-rfc3603bis-07

[Ballot comment]
The Gen-ART Review by Francis Dupont was posted on 24-Dec-2008. Please
  consider the editorial concerns that were raised.

  - Abstract page 2: please remove (SIP) [RFC3261] (the Abstract is an
    autonomous text, the abbrev is not used so is useless, etc)
  - ToC page 3: Acknowledgements -> Acknowledgments
  - 1 page 5: this is the right place to introduce the SIP abbrev,
    i.e., SIP -> Session Initiation Protocol (SIP) [RFC3261]
  - 2 page 6: the DCS abbrev is never introduced
  - 5 page 10: the UAC abbrev is not introduced, IMHO you should find
    a way to introduce UAC and UAS abbrevs in 3 (Trust Boundary).
  - 5.1 page 11: .The trace-param -> . The trace-param
  - 8 page 25: ccc-id -> cccid (for uniformity)
  - 8.3 page 28: The UAC may also include a P-DCS-Redirect header.
    -> The UAC MAY also include a P-DCS-Redirect header.
    (IMHO according to the context this should be the uppercase keyword)
  - 8.5 page 28: .Otherwise, -> . Otherwise,
  - 12 page 37: Acknowledgements -> Acknowledgments
  - 12 page 37: Tung- Hai -> Tung-Hai ?
  - 13.2 page 38: please use the long names for months (first 4 entries)

[Ballot comment]
Comments from GEN Art some minor editorial concerns (i.e, to be fixed bt the RFC Editor):

- Abstract page 2: please remove (SIP) [RFC3261] (the Abstract is an
autonomous text, the abbrev is not used so is useless, etc)

- ToC page 3: Acknowledgements -> Acknowledgments

- 1 page 5: this is the right place to introduce the SIP abbrev,
i.e., SIP -> Session Initiation Protocol (SIP) [RFC3261]

- 2 page 6: the DCS abbrev is never introduced

- 5 page 10: the UAC abbrev is not introduced, IMHO you should find
a way to introduce UAC and UAS abbrevs in 3 (Trust Boundary).

- 5.1 page 11: .The trace-param -> . The trace-param

- 8 page 25: ccc-id -> cccid (for uniformity)

- 8.3 page 28: The UAC may also include a P-DCS-Redirect header.
-> The UAC MAY also include a P-DCS-Redirect header.
(IMHO according to the context this should be the uppercase keyword)

- 8.5 page 28: .Otherwise, -> . Otherwise,

- 12 page 37: Acknowledgements -> Acknowledgments

- 12 page 37: Tung- Hai -> Tung-Hai ?

- 13.2 page 38: please use the long names for months (first 4 entries)

IANA Last Call questions/comments:

IANA has a question about the second action requested by
draft-andreasen-sipping-rfc3603bis-07.txt:

ACTION 1:

Upon approval of this document, IANA will make the following
changes in the "Header Fields" registry at
http://www.iana.org/assignments/example-foobar-registry

OLD:
P-DCS-Trace-Party-ID [RFC3603]
P-DCS-OSPS [RFC3603]
P-DCS-Billing-Info [RFC3603]
P-DCS-LAES [RFC3603]
P-DCS-Redirect [RFC3603]

NEW:
P-DCS-Trace-Party-ID [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-OSPS [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-Billing-Info [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-LAES [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-Redirect [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]


ACTION 2:

Upon approval of this document, IANA will make the following
changes in the "Header Field Parameters and Parameter Values"
registry at
http://www.iana.org/assignments/example-foobar-registry

OLD:
P-DCS-Billing-Info called No [RFC3603]
P-DCS-Billing-Info calling No [RFC3603]
P-DCS-Billing-Info charge No [RFC3603]
P-DCS-Billing-Info locroute No [RFC3603]
P-DCS-Billing-Info rksgroup No [RFC3603]
P-DCS-Billing-Info routing No [RFC3603]
P-DCS-LAES content No [RFC3603]
P-DCS-LAES key No [RFC3603]
P-DCS-Redirect count No [RFC3603]
P-DCS-Redirect redirector-uri No [RFC3603]

NEW:
P-DCS-Billing-Info called No [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-Billing-Info calling No [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-Billing-Info charge No [RFC-andreasen-sipping-rfc3603bis-
07][RFC3603]
P-DCS-Billing-Info locroute No [RFC-andreasen-sipping-rfc3603bis-
07][RFC3603]
P-DCS-Billing-Info rksgroup No [RFC-andreasen-sipping-rfc3603bis-
07][RFC3603]
P-DCS-LAES content No [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-Redirect count No [RFC-andreasen-sipping-rfc3603bis-07][RFC3603]
P-DCS-Redirect redirector-uri No [RFC-andreasen-sipping-rfc3603bis-
07][RFC3603]
P-DCS-Billing-Info jip No [RFC-andreasen-sipping-rfc3603bis-07]
P-DCS-LAES bcid No [RFC-andreasen-sipping-rfc3603bis-07]
P-DCS-LAES cccid No [RFC-andreasen-sipping-rfc3603bis-07]
P-DCS-Trace-Party-ID timestamp No [RFC-andreasen-sipping-rfc3603bis-07]


**QUESTION: Should we remove the entries "P-DCS-Billing-Info
routing" and "P-DCS-LAES key," or mark them "OBSOLETED" or
"DEPRECATED"?

We understand the above to be the only IANA Actions for this document.

State Change Notice email list have been change to wtm@research.att.com, fandreas@cisco.com, B.McKibben@cablelabs.com, draft-andreasen-sipping-rfc3603bis@tools.ietf.org, mary.barnes@nortel.com from wtm@research.att.com, fandreas@cisco.com, B.McKibben@cablelabs.com, draft-andreasen-sipping-rfc3603bis@tools.ietf.org

Expert Evaluation (per RFC 3427):
---------------------------------
    1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
        proposal for applicability to SIP and conformance to these
        guidelines.  The Expert Reviewer will send email to the Transport
        Area Directors on this determination.  The expert reviewer can
        cite one or more of the guidelines that haven't been followed in
        his/her opinion.

I am the designated expert.

    2.  The proposed extension MUST NOT define SIP option tags, response
        codes, or methods.

The extension defines new header fields, but not option tags, response
codes, or methods.

    3.  The function of the proposed header MUST NOT overlap with current
        or planned chartered extensions.

Note that this draft is a revision of RFC 3603 originally published in
October 2003. There is a historical overlap: the P-DCS-Redirect header
overlaps with the History-Info header specified in RFC 4244. It is
understandable that this overlap has historical reasons: the original
P-DCS-Redirect came to existence before History-Info. For backward
compatibility reasons with existing implementations, the P-DCS-Redirect
header has to exist. Perhaps the draft should include a note
acknowledging this overlap and providing a motivation for its existence.

Other than that, there are no overlaps with current or planned chartered
extensions.

    4.  The proposed header MUST be of a purely informational nature, and
        MUST NOT significantly change the behavior of SIP entities which
        support it.  Headers which merely provide additional information
        pertinent to a request or a response are acceptable.  If the
        headers redefine or contradict normative behavior defined in
        standards track SIP specifications, that is what is meant by
        significantly different behavior.

The defined headers are of a purely informational nature and do not
significantly change the behavior of SIP entities which support it.

    5.  The proposed header MUST NOT undermine SIP security in any sense.
        The Internet Draft proposing the new header MUST address security
        issues in detail as if it were a Standards Track document.  Note
        that, if the intended application scenario makes certain
        assumptions regarding security, the security considerations only
        need to meet the intended application scenario rather than the
        general Internet case.  In any case, security issues need to be
        discussed for arbitrary usage scenarios (including the general
        Internet case).

Security of these new headers is appropriately addressed in each case and
in the general Security Considerations section.

    6.  The proposed header MUST be clearly documented in an (Individual
        or Working Group) Informational RFC, and registered with IANA.

That is the main purpose of this document.

    7.  An applicability statement in the Informational RFC MUST clearly
        document the useful scope of the proposal, and explain its
        limitations and why it is not suitable for the general use of SIP
        in the Internet.

An applicability statement clearly indicates the scope of applicability
of these header fields.


Comments:
---------

1) Section 5.1, extension to Table 2 of RFC 3261 for the
P-DCS-Trace-Party-ID. The proxy column indicates "dr" (for "delete" and
"read" actions). The text in Section 5.6.1 also indicates a modify
action, so I am missing an "m" mnemonic in this column.

Reading Section 5.6.1, I haven't being able to determine if there is a
case when an originating proxy can add ("a") this header if the incoming
request does not contain it. Perhaps this is also something that Section
5.6.1 should clarify.



2) Issues with the NTP format.
Towards the end of Section 5.1, the text reads:

    The timestamp-param is populated using format defined by
    the Simple Network Time Protocol in [RFC4330]

I think the text should say:

    The timestamp-param is populated using the Network Time Protocol
    timestamp format defined in RFC 1305 [RFC1305] and used by the Simple
    Network Time Protocol [RFC4330].

Additionally, the text does not say and should say how this value is
encoded. RFC 1305 defines a 64-bit for the NTP timestamp format.
Therefore, one can encoded in decimal, BCD, UTF-8, base64, or some other
format. Presumably UTF-8 should be used. Please add normative text
indicating how to encode this format.

Last thing: Since the NTP timestamp format is a 64-bit format, it can be
encoded as decimal (value 1 - 2^64-1), UTF-8, BCD, etc. I think the
example of the timestamp parameter in Section 5.1 is quite suspicious of
being wrong:

    timestamp=123456789



3) Section 6.4 provides procedures for untrusted UASes. The first (and
other) paragraph says:

    If the UAS receives an INVITE request with an OSPS-Tag of "BLV",
    dialog identification that matches an existing dialog, it MUST reject
    the request with a 403-Forbidden error code.

My comment: if the UAS is untrusted, why do you think it will implement
the "MUST reject" action? I doubt this will happen. Furthermore, I hope
the protocol is not compromised if untrusted UASes receive a P-DCS-OSPS
header field in a SIP request and ignore it, as one would do if a header
is not implemented.

So, if the network entities cannot trust that UASes will follow this
procedures, and if UASes may safely ignored, then I don't understand the
value of the MUST strength.

The same can be extrapolated to other normative text within the same section.



4) Last sentences in Section 7 reads:

    The P-DCS-Billing-
    Info header extension is used only on requests and responses between
    proxies and trusted User Agents.  It is never sent to, nor sent by,
    an untrusted UA.

Question: how can you guarantee that an untrusted UA will never sent this
header? The UA is untrusted, so, you don't trust what it does. I guess
the correct text should say: "It is never sent to an untrusted UA. It is
expected that untrusted UAs do not send this header".

The same applies to Section 7.2.


5) Text in the wrong section. Section 7.2 is devoted to "Procedures at an
Untrusted UAC". Therefor, I am expecting to find procedures that takes
place at an untrusted UAC, not elsewhere. However, the sentence in there
reads:

    "This header is never sent to an untrusted UAC ..."

Notice that the UAC is not the active subject (related to the title), but
just the passive object which receives the header. Therefore, I conclude
that this text, while correct, is misplaced. Please move it to the
correct section.

The same applies to the text in Sections 7.4, 8.2, 8.4 and perhaps
others. In Sections 8.2 and 8.4, the text is even written with normative
strength (surprise).

6) Second paragraph in Section 8 reads:

    The header may also contain the associated BCID ...

I guess the "may" should be a normative "MAY"

In this same paragraph, it would be nice to have short description of
what ccc-id and BCID are all about.


7) Inconsistent usage of normative text. Section 8.3 first paragraph
contains two instances of "may". I thought it is fine to have then
without normative strength, since they both are describing non-SIP
procedures that go beyond the scope of the document. However, the second
paragraph in the same Section 8.3 contains two instances of "MAY" for
similar stuff. As a minimum, all these instances should have the same
consistent treatment, either as normative or non-normative strength. I
don't have a strong opinion of which one to use.

The same applies to Section 8.6.1 second and third paragraphs; and
Section 8.6.2 second paragraph.


Nits:
-----
- Section 5.1: s/tel: URL/tel URL
- Although header fields in SIP are case-insensitive, I would suggest to
respect the original way of writing them. For example:
s/Refer-to/Refer-To across the document.
- Section 7.6.1: s/P-DCS-Billing- Info/P-DCS-Billing-Info
- Section 7.6.1: s/Contact: header/Contact header
- Section 7.6.2: s/Billing- Correlation-ID/Billing-Correlation-ID
- Title of Section 8:
  s/P-DCS-REDIRECT/P-DCS-Redirect
- Expand BCID at first usage.
- Section 8.5, first paragraph:
  s/of Service[PCDQOS].Otherwise/of Service[PCDQOS]. Otherwise
- Section 8.6, first paragraph:
  s/a proxy that received/a proxy that receives


/Miguel

--