Subject: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Aug 2012 16:56:55 -0500

Summary: There are a few issues to address before progressing to IETF 
LC. I'm putting the document into revised ID needed to address at least 
the IANA points below.

The primary issue is with the instructions to IANA on creating the new 
trees and the registration template used to put things in those trees.

Sections 7.3.2 and 7.3.3 don't currently define the format of an entry 
in the trees in the new subregistry. This needs to be clearly defined, 
and the sections need to explicitly indicate that the trees are 
initially empty.

The template in section 8 was adapted from RFC2506, but it needs more 
tweaks and it needs to match whatever format is defined above.

   * We don't need a separate list for reviewing these requests. We 
certainly don't need a list at apps.ietf.org. The normal process for 
submitting a request for the global tree should be submitting the 
template by email to [email-masked], and for the sip tree, the normal 
process would be submitting an Internet-Draft to the IESG.

   * IANA is currently using a different for media feature tag 
registrations. It's available at 
<http://www.iana.org/protocols/media-feature-tag-template.txt>. If we 
really need to follow that registration format, please start from this 
template. But do we need all this information in the registry?

Other major issues:

1) Should the expert reviewer be explicitly required to consider 
security issues as part of that review? (see section 4.6 of 
<https://datatracker.ietf.org/doc/draft-ietf-appsawg-media-type-regs/> 
for example).

2) The security considerations section claims that the aspects of the 
considerations in rfc3840 that apply to end user devices don't apply 
here since these are not typically used to convey information about end 
user devices. "Not typically" is weak. Can this sentence be made more 
specific about what concerns do and don't apply? The concerns in 3840 
about influencing application behavior, and in 2506 about providing 
information that can be used to exploit implementation weakeness at the 
elements that do provide these tags should be reflected here.

3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in 
section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE will get 
back to the UA that sent the subscribe. The information that creates the 
other dialogs for it must appear in the immediate NOTIFYs. Is there a 
requirement for the end accepting a subscription to use the same feature 
capabilities in the 200 OK to the subscription and in the immediate NOTIFY?

4) Similarly, consider clarifying whether UPDATES nested within an 
INVITE constrained to keep the same feature capability indicators as in 
the INVITE?

Minor Issues:

Section 4.3.4: A SIP Stand-Alone Transaction is by definition a 
non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I 
suggest s/18x or 2xx/2xx/ in this section.

The two places where you talk about overriding registration policy in 
section 5.2 isn't quite right. We should be specific that we're only 
talking about SIP header field parameters. In the first case, we're 
using IETF Consensus (this document) to delegate parameters starting 
with a 'g.' for _this_ header field to a policy of Expert Review. In the 
second case, there's no overriding at all - registrations use IETF 
Consensus there.  Here's a stab at something more accurate. Maybe others 
can come up with something better. I suggest replacing the first 
instance with "Note that the general policy for registering SIP header 
field parameters is 'IETF Consensus' as specified in [RFC3968]. This 
document delegates the registration of parameters to the Feature-Caps 
header field starting with 'g.' to a policy of 'Expert Review'", and 
deleting the second instance.

The NOTE in section 6.2.1 is not useful unless you know the history of 
that led to the syntax in 3840 and 3841. I suggest replacing it with 
'NOTE: The "*" value is present in order to follow the guidelines for 
syntac in [RFC4485] and to maintain a consistent format with [RFC3840] 
and [RFC3841].'

Nits:

There is a mix of "xxx" "XXX" and "XXXX" to indicate to the RFC Editor 
that the number assigned to this RFC should appear here. Please choose 
one format and make the instructions to the RFC Editor for making the 
substitution clear.

Section 4.1: I suggest s/in a non-priority order, and any/as an 
unordered set. Any/

Why is the second paragraph of 4.1 in the introduction to this section? 
It's getting pretty deep into specification detail. It would fit better 
at the end of 4.2.1.

Section 4.2.2: The beginning of paragraphs 2 an 4 start "When a UA", but 
don't mean any UA. They rely on the context of the previous paragraphs 
to scope it to a UA that is part of a B2BUA. To help avoid confusion I 
suggest changing both of these this way: s/When a UA/When such a UA/

The NOTE in section 4.3.1 is confusing. What's the distinction between a 
SIP method and a request type that's important here? What methods does 
this specification leave the behavior undefined for. I don't think there 
are any except perhaps CANCEL. Is the note important to keep?

Section 4.3.2: s/is no long supported/is no longer supported/

Section 4.3.3: The NOTE says support applies to a Contact. It doesn't 
really - it applies to messages sent with that Contact as the target 
perhaps.

Section 5.1 has some edititis. Parts of it look like a "structure of 
this document" description, which should be in the Introduction to the 
document. It's especially odd that it points to earlier in the document. 
I suggest either deleting the last 3 1-sentence paragraphs, or moving 
them to section 1, and making the document roadmap more complete.

Section 5.2.2: I suggest s/ensure that the feature capability indicator 
meets/ensure that the definition of the feature capability indicator meets/

Section 5.3.3: STRONGLY RECOMMENDED isn't 2119. I suspect some 2119 
purists will object that this sentence doesn't need 2119 at all. I 
suggest at least changing STRONGLY to lower-case, and consider changing 
both words.

Section 7.3.2: s/through the Expert Review policies/through the Expert 
Review policy/

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Aug 2012 19:00:56 -0400

Thanks Robert!

I'm going to defer to Christer on most of this, but want to comment on a 
couple of things:

> template. But do we need all this information in the registry?

I find this one, and the old one, a bit strange.
The template asks for a bunch of information that IANA doesn't capture 
in its subregistry. Presumably that info could be used by the expert 
reviewer, but it wouldn't be available to users. In practice it appears 
that all the things registered have a reference to a document that might 
contain the same info. (Or it could contain conflicting info.)

So I'm thinking we need to do better than has been done for media 
feature tags.

> INVITE constrained to keep the same feature capability indicators as in

I presume you mean an UPDATE to a before the final response to the 
dialog establishing INVITE is received.

It seems that UPDATES after the dialog is established aren't permitted 
to carry the header.

> deleting the second instance.

You and I already talked about this, but I realize now that we have to 
work on the wording more. The issue is that from a sip header field 
perspective the parameter includes the "+", and its parameters that 
begin with "+" that we are reserving in the header field parameter registry.

But the "+" isn't part of the name of the feature capability indicator.

So we are delegating parameters that start with "+g." to the expert 
review procedure.

And while things in the sip tree (things beginning with "+sip.", while 
still requiring IETF consensus, will still go in the sip tree, not as 
individuals in the sip header fields parameter registry. But maybe we 
don't need to "note" this part.

> one format and make the instructions to the RFC Editor for making the

I recently discovered that xml2rfc has '&rfc.number;' to get this value, 
though I haven't tried it yet. Apparently it expands to XXXX for drafts.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 14:14:47 +0200

Hi Paul,

>> INVITE constrained to keep the same feature capability indicators as 
>> in the INVITE?
>
> I presume you mean an UPDATE to a before the final response to the dialog establishing INVITE is received.
>
> It seems that UPDATES after the dialog is established aren't permitted to carry the header.

Where do you read that?

The text says that the header field can be carried in target refresh requests.

>> with a 'g.' for _this_ header field to a policy of Expert Review. In 
>> the second case, there's no overriding at all - registrations use IETF 
>> Consensus there.  Here's a stab at something more accurate. Maybe 
>> others can come up with something better. I suggest replacing the 
>> first instance with "Note that the general policy for registering SIP 
>> header field parameters is 'IETF Consensus' as specified in [RFC3968]. 
>> This document delegates the registration of parameters to the 
>> Feature-Caps header field starting with 'g.' to a policy of 'Expert 
>> Review'", and deleting the second instance.
>
> You and I already talked about this, but I realize now that we have to work on the wording more. The issue is that from a sip 
> header field perspective the parameter includes the "+", and its parameters that begin with "+" that we are reserving in the header field parameter registry.
>
> So we are delegating parameters that start with "+g." to the expert review procedure.
>
> And while things in the sip tree (things beginning with "+sip.", while still requiring IETF consensus, will still go in the sip tree, not as individuals in the sip header fields parameter registry. But maybe we don't need to "note" this part.

I am not sure I understand. The reviewer will check the feature capability indicator. The "+" is a SIP coding issue. The draft even says that the leading "+" is not part of the registration.

> I recently discovered that xml2rfc has '&rfc.number;' to get this value, though I haven't tried it yet. Apparently it expands to XXXX for drafts.

I'll take a look :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Aug 2012 13:50:29 -0400

>> It seems that UPDATES after the dialog is established aren't permitted to carry the header.

Oops. Sorry. At the time I wrote that I missed the part about being 
allowed in target refresh requests.

> I am not sure I understand. The reviewer will check the feature capability indicator. The "+" is a SIP coding issue. The draft even says that the leading "+" is not part of the registration.

I brought it up because when you look at the header as a whole, the 
*parameter* does include the "+". That is pertinent to the discussion of 
which parameters are being delegated. What do you think of:

"Note that the general policy for registering SIP header field 
parameters is 'IETF Consensus' as specified in [RFC3968]. This document, 
itself subject to 'IETF Consensus' defines a new IANA procedure for 
registration of all parameters beginning with "+" of the "Proxy-Feature" 
sip header field. The registration of those parameters beginning with 
"+" followed by "g." are governed by 'Expert Review' policy, while 
others are 'IETF Consensus'.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Aug 2012 20:36:14 +0200

Hi,

> others are 'IETF Consensus'.

Just to make sure I understand, where do you suggest to add this note, and what text would it replace? :)

Regards,

Christer