Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-03 [was: WGLC for draft-ietf-sipcore-proxy-feature-02]

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jun 2012 14:45:52 +0200

Hi,

I've submitted a new version (-03) of the draft, based on the WGLC comments.

All comments should be addressed, but I ask the people who gave comments to double check :)

Thank You!

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 10. kesäkuuta 2012 21:16
To: [email-masked]
Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-proxy-feature-02

The WGLC for draft-ietf-sipcore-proxy-feature-02.
Thank you to those of you who provided comments.

I didn't see any major, or unsolvable issues. Christer indicated to me that he is going to issue a new version that addresses the WGLC comments received. Then I'll be working with the ADs on advancing this.

	Thank you,
	Paul (as co-chair)

On 5/18/12 5:10 PM, Paul Kyzivat wrote:
> 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)
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jun 2012 22:52:55 +0200

> All comments should be addressed, but I ask the people who gave comments to double check :)

Christer: I must appologize for finding things now that I should have 
found myself during WGLC. Mostly superficial, but for the last one.

Name of the IANA registry:

I think we should give this careful thought, perhaps including the IANA 
person in the discussion. I know I frequently have difficulty finding 
very common registries because I can't remember what they are called.
Looking the root of the iana registry (http://www.iana.org/protocols) I 
find that there is a section labeled "Session Initiation Protocol (SIP) 
Parameters". And under that are "Header Fields", "Resource-Priority 
Priority Values", ...

Some of the names there are good, and others not so good.

I also see that there is a section called "Media Feature Tags", and 
under it "features.global-tree", features.sip-tree", ...

I think we want this registry included in the SIP Parameters section. 
And I think an easy to find name there might be "Proxy-Feature 
sip-tree". I don't know if anything must be done to get this into the 
proper section. I guess we ask IANA that.

Alternatively, I guess we could consider adding 
"proxy-features.sip-tree" to the Media Feature Tags section.

Either way, we need to find out what to say to get IANA to do it that way.

Naming of 4.2.2 vs. 4.2.3:

These sections define the two trees. 4.2.2 clearly identifies its tree, 
  but 4.2.3 does not. I think its section name should be "SIP Tree".

Security Considerations:

As I look at it, I realize that this was just a placeholder.

    Feature caps can provide sensitive information about a SIP entity.
    RFC 3840 cautions against providing sensitive information to another
    party.  Once this information is given out, any use may be made of
    it.

Its nice that 3840 has cautions, but how does that affect *this* draft?

Perhaps the original intent was to reuse the security considerations 
from 3840 by reference? I don't think that will fly.

I think the security considerations from 3840 might be mined/adapted to 
produce something comparable for here. But its a non-trivial adaptation.

I'm sorry to have found this so late. But this will be ripped apart by 
the IESG if it isn't dealt with. Even once something meaningful is put 
in here we are likely to get some comments about it. (They are very hard 
to avoid.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jun 2012 11:31:14 +0200

Hi,

> "proxy-features.sip-tree" to the Media Feature Tags section.

I don't think we should do that, as we previously decided not to use media feature tags for this.

> Either way, we need to find out what to say to get IANA to do it that way.

I suggest that the draft requests IANA to create a new sub directory under the "SIP Parameters" registry.

We'll then deal with the detail once the draft reaches IANA.

So, the text could look like:

"7.2. SIP Feature Caps Trees

   This specification creates a new sub registry to the IANA "Session Initiation Protocol (SIP) Parameters"
   Protocol Registry, per the guidelines in RFC 5226 [RFC5226]. 
   The name of the sub directory is "SIP Feature Caps Trees".

7.2.1  Global Registration Tree

   This specification creates a new feature cap tree in the IANA "SIP Feature Caps Trees" registry.  
   The name of the tree is "Global Feature Cap Registration Tree", and its leading facet
   is "g.".  It is used for the registration of feature caps.
   
   The addition of entries into this tree occurs through the Expert
   Review policies, as defined in RFC 5226 [RFC5226].  A designated area
   expert will review the proposed SIP feature cap, and consult with
   members of related mailing lists.  The information required in the
   registration is defined in Section 4.3 of RFC XXX.
   
   Note that all feature caps registered in the SIP tree will have names
   with a leading facet "g.".  No leading "+" is used in the
   registrations in any of the media feature tag trees.

7.2.2  SIP Feature Cap Registration Tree

   This specification creates a new feature cap tree in the IANA "SIP Feature Caps Trees" registry
   The name of the tree is "Feature Cap Registration Tree", and its leading facet is "sip.".  It is used for
   the registration of feature caps.
   
   The addition of entries into this tree occurs through the IETF
   Consensus, as defined in RFC 5226.  This requires the publication of
   an RFC that contains the registration.  The information required in
   the registration is defined in Section 4.3 of RFC XXX.
   
   Note that all feature caps registered in the SIP tree will have names
   with a leading facet "sip.".  No leading "+" is used in the
   registrations in any of the media feature tag trees."

---------------------------

> but 4.2.3 does not. I think its section name should be "SIP Tree".

I agree. I'll change that.

(I'll do the same change in the IANA considerations section).

---------------------------

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 13 Jun 2012 17:54:48 +0200

Hi,

> from 3840 by reference? I don't think that will fly.

That was the intention, yes.

> in here we are likely to get some comments about it. (They are very hard

So, instead of simply refering to 3840, I suggest some explicit text, based on the 3840 text.

Note, however, that most of the 3840 security issues apply to UAs. In addition, the 3841 issue
of 3840 does not apply, as the 3841 mechanism cannot be used with feature caps.

Suggested text:

"8.  Security Considerations

   The security issues for feature caps are similar to the ones defined
   in RFC 3840 for media feature tags. However, as feature caps will
   typically not be used to convey capability information of end-user devices,
   those aspects of RFC 3840 do not apply to feature caps.

   In addition, the RFC 3840 security issue regarding an attacker using the 
   SIP caller preferences extension [ref-to-3841] in order to affect
   routing decisions does not apply, as the mechanism is not defined to
   be used with feature caps.

   Feature caps can provide capability and characteristics information 
   about the SIP entity, some of which might be sensitive. The 
   Feature-Caps header field does not convey address information about 
   SIP entities. However, individual feature caps might provide address 
   information as feature cap values. Therefor, mechanisms for 
   guaranteeing confidentiality and authenticity SHOULD be provided."

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Jun 2012 05:02:59 +0200

Hi Christer,

A few comments inline.

	Thanks,
	Paul

> I don't think we should do that, as we previously decided not to use media feature tags for this.

Fine.

> We'll then deal with the detail once the draft reaches IANA.

ok

>     The name of the sub directory is "SIP Feature Caps Trees".

Because the header name is Proxy-Feature, ISTM that people looking to 
register new values are likely to be looking for that name. So it would 
be good for that to be in there somewhere. Also, since its under the SIP 
parameters registry, I don't think it needs to have "SIP" in its name. 
When I look at the registry some do have SIP and some don't, but the 
ones without seem more natural. So perhaps:

Proxy-Feature trees, or
Proxy-Feature Feature Caps trees

I just know from experience that it can be hard to find something in the 
iana registries, so making it easy to search for is helpful.

>     The name of the tree is "Feature Cap Registration Tree",

No, that isn't its name. It is "SIP Feature Cap Registration Tree"

>     and its leading facet is "sip.".  It is used for

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jun 2012 08:42:31 +0200

Hi,

> Because the header name is Proxy-Feature, ISTM that people looking to register new values are likely to be looking for that name. So it would be good for that to be in there somewhere. Also, since its under the SIP parameters registry, I don't think it 
> needs to have "SIP" in its name. 
> When I look at the registry some do have SIP and some don't, but the ones without seem more natural. So perhaps:
>
> Proxy-Feature trees, or
> I just know from experience that it can be hard to find something in the iana registries, so making it easy to search for is helpful.

Ok.

I'll change to "Proxy-Feature Feature Caps trees", as suggested.

-------------

> No, that isn't its name. It is "SIP Feature Cap Registration Tree"

Correct. I'll fix that.

Regards,

Christer