Subject: [pcp] PCP server in draft-ietf-v6ops-6204bis

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jan 2012 11:59:12 -0800

v6ops,

I was reading over draft-ietf-v6ops-6204bis today and have a 
suggestion.

Background:  RFC6092 is v6ops's Simple CPE Security document, which 
recommends that a protocol be used to allow a passive listener (e.g., 
web camera) to open a pinhole.  In that document, James Woodyatt's 
ALD was suggested as a possible candidate protocol for that function.

But I see that both the old RFC6204 and draft-ietf-v6ops-6204bis-05
say this (I added uppercase for emphasis):	

   S-1:  The IPv6 CE router SHOULD support [RFC6092].  In particular,
         the IPv6 CE router SHOULD support functionality sufficient for
         implementing the set of recommendations in [RFC6092],
         Section 4.  This document takes no position on whether such
         functionality is enabled by default OR MECHANISMS BY WHICH 
         USERS WOULD CONFIGURE IT.

I would like draft-ietf-v6ops-6204bis to take the position that 
Port Control Protocol (PCP) be the protocol for the uppercased function.

Stated more clearly, I would like the above paragraph to read:

   S-1:  The IPv6 CE router SHOULD support [RFC6092].  In particular,
         the IPv6 CE router SHOULD support functionality sufficient for
         implementing the set of recommendations in [RFC6092],
         Section 4.  This document takes no position on whether such
         functionality is enabled by default.  The IPv6 CE router 
...............................................^^^^^^^^^^^^^^^^^^
         SHOULD implement a PCP server [I-D.ietf-pcp-base] so that
.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
         hosts can configure this functionality.
.........^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you need more background, please be sure to read both REQ-48 and REQ-49
of RFC6092.  PCP would be a specific protocol that fulfills REQ-49.

In anticipation of one of the earlier objections that making PCP a normative
requirement would delay draft-ietf-v6ops-6204bis,
https://datatracker.ietf.org/doc/draft-ietf-pcp-base shows the document
status is Publication Requested because the PCP working group finished its
WGLC on the document.

-d

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 27 Jan 2012 20:18:01 +0000

I disagree. 
I believe the marketplace should determine the winning technology in this case, if there is to be a winning technology. RFC6204bis needs to continue to take no position. 

Just because other solutions weren't created by IETF doesn't mean they are any less good. 
Barbara

----- Original Message -----
From: Dan Wing [mailto:[email-masked]]
Sent: Friday, January 27, 2012 02:59 PM
To: 'v6ops' <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: [v6ops] PCP server in draft-ietf-v6ops-6204bis

v6ops,

-d

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 27 Jan 2012 15:49:56 -0500

> Just because other solutions weren't created by IETF doesn't mean they are any less good.

<outrageous>
Right. They are less good because PCP is better.
</outrageous>

Sorry, couldn't resist. ;)

Seriously: We already have consensus on a "SHOULD implement a PCP 
server" in draft-ietf-behave-lsn-requirements. I think we should also 
have it on the CPE. Having only one protocol to support would make it so 
much easier for application developers!

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jan 2012 12:54:36 -0800

> -----Original Message-----
> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: Friday, January 27, 2012 12:18 PM
> To: [email-masked]'; [email-masked]'
> Cc: [email-masked]'; [email-masked]'
> Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis
> 
> I disagree.
> I believe the marketplace should determine the winning technology in
> this case, if there is to be a winning technology. RFC6204bis needs to
> continue to take no position.
> 

I suppose you are referring to UPnP IGD 2, which added IPv6 firewall
support (among other things of less interest to v6ops).

If it said "or UPnP IGD 2", would you still object or would that be 
acceptable?

Right now, the text allows any sorts of thing -- including a web portal
operated by the ISP, Web UI on the CPE itself, CLI on the CPE (accessed
via ssh or telnet), holding a little red button in the back for 3 
seconds to allow port 80 or 30 seconds to allow port 443, or whatever 
someone wants to design and claim compliance.  This sort of free-for-all
seems incongruent with Internet and IPv6 going into billions of 
homes and businesses and a standards-making organization such as the
IETF.

-d

> Cc: [email-masked] <[email-masked]>; draft-ietf-v6ops-
> [email-masked] <[email-masked]>