Subject: [Gen-art] Gen-art review of draft-ietf-sip-connected-identity-04.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 21 Feb 2007 11:16:21 -0500

I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: Connected Identity in the Session Initiation Protocol (SIP)
Summary: This document is ready for publication, but has the following
nits that should be resolved.

Comments
---------

1. The abstract is a bit awkward. It would read better if it started
with "This document provides a means for that User Agent (UA) to supply
its identity to the peer UA by means of a request in the reverse
direction and for that identity to be signed by an Authentication
Service." instead of having this sentence buried in the middle. That the
typo in that sentence though with the 'for that'.

2. Some terms are capitalized and some are in quotes. Are these two
styles used consistently to mean two different things?

3. The document seems to have the habit of indenting paragraphs that
begin with the word 'Note'. This doesn't seem appropriate for an RFC. 

4. In section 2, third paragraph, the two commas should be deleted.

5. In section 3, third paragraph, last sentence has 'to to'.

6. In section 3, fifth paragraph, has the sentence 'It is assumed that
deployed proxies will already be able to tolerate a change of URI, since
this has been expected for a considerable time.' which doesn't sound
like a standards-track RFC to me. A number of the sentences that follow
in this section are also a bit loose.

7. In each of the subsections of 4, the introduction sentence is
incomplete. Text along the lines of 'is as follows:" should be added.

8. In section 4.3, second paragraph, replace "that last indicated in the
>From header field " with "that last identity indicated in the From
header field" to ensure no ambiguity.

9. In section 4.4.1, the second paragraph is indented for no apparent
reason.

10. In section 4.4.1, third paragraph, refers to section 4.4.2 but also
refers to RFC 3261. It should be clarified whether that section number
is in this document or the other RFC.

11.  In section 4.4.2, second paragraph, it says "if the UA sends a 2xx
response", but what if it doesn't? Are there no expectations then?

12. In section 4.4.5, second paragraph, "Note that when UAs conform with
this specification the Authentication Service will normally be able to
authenticate the sender of a request as being the entity identified in
the From header field and hence will be able provide a signature for
this identity.". It wasn't clear whether this was defining a requirement
or making a prediction about what other features might be supported by
the implementation.

13. In section 4.7, the proxy itself advertises the from-change feature?
If so, this could be stated more clearly and earlier in the section. The
second paragraph is not parsable.

14. In section 6, all the instructions to IANA are one-time. Should the
RFC editor then delete the section before publishing?

15. In section 7, third paragraph, it wasn't obvious to me how this was
a security consideration.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Feb 2007 08:49:37 +0100

On 2007-02-23 01:02, Cullen Jennings wrote:

> Brian, could you do me a favor and have a look at these and if you think any of them need to be DISCUSS, let me know and I will try and deal with DISCUSS level issues quickly. This is an important draft that I want to move along as fast as possible. 

There are a few of Sharon's points that look like necessary
clarifications to me. I wonder whether a new draft in the
next day or two won't be simplest. Below:

On 2007-02-21 19:14, Elwell, John wrote:

> [JRE] Standards track RFCs do not need to contain only normative statements
> and, I believe, can give reasons for things. I guess I could make this
> particular sentence a note, but in view of your comment above about notes I
> await your feedback. Or is it just the clause "since this has been expected
> for a considerable time", which I guess could be deleted if that would help.

But this paragraph doesn't seem to completely tell me what
to code. I agree with Sharon that the language needs to be more
prescriptive, even if it's not normative. Tell the programmer
what to do :-)

> [JRE] Good catch. I have added "If any other final response is sent the UA
> MUST NOT update the remote URI for this dialog."

Yes, this is needed.

> 
> 12. In section 4.4.5, second paragraph, 

Actually s 4.5

>> "Note that when UAs conform with
> [JRE] It is just making a prediction (since if the UA does not conform to
> this specification the Authentication Service will not in general be able to
> perform this authentication). It is not clear what change, if any, I should
> make.

I'm worried by the "normally". What's the abnormal case? Does
it matter? If you can resolve that, I think it will be OK.

> [JRE] No, there is not intention to state that the proxy advertises this
> feature. Perhaps I should change the last bit to say "Supported: from-change
> is indicated in the received dialog forming request." Does the addition of
> the word "received" help?

I agree with Sharon. The second paragraph just doesn't make
sense to me. Who is sending 'Supported: from-change' to who?

>> RFC editor then delete the section before publishing?

IMHO, no, this should definitely be preserved for the record.

    Brian