Subject: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 May 2012 11:10:38 -0400

I am issuing a WGLC for:

draft-ietf-sipcore-proxy-feature-02
   (http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-02)

The WGLC will conclude at 23:59 UTC on June 8, 2012.

(I'm giving it three weeks because there are a lot of things going on at 
this time - a 3gpp meeting, some holidays, etc.)

Note that this is intended to satisfy our milestone: Mechanism to 
indicate proxy capabilities to both endpoints and other intermediaries 
in the path of a REGISTER transaction or dialog-forming transaction to 
IESG (PS)

I'm looking for volunteers to perform a careful review of this document. 
It would be especially good to have participation of people who haven't 
previously been closely involved. Please inform me and Adam if you are 
able to do a careful WGLC review.

	Thanks,
	Paul (as co-chair)

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 21 May 2012 09:25:47 +0000

Paul,

I volunteer to review the draft.

Regards,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, May 18, 2012 11:11 AM
To: SIPCORE
Subject: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

I am issuing a WGLC for:

	Thanks,
	Paul (as co-chair)
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Lili Yang_lili <[email-masked]>
Date: Mon, 28 May 2012 08:59:05 +0000

Hello Paul,

I am Lili Yang from Huawei. 
I volunteer to review the draft. 

Best regards,
Lili
华为技术有限公司 Huawei Technologies Co., Ltd.

Phone: +86-755-28422556
Mobile:+86-13632632065
Email: [email-masked]
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com 

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any use of the 
information contained herein in any way (including, but not limited to, total or partial 
disclosure, reproduction, or dissemination) by persons other than the intended 
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, May 18, 2012 11:11 PM
To: SIPCORE
Subject: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

I am issuing a WGLC for:

	Thanks,
	Paul (as co-chair)

---

From: Shida Schubert <[email-masked]>
Date: Wed, 30 May 2012 16:39:32 +0900

Here is my review for draft-ietf-sipcore-proxy-feature.

0. Spec name

I think as it is no longer about proxy-feature, may be the 
draft name or spec name should change to reflect what the 
draft is doing.. "Registration of feature-cap tree and guideline"

1. General

Please be consistent with the terms used. It is 
confusing when so many of similar terms are used for 
what this draft tries to define. 

e.g. 

SIP feature cap
SIP feature caps
SIP Feature Cap
Feature-caps
Feature-Caps
Feature-Cap header field

Also 

"features" alone and "features and capabilities" are 
used, I would stick with one when you are trying to 
say the same things. 

2. Abstract

Abstract is slightly confusing..

Why aren't we using the term SIP intermediary, there 
was probably a discussion taken place in the ML but 
SIP entity is rather confusing(I am assuming it is because 
it includes B2BUA??).. If you insist on using 
SIP entity then I would rephrase the abstract to say 
something along the line of...

"This specification creates a new IANA registry, "SIP Feature Cap
Registry" for registering "SIP feature caps" which is used by SIP 
entities not represented in the contact header to indicate support 
of features and capabilities.

This specification also defines a new SIP header field, Feature-Caps 
header field, to convey SIP feature caps."

3. Introduction (Section 1)

I would fix the introduction in a similar fashion to that of abstract. 

4. Section 4.2.1 

The sentence about "other registration tree being out of scope, I think 
is unnecessary here.. unless you want to explicitly state this.."

5. Section 4.2.3 

Last paragraph, last sentence, should the must be published be MUST be published?

6. Section 4.4.1 second paragraph

What procedure defined in this spec is this talking about? Can you elaborate? 

7. Section 4.4.5 second paragraph

Add "message" in front of the flows to make it "example message flow" to make 
it consistent with the first paragraph. 

8. Section 5.1 first paragraph

Old " to convey support of features and capabilities, using SIP feature caps."

New "to convey support of features and capabilities, by setting SIP feature caps."

9. Section 5.1 NOTE:

Old "It is not possible to convey the address of the SIP entity as a
Feature-Caps header field parameter."

New "It is not possible to convey the address of the SIP entity as part of 
a Feature-Caps header field parameter." 

What does the following sentence to above mean? Are you saying that 
you could in fact define a way to convey the address of the entity which 
indicated support of feature/capabilities by defining a method to do so in 
the sip feature-cap spec?

10. Section 5.1 last paragraph

foo;bar and bar;foo having the same semantics seems to 
conflict with the following paragraph where it is indicated that 
the order of the feature-cap header field indicates the closeness 
of the entity supporting the features. 

11. Section 5.2.1 last paragraph

I am assuming that the text is trying to mandate entity adding SIP 
Feature-Caps header to add a "new" header on top of the existing 
one if there is and prohibit SIP entity wanting to indicate features 
and capabilities from adding only the value.. Am I correct? If so 
this I think should be explicitly stated.

12.  Section 5.2.1 last paragraph, last sentence.

OLD : "the SIP feature caps in the
top-most Feature-Caps header field will represent the supported
features "closest" to the entity."

NEW: "the SIP feature caps in the
top-most Feature-Caps header field will represent the
features supported by the "closest" entity.

13. Section 5.2.2 B2BUA behavior

Isn't it clearer to just say B2BUA where UA is being used?

14. Section 5.2.4 Proxy behavior

5.2.1 is about UA and Proxy behavior, if 5.2.1 is a general 
behavior of a SIP entity, may be the title should change to 
general behavior or something.

15. Section 5.3.2 SIP Dialog Paragraph 3

Change "or a target" to "in a target"

Change "long supported" to "longer supported"

16. IANA section

- It is a little confusing how in the registration policy, 
"+" is not used but it is mandatory when it is set. I have 
no problem with it but may be it should be noted in the 
registration policy that although it is not registered with 
"+", it is prepended to the fcap-name when used.

Regards
Shida

On May 19, 2012, at 12:10 AM, Paul Kyzivat wrote:

> (I'm giving it three weeks because there are a lot of things going on at this time - a 3gpp meeting, some holidays, etc.)
> 
> Note that this is intended to satisfy our milestone: Mechanism to indicate proxy capabilities to both endpoints and other intermediaries in the path of a REGISTER transaction or dialog-forming transaction to IESG (PS)
> 
> I'm looking for volunteers to perform a careful review of this document. It would be especially good to have participation of people who haven't previously been closely involved. Please inform me and Adam if you are able to do a careful WGLC review.
> 
> 	Thanks,
> 	Paul (as co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 May 2012 10:46:24 -0400

Shida,

Thanks for the very thorough review. Its good to get a fresh 
perspective. I'll wait for Christer to comment on the details.

	Thanks,
	Paul