Subject: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Aug 2012 16:01:49 -0400

Sorry to do this again, but we need to do another WGLC on 
draft-ietf-sipcore-proxy-feature-08.

The WGLC will run for a week. It will conclude at 23:59 UTC on Monday, 
September 3, 2012. (A week should be enough considering the nature of 
the changes since the last WGLC.)

This covers changes since the last WGLC, which was for the -02 version. 
Those changes were to cover things I found while writing the document up 
for submission to the iesg, and things found by Robert Sparks in his AD 
review. Most of those things were editorial, but some of them were quite 
heavy editorial, such as rearranging sections of the document. (This 
causes the diff to version -02 to be largely worthless.)

There was one significant change that isn't editorial. We changed the 
review policy for registering new feature capability indicators in the 
global tree from Expert Reveiw to Specification Required. This isn't a 
big change, since we were always requiring a specification. But it is a 
better fit. (This doesn't require an RFC, only a specification that can 
be referenced permanently.)

Please look at this and then indicate you acceptance or issues here on 
the mailing list. We really need responses to indicate that it has been 
reviewed.

Some helpful links:

The draft version being reviewed:
http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08

Diff from version -06 (recent changes):
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-08.txt;url1=draft-ietf-sipcore-proxy-feature-06.txt

Diff from version -02 (the subject of the last WGLC):
http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-08.txt;url1=draft-ietf-sipcore-proxy-feature-02.txt

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

---

From: Atle Monrad <[email-masked]>
Date: Tue, 28 Aug 2012 07:45:20 +0200

Paul, all

I've read through draft-ietf-sipcore-proxy-feature-08 and provided Christer et.al. with a number of proposed nits plus a couple of other wordings that seems to need corrections aswell. 

Generally I'm fine with this version of the draft.

It seems to me that the draft has progressed as indicated by the previous comments given, thus I hope that the draft -08 can be accepted and with some polishing can progress towards completion rather soon.

We have features in 3GPP Rel-10 and 3GPP Rel-11 that are waiting for completion of this draft.

Thanks
/atle

________________________________ 

Atle Monrad
3GPP CT Chairman
Standardization and Regulation,
Group Function Technology and Portfolio Management 
Ericsson

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 27. august 2012 22:02
To: SIPCORE
Subject: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08

Sorry to do this again, but we need to do another WGLC on draft-ietf-sipcore-proxy-feature-08.

The WGLC will run for a week. It will conclude at 23:59 UTC on Monday, September 3, 2012. (A week should be enough considering the nature of the changes since the last WGLC.)

This covers changes since the last WGLC, which was for the -02 version. 
Those changes were to cover things I found while writing the document up for submission to the iesg, and things found by Robert Sparks in his AD review. Most of those things were editorial, but some of them were quite heavy editorial, such as rearranging sections of the document. (This causes the diff to version -02 to be largely worthless.)

There was one significant change that isn't editorial. We changed the review policy for registering new feature capability indicators in the global tree from Expert Reveiw to Specification Required. This isn't a big change, since we were always requiring a specification. But it is a better fit. (This doesn't require an RFC, only a specification that can be referenced permanently.)

Please look at this and then indicate you acceptance or issues here on the mailing list. We really need responses to indicate that it has been reviewed.

Some helpful links:

	Thanks,
	Paul (as co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Aug 2012 09:10:18 -0400

> We have features in 3GPP Rel-10 and 3GPP Rel-11 that are waiting for completion of this draft.

The only "polishing" I anticipate will be
- to respond to any iesg comments
- editorial fixes requested by the editor

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Aug 2012 10:10:32 +0200

Hi,

Based on Atle's findings, there are a few editorial nits that I think we shall fix:

Section 4.3.2:
----------------

The text says:

	"Unless a feature capability indicator is inserted in a Feature-Caps
   	header field or a target refresh request,.."

Replace "or" with "of".

Section 5.3.4:
-----------------

The text says:

	"There might be restrictions related to whether entities are allowed
  	 to insert a feature capability indicator in registration related
   	messages, standalone transaction messages, or dialog related
  	messages, whether entities are..."

Remove "or".

Sections 7.3.2 and 7.3.3:
-----------------------------

In both sections we have the following text:

   	"Description contains the Abstract, provided in the registration
   	feature capability indication registration template."

However, there is no "Abstract" in the template. There is a "Description", though.

So, I suggest to simply say:

   	"Description, provided in the registration feature capability 
	indication registration template."

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 28. elokuuta 2012 16:10
To: Atle Monrad
Cc: SIPCORE
Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Aug 2012 10:53:03 -0400

These are very editorial in nature. (Hopefully the RFC editor would have 
caught them too.) They should be fixed, but I think you can save them 
for the next required edit.

	Thanks,
	Paul