Re: procedures for working group last call

[Fred Baker <fred@cisco.com>]

The process is that you collect comments made, determine whether they have merit, and if so edit them into the draft. For technical comments, that may require a discussion on the list. For editorial comments, use good editorial judgement. Question re Mohamed Boucadair's markup: Given that I know you prefer Apple's counterpart to Microsoft Office, I have to ask: do you run Microsoft Word on your computer? Are you able to read the comments?

Let me take one comment from his markup as an example. As a general comment, he raises a question that may warrant addressing, if only to say that it was deemed out of scope. The change to the abstract seems mostly editorial, but the comment regarding service provider policy is out of place given that the only other references to a "service provider" (prior to these edits) are (1) in section 2.1 stating that the CPE resides between a residential broadband customer and his service provider, and (2) in Recommendation 16, which says that "Filtering behavior SHOULD by endpoint independent by default in gateways intended for provisioning without service-provider management." 

Use your editorial judgement on editorial comments; err in the direction of simplicity of language (active voice, short sentences, question every comma and conjunctive, etc). Spelling and grammatical changes are generally helpful to pick up. What is really important is technical commentary: if a recommendation is disputed or an oversight pointed out, we need to discuss that.

The comments Mohamed places on the abstract are: 

> After reading this document, opening IPv6 fw pinholes is not covered. What are the security limitation of such feature? How this should be implemented to not open holes which may be exploited by malicious attackers.
> 
> - FW filters should be updated upon the change of the assigned IPv6 prefix, the change of the local IPv6 assigned to an internal node.
> 
> - Application-specific filters such as VoIP (SIP and RTP) are out of scope. The control of the FW can be achieved via appropriate means which are out of scope of this document.

There was indeed discussion of pinhole technologies such as UPnP and your proposal. My recollection was that the topic was deemed out of scope: the IETF doesn't have a consensus on the topic (we just barely agree that someone should define the term "firewall"), and if we were to recommend something we would want it to be an open standard that passed security muster. Frankly, I think letting IPsec through the firewall is a very adequate "pinhole" - there is an assumption of end-to-end AAA. Even there, though, were I writing the specification I would say that I wanted the host to announce classes of sessions that it was willing to be a receiver of and have the firewall open corresponding pinholes; that might include "you may send IPsec traffic to me". There is of course a security issue with that as well; a virus or trojan is an application running on a computer, and could open pinholes of its choosing.

On Apr 12, 2010, at 10:13 AM, james woodyatt wrote:

> chairs--
> 
> I'm not sure I know what is the proper procedure for a technical editor to follow during the working group last call phase, so I plan to remain quiet on the subject of I-D.ietf-v6ops-cpe-simple-security until the end of the window unless I'm asked to speak up by one of the chairpersons.
> 
> 
> --
> james woodyatt <jhw@apple.com>
> member of technical staff, communications engineering
> 
> 

http://www.ipinc.net/IPv4.GIF