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

From: james woodyatt <[email-masked]>
Date: Sun, 29 Jan 2012 09:51:52 -0800

On Jan 29, 2012, at 08:08 , Francis Dupont wrote:
> 
> UPnP IGD v2 does the job, it was just published after the PCP effort beginning.

Was it published under terms that permit IETF to cite it in a standards track document as a normative requirement?  This has, in the past, been a problem with UPnP IGDv1.

--
j h woodyatt <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 11:16:24 -0800

On Jan 30, 2012, at 24:03 , Wuyts Carl wrote:

> + 1 on Barbara’s statement.  V6ops should take no position to select a mechanism here.  PCP seems to get the most attention but it should not make v6ops to decide to take it along explicitly in RFC6204bis.

I vigorously disagree with the reasoning in these statements.

If IETF cannot bring itself, in RFC 6204bis, to "require" its own standard protocol, which was intended for meeting REC-48 in RFC 6092, then I don't see why we should keep S-1 at all.

Put another way: if we believe there should be no standard mechanism in IPv6 CE routers for "host applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate" then why do we believe that IPv6 CE routers should implement RFC 6092?

I am NOT just ranting here.  This is a very serious question, and I would like the working group to address it.  I would very much like to see serious answers given.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 12:17:13 -0800

On Jan 30, 2012, at 11:58 , STARK, BARBARA H wrote:
> 
> To come at this from a procedural angle, then...
> 
> With the advent of the homenet WG, I thought we agreed that we would not make any attempt to address new additional LAN technology recommendations in a 6204bis document. We said 6204bis would only try to deal with WAN-side transition technologies, and other "fix existing 6204 recommendations, because now we know better" changes.
> 
> Recommending PCP as a LAN technology is, IMO, a homenet issue. It has no place in 6204bis.

This reasoning applies just as well to the recommendation of RFC 6092 Simple Security, which is about protecting LAN hosts according to local network policy.

If recommending a PCP server is for HOMENET to do, and it has no place in RFC 6204bis from V6OPS, then recommending RFC 6092 Simple Security neither has any place in RFC 6204bis and it should therefore be removed, and a notice inserted into RFC 6204bis to explain why the previous document was in error and to note that forthcoming documents from HOMENET will address the issue properly.

I would very much like to get a better understanding of how you are reasoning on this issue.

---

From: james woodyatt <[email-masked]>
Date: Mon, 30 Jan 2012 14:08:53 -0800

On Jan 30, 2012, at 12:59 , STARK, BARBARA H wrote:

> The reference to RFC 6092 is in RFC 6204, which was published prior to homenet’s creation.
>  
> Unless the reference to 6092 is truly an error, then we don’t need to be discussing changes to its recommendation (removal, updates, enhancements) in 6204bis. It continues as it was. 6204bis has tried to leave LAN elements of 6204 untouched. They were fully and appropriately discussed with consensus agreement to include them, at the time of 6204. And so they remain, unless there is a problem.
>  
> If you believe that inclusion of 6092 as a “SHOULD” is truly an error, then I would like to understand why you think that. If there exists proof that it’s harmful (I’ve heard some people say that having it enabled by default has caused some problems, so perhaps there is such proof), then maybe we should reconsider its inclusion. If you’re suggesting its removal because the topic is no longer under the charter of v6ops, then I disagree. We didn’t say that we wanted to pull out LAN elements when doing 6204bis. We said we didn’t want to do anything with them, at all (unless they have proven to be a true mistake). Removing the reference to 6092 would be inconsistent with an attempt to make no “LAN functionality” changes to 6204, when creating 6204bis. I would only support it if it were shown to be truly harmful.

If I were to make a technical argument about the harmfulness of RFC 6092, I would start with a lengthy review of its Security Considerations, in section 6.

I think it's a debatable question of procedure, whether it was an error at the time for V6OPS to publish RFC 6204 with its S-1 "requirement" to recommend implementation of RFC 6092.  There was a clamor for the timely publication of a document, and neither HOMENET nor PCP were remotely close to usable when RFC 6204 was in WGLC.

I do think it shouldn't be controversial *now* to say that HOMENET is the venue where any further IETF recommendations about the implementation of RFC 6092 in IPv6 CE routers should originate.  If you disagree, then once again, I have to ask for an explanation of your reasoning.  I'm very interested to know.

If V6OPS wishes to continue stepping on HOMENET's charter, on the grounds that it already has its footprints there from before HOMENET was launched, then I suppose that's fine— but, if so, then I don't see why V6OPS shouldn't also take this opportunity to revise RFC 6204 to recommend a PCP server to meet REC-48 in RFC 6092.  Again, as a purely technical matter— I know, technical matters are so boring— IETF has a standards-track protocol for ""host applications to solicit inbound traffic without advance knowledge of the addresses of exterior nodes with which they expect to communicate" as RFC 6092 recommends.  We did not have this protocol when either RFC 6092 or RFC 6204 were ready for publication, but we do now.  I fail to see any technical basis for leaving this unspecified in RFC 6204bis.  Is there one?

Alternatively, if this is primarily a procedural dispute, then we could open RFC6092bis in order to update REC-48 accordingly, then cite the RFC6092bis in RFC6204bis with a publication in lockstep.  Which would you prefer?