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

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Feb 2007 18:14:12 +0000

Sharon,

Thanks for your comments. See my responses below. Where I have made changes
to the document these will be in the next version, whenever that should be
required (depends on chairs / ADs I guess).

John 

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]] 
> Sent: 21 February 2007 16:16
> To: [email-masked]
> Cc: Elwell, John; Dean Willis; Keith Drage; Cullen Jennings
> Subject: Gen-art review of draft-ietf-sip-connected-identity-04.txt
> 
> 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'.
[JRE]The abstract now reads:
"This document provides a means for a Session Initiation Protocol (SIP) User
Agent (UA) that receives a dialog-forming request 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. Because of retargeting
of a dialog-forming request (changing the value of the Request-URI), the UA
that receives it (the User Agent Server, UAS) can have a different identity
from that in the To header field. The same mechanism can be used to indicate
a change of identity during a dialog, e.g., because of some action in the
Public Switched Telephone Network (PSTN) behind a gateway. This document
normatively updates RFC 3261 (SIP)."
I didn't understand your bit about the typo, but hopefully that too is
fixed.

> 
> 2. Some terms are capitalized and some are in quotes. Are these two
> styles used consistently to mean two different things?
[JRE]I am not sure what your refer to. The items in quotes are the new
option tag "from-change" (I think the convention in SIP documents is to put
option tags in quotes) and the expressions "connected identity" and
"response identity", which are informal terms (maybe I could clarify by
saying 'commonly called...'). Capitalised things seem to include keywords
like "MUST" and SIP method names like "UPDATE", which are always
capitalised. Did you have any other examples in mind?

> 
> 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. 
[JRE] What is the appropriate formatting? I have seen indentations used in
this way in a number of other RFCs, e.g., RFC 3261, RFC 4474, RFC 3841.
Should I just remove the indent?

> 
> 4. In section 2, third paragraph, the two commas should be deleted.
[JRE] I regarded this as descriptive, rather than defining, and therefore
commas are appropriate. Let me know if you disagree stongly.

> 
> 5. In section 3, third paragraph, last sentence has 'to to'.
[JRE] OK

> 
> 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. 
[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.

> A number of the sentences 
> that follow
> in this section are also a bit loose.
[JRE] Without specifics I am not sure what to change.

> 
> 7. In each of the subsections of 4, the introduction sentence is
> incomplete. Text along the lines of 'is as follows:" should be added.
[JRE] I don't understand - there are no incomplete sentences there, apart
from the sub-section header, which are not intended to be sentence. Can you
give me an example of an offending sentence?

> 
> 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.
[JRE] Changed to  "the last identity indicated in the From header field".

> 
> 9. In section 4.4.1, the second paragraph is indented for no apparent
> reason.
[JRE] This is supposed to be a note (additional information), but I
neglected to prefix it with "Note". I await you response on 3 above.

> 
> 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.
[JRE] "of this document" added.

> 
> 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?
[JRE] Good catch. I have added "If any other final response is sent the UA
MUST NOT update the remote URI for this dialog."

> 
> 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.
[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.

> 
> 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.
[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?

> 
> 14. In section 6, all the instructions to IANA are one-time. 
> Should the
> RFC editor then delete the section before publishing?
[JRE] I don't think it is common practice to delete this information. For
example, see RFC 4474, RFC 4538, RFC 4488.

> 
> 15. In section 7, third paragraph, it wasn't obvious to me 
> how this was
> a security consideration.
[JRE] It is a security consideration because this RFC does not protect
against a rogue proxy that incorrectly retargets a request to a particular
destination.

> Sharon Chisholm
> Nortel 
> Ottawa, Ontario
> Canada

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

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 26 Feb 2007 20:22:14 +0100

listing it as <br>&gt; Informational. The draft itself seems to be merely informational, due <br>&gt; to the lack of normative statements.<br>Yes, it should be Informational. The proper status is in the tracker, so <br>I think we can leave it up to the RFC Editor here. I'll include a note <br>for them if the document doesn't end up being revised for some other reason.<br>&gt;<br>&gt; 2) Since the draft does not contain any normative statement <br>&gt; (capitalized MUST, MAY, SHOULD, etc.), I am not sure if Section 1.1 <br>&gt; and
 the reference to RFC 2119 makes sense. It could be safely deleted.<br>Agreed.<br>&gt;<br>&gt; 3) The split between normative and informative references is a bit <br>&gt; subjective. In my opinion, the only normative references here should <br>&gt; be [ieee802.15.4] and [RFC2460], I think the others are informative in <br>&gt; nature.<br>&gt;<br>&gt; Other than these nits, the draft looks good.<br>Thanks for the review. I'll capture these as Editor's notes for now.<br><br>- Mark<br>&gt;<br>&gt; /Miguel<br>&gt;<br>&gt;<br>&gt; _________<br></div></div><br></div></div></body></html>
--0-478689590-1172514116=:9491--

--=======02330376=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--=======02330376=--

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Mon, 26 Feb 2007 20:22:14 +0100

In regard to item 3, the SIP WG has a habit of indenting text which is
of less significance and which does not contain normative text. This
seems to go back to the original RFC 2543.

This corresponds to the use of NOTE text in other SDOs, and given that
many SDOs do normatively reference SIP specifications, it seems useful
to continue this practice.

In regard to item 14, least in SIP the documents have been published
with this information. There is no SIP specific policy on this, but I
certainly understood this was general practice in IETF generally since
the new clause was introduced.

regards

Keith

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: 21 February 2007 18:14
To: Sharon Chisholm; [email-masked]
Cc: Dean Willis; Drage, Keith (Keith); Cullen Jennings
Subject: RE: Gen-art review of draft-ietf-sip-connected-identity-04.txt

Sharon,

Thanks for your comments. See my responses below. Where I have made
changes
to the document these will be in the next version, whenever that should
be
required (depends on chairs / ADs I guess).

John 

[JRE]The abstract now reads:
"This document provides a means for a Session Initiation Protocol (SIP)
User
Agent (UA) that receives a dialog-forming request 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. Because of
retargeting
of a dialog-forming request (changing the value of the Request-URI), the
UA
that receives it (the User Agent Server, UAS) can have a different
identity
from that in the To header field. The same mechanism can be used to
indicate
a change of identity during a dialog, e.g., because of some action in
the
Public Switched Telephone Network (PSTN) behind a gateway. This document
normatively updates RFC 3261 (SIP)."
I didn't understand your bit about the typo, but hopefully that too is
fixed.

[JRE]I am not sure what your refer to. The items in quotes are the new
option tag "from-change" (I think the convention in SIP documents is to
put
option tags in quotes) and the expressions "connected identity" and
"response identity", which are informal terms (maybe I could clarify by
saying 'commonly called...'). Capitalised things seem to include
keywords
like "MUST" and SIP method names like "UPDATE", which are always
capitalised. Did you have any other examples in mind?

> begin with the word 'Note'. This doesn't seem appropriate [email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

In regard to item 3, the SIP WG has a habit of indenting text which is
of less significance and which does not contain normative text. This
seems to go back to the original RFC 2543.

This corresponds to the use of NOTE text in other SDOs, and given that
many SDOs do normatively reference SIP specifications, it seems useful
to continue this practice.

In regard to item 14, least in SIP the documents have been published
with this information. There is no SIP specific policy on this, but I
certainly understood this was general practice in IETF generally since
the new clause was introduced.

regards

Keith

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: 21 February 2007 18:14
To: Sharon Chisholm; [email-masked]
Cc: Dean Willis; Drage, Keith (Keith); Cullen Jennings
Subject: RE: Gen-art review of draft-ietf-sip-connected-identity-04.txt

Sharon,

Thanks for your comments. See my responses below. Where I have made
changes
to the document these will be in the next version, whenever that should
be
required (depends on chairs / ADs I guess).

John 

[JRE]The abstract now reads:
"This document provides a means for a Session Initiation Protocol (SIP)
User
Agent (UA) that receives a dialog-forming request 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. Because of
retargeting
of a dialog-forming request (changing the value of the Request-URI), the
UA
that receives it (the User Agent Server, UAS) can have a different
identity
from that in the To header field. The same mechanism can be used to
indicate
a change of identity during a dialog, e.g., because of some action in
the
Public Switched Telephone Network (PSTN) behind a gateway. This document
normatively updates RFC 3261 (SIP)."
I didn't understand your bit about the typo, but hopefully that too is
fixed.

[JRE]I am not sure what your refer to. The items in quotes are the new
option tag "from-change" (I think the convention in SIP documents is to
put
option tags in quotes) and the expressions "connected identity" and
"response identity", which are informal terms (maybe I could clarify by
saying 'commonly called...'). Capitalised things seem to include
keywords
like "MUST" and SIP method names like "UPDATE", which are always
capitalised. Did you have any other examples in mind?

> begin with the word 'Note'. This doesn't seem appropriate for an RFC. 
[JRE] What is the appropriate formatting? I have seen indentations used
in
this way in a number of other RFCs, e.g., RFC 3261, RFC 4474, RFC 3841.
Should I just remove the indent?

> 4. In section 2, third paragraph, the two commas should be deleted.
[JRE] I regarded this as descriptive, rather than defining, and
therefore
commas are appropriate. Let me know if you disagree stongly.

[JRE] OK

> like a standards-track RFC to me. 
[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.

> incomplete. Text along the lines of 'is as follows:" should be added.
[JRE] I don't understand - there are no incomplete sentences there,
apart
from the sub-section header, which are not intended to be sentence. Can
you
give me an example of an offending sentence?

> header field" to ensure no ambiguity.
[JRE] Changed to  "the last identity indicated in the From header
field".

> response", but what if it doesn't? Are there no expectations then?
[JRE] Good catch. I have added "If any other final response is sent the
UA
MUST NOT update the remote URI for this dialog."

> or making a prediction about what other features might be supported by
[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.

[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?

> RFC editor then delete the section before publishing?
[JRE] I don't think it is common practice to delete this information.
For
example, see RFC 4474, RFC 4538, RFC 4488.

> 
> 15. In section 7, third paragraph, it wasn't obvious to or an RFC. 
[JRE] What is the appropriate formatting? I have seen indentations used
in
this way in a number of other RFCs, e.g., RFC 3261, RFC 4474, RFC 3841.
Should I just remove the indent?

> 4. In section 2, third paragraph, the two commas should be deleted.
[JRE] I regarded this as descriptive, rather than defining, and
therefore
commas are appropriate. Let me know if you disagree stongly.

[JRE] OK

> like a standards-track RFC to me. 
[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.

> incomplete. Text along the lines of 'is as follows:" should be added.
[JRE] I don't understand - there are no incomplete sentences there,
apart
from the sub-section header, which are not intended to be sentence. Can
you
give me an example of an offending sentence?

> header field" to ensure no ambiguity.
[JRE] Changed to  "the last identity indicated in the From header
field".

> response", but what if it doesn't? Are there no expectations then?
[JRE] Good catch. I have added "If any other final response is sent the
UA
MUST NOT update the remote URI for this dialog."

> or making a prediction about what other features might be supported by
[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.

[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?

> RFC editor then delete the section before publishing?
[JRE] I don't think it is common practice to delete this information.
For
example, see RFC 4474, RFC 4538, RFC 4488.

[JRE] It is a security consideration because this RFC does not protect
against a rogue proxy that incorrectly retargets a request to a
particular
destination.

me 
[JRE] It is a security consideration because this RFC does not protect
against a rogue proxy that incorrectly retargets a request to a
particular
destination.