Subject: [pcp] WGLC: draft-ietf-pcp-third-party-id-option-00 comments due by JAN 7

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Dec 2014 16:50:29 +0000

In Honolulu we had a discussion about the draft formerly known as
draft-ripke-pcp-tunnel-id-option, which has been presented and discussed several times
over the last several meetings.  We said we'd adopt it as a WG document and immediately
last call it.

The document has now been republished as draft-ietf-pcp-third-party-id-option, and as such,
this email initiates a Working Group Last Call on it to conclude on Wednesday, January 7th 
(allowing extra time due to holidays).  Please send comments to the list.

As a reminder, when responding to a WGLC, what we chairs are looking for is a statement about 
document quality (not really about whether the mechanism should move forward).  That is, 
state whether you think the document is ready as is, or if not, what issues you see.

Thanks,
-Dave

-----Original Message-----
From: pcp [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, December 8, 2014 2:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: [pcp] I-D Action: draft-ietf-pcp-third-party-id-option-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Port Control Protocol Working Group of the IETF.

        Title           : PCP Third Party ID Option
        Authors         : Andreas Ripke
                          Rolf Winter
                          Thomas Dietz
                          Juergen Quittek
                          Rafael Lopez da Silva
	Filename        : draft-ietf-pcp-third-party-id-option-00.txt
	Pages           : 11
	Date            : 2014-12-08

Abstract:
   This document describes a new Port Control Protocol (PCP) option
   called THIRD_PARTY_ID.  It is used together with the THIRD_PARTY
   option specified in [RFC6887] to identify a Third Party in situations
   where the IP address in the THIRD_PARTY option alone is insufficient
   to create mappings in a PCP-controlled device.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pcp-third-party-id-option/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pcp-third-party-id-option-00

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: 🔓Dan Wing <[email-masked]>
Date: Wed, 10 Dec 2014 09:53:35 -0800

> state whether you think the document is ready as is, or if not, what issues you see.

The tombstone file is missing (I wish it would get created automatically when WG documents are created!).  For others' benefit, side-by-side diff is
http://tools.ietf.org/rfcdiff?url1=draft-ripke-pcp-tunnel-id-option-02&url2=draft-ietf-pcp-third-party-id-option-00

My review:

* The document mentions CGN assigning RFC1918 addresses.  A CGN shouldn't be assigning RFC1918 addresses, it should be assigning RFC6598 space (100.64.0.0/10).  RFC1918 space belongs to end subscribers, not the ISP.

* Below section 4, I see "May appear in: request. Must appear in response if it appeared in the associated request." -> should be uppercased to RFC2119 format.

* Section 5.2, "Processing a Request", says:
  If the THIRD_PARTY_ID option is sent without a THIRD_PARTY	
  option the PCP server MUST return a MALFORMED_REQUEST response.
it should say "... is RECEIVED without ...", because this section is about how to process a request (not how to send a request; sending was described in previous section).

-d

---

From: Andreas Ripke <[email-masked]>
Date: Thu, 11 Dec 2014 15:40:02 +0000

Hi Dan,

Thanks for your review.

> My review:
> 
> * The document mentions CGN assigning RFC1918 addresses.  A CGN shouldn't
> be assigning RFC1918 addresses, it should be assigning RFC6598 space
> (100.64.0.0/10).  RFC1918 space belongs to end subscribers, not the ISP.
> 

Maybe our wording is misleading:

	This is, for example, the case if a CGN
	supports overlapping private IP address spaces ([RFC1918]) for
	internal hosts of different subscribers.

We do not expect the CGN to assign addresses.
But the CGN should support or accept overlapping private IP address spaces for the subscriber's hosts.
We could change 'supports' to 'accepts'.

> * Below section 4, I see "May appear in: request. Must appear in response if it
> appeared in the associated request." -> should be uppercased to RFC2119
> format.
>

Ok.
 
> it should say "... is RECEIVED without ...", because this section is about how to
> process a request (not how to send a request; sending was described in
> previous section).

Yes.

Best,

Andreas

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 11 Dec 2014 09:10:33 -0800

> We could change 'supports' to 'accepts'.

My heartburn is around the phrasing that a CGN assigns RFC1918 addresses.  A carrier-grade NAT, operated by a carrier (ISP) should not assign RFC1918 addresses to subscribers.  Rather, a CGN should assign RFC6598 addresses -- that's why RFC6598 addresses were defined, was for CGN to assign them.  This is because the subscriber's "host" is likely a NAT (even if it's a cellular handset -- consider tethering to a PC), which itself wants to assign RFC1918 addresses.

I suggest:
OLD:
   This is, for example, the case if a CGN supports overlapping
   private IP address spaces ([RFC1918]) for internal hosts
   of different subscribers.

NEW:
   This is the case if a CGN assigns overlapping
   IP addresses (e.g., [RFC6598]) to
   internal hosts of different subscribers.

-d

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Dec 2014 14:05:39 -0500

> We could change 'supports' to 'accepts'.
...

Just a general comment here on overlapping address spaces. In our work 
on the NATv2 MIB, we explicitly provide for DS-Lite, by using the IPv6 
tunnel header source address as part of the mapping information as 
speecified in RFC 6333. For other cases of address space overlap, it is 
assumed that the NAT uses an additional classifier such as ingress 
interface, VRF, or VLAN to figure out which address realm is involved.

Just wondering if this implies something about the path that PCP 
commands have to take relative to the data packets they will be affecting.

Tom Taylor

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Dec 2014 14:11:04 -0500

Disconnect here. Andreas is talking about host-side (internal) 
addresses, Dan is talking about external addresses.

Tom Taylor

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 11 Dec 2014 12:32:59 -0800

On Dec 11, 2014, at 11:11 AM, Tom Taylor <[email-masked]> wrote:

> Disconnect here. Andreas is talking about host-side (internal) addresses, Dan is talking about external addresses.

We are both talking about internal addresses (the addresses assigned on the 'inside' of the CGN, rather than the addresses on the public (Internet-facing) side of the CGN.

-d

---

From: <[email-masked]>
Date: Fri, 12 Dec 2014 07:12:20 +0000

Hi Dan, all,

I agree with Andreas here. The CGN does not ** assign ** internal addresses to hosts. Those internal addresses are assigned by other means. 

IMHO, there is no harm to cite both RFC6598 and RFC1918 as examples.

Cheers,
Med

-----Message d'origine-----
De : pcp [mailto:[email-masked]] De la part de ??Dan Wing
Envoyé : jeudi 11 décembre 2014 18:11
À : Andreas Ripke
Cc : [email-masked]
Objet : Re: [pcp] WGLC: draft-ietf-pcp-third-party-id-option-00 comments due by JAN 7

I suggest:
OLD:

NEW:

-d

---

From: 🔓Dan Wing <[email-masked]>
Date: Thu, 11 Dec 2014 23:25:19 -0800

> I agree with Andreas here. The CGN does not ** assign ** internal addresses to hosts. Those internal addresses are assigned by other means. 

Thanks, I see the issue now.

I had suggested:

and the problem is the specific word "assign".  So, how about:
  This is the case if a CGN supports overlapping
  IP addresses (e.g., [RFC6598]) for
  internal hosts of different subscribers.

which is identical to current I-D text, except cites RFC6598 and removes commas and 'for example' phrase.

> IMHO, there is no harm to cite both RFC6598 and RFC1918 as examples.

Since the publication of RFC6598, RFC1918 address shouldn't ever be seen by a Carrier Grade NAT.  RFC1918 addressing belongs the subscriber's private network (not the ISP's network).

-d

---

From: <[email-masked]>
Date: Fri, 12 Dec 2014 07:48:51 +0000

Re-,

The publication of RFC6598 does not hide all the deployments around which make use of 1918 addresses. That's why I think it is fair (and even accurate) to cite both.

Cheers,
Med

-----Message d'origine-----
De : 🔓Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 12 décembre 2014 08:25
À : BOUCADAIR Mohamed IMT/OLN
Cc : Andreas Ripke; [email-masked]
Objet : Re: [pcp] WGLC: draft-ietf-pcp-third-party-id-option-00 comments due by JAN 7

I had suggested:

-d

---

From: RAFAEL ALEJANDRO LOPEZ DA SILVA <[email-masked]>
Date: Fri, 12 Dec 2014 12:58:09 +0000

> -----Mensaje original-----
> De: pcp [mailto:[email-masked]] En nombre de ??Dan Wing
> Enviado el: viernes, 12 de diciembre de 2014 8:25
> Para: Mohamed Boucadair
> CC: [email-masked]
> Asunto: Re: [pcp] WGLC: draft-ietf-pcp-third-party-id-option-00 comments
> due by JAN 7
>
>
> > I agree with Andreas here. The CGN does not ** assign ** internal
> addresses to hosts. Those internal addresses are assigned by other means.
>
> Since the publication of RFC6598, RFC1918 address shouldn't ever be seen by
> a Carrier Grade NAT.  RFC1918 addressing belongs the subscriber's private
> network (not the ISP's network).
>
> -d

In a DS-Lite scenario, the CGN sees IPv4 RFC1918 addresses.

Rafael

> > De : pcp [mailto:[email-masked]] De la part de ??Dan Wing Envoyé
> > : jeudi 11 décembre 2014 18:11 À : Andreas Ripke Cc : [email-masked]
> >>> * The document mentions CGN assigning RFC1918 addresses.  A CGN
> >>> shouldn't be assigning RFC1918 addresses, it should be assigning
> >>> RFC6598 space (100.64.0.0/10).  RFC1918 space belongs to end
> subscribers, not the ISP.
> >>>
> >>
> > My heartburn is around the phrasing that a CGN assigns RFC1918
> addresses.  A carrier-grade NAT, operated by a carrier (ISP) should not assign
> RFC1918 addresses to subscribers.  Rather, a CGN should assign RFC6598
> addresses -- that's why RFC6598 addresses were defined, was for CGN to
> assign them.  This is because the subscriber's "host" is likely a NAT (even if it's
> a cellular handset -- consider tethering to a PC), which itself wants to assign
> RFC1918 addresses.
> >
> > I suggest:
> > OLD:
> >>> * Below section 4, I see "May appear in: request. Must appear in
> >>> response if it appeared in the associated request." -> should be
> >>> uppercased to RFC2119 format.
> >>>
> >>
> >> Ok.
> >>
> >>> If the THIRD_PARTY_ID option is sent without a THIRD_PARTY option
> >>> the PCP server MUST return a MALFORMED_REQUEST response.
> >>> it should say "... is RECEIVED without ...", because this section is
> >>> about how to process a request (not how to send a request; sending
> >>> was described in previous section).
> >>
> >> Yes.
> >>
> >> Best,
> >>
> >> Andreas
> >>
> >>
> >> NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park,
> >> West End  Road, London, HA4 6QE, GB | Registered in England 2832014
> >>
> >>
> >

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: 🔓Dan Wing <[email-masked]>
Date: Fri, 12 Dec 2014 09:14:53 -0800

> In a DS-Lite scenario, the CGN sees IPv4 RFC1918 addresses.

Thanks, good point.  

-d

---

From: Dave Thaler <[email-masked]>
Date: Sun, 14 Dec 2014 00:45:03 +0000

Dan Wing wrote:
> The tombstone file is missing (I wish it would get created automatically when
> WG documents are created!).  For others' benefit, side-by-side diff is
> http://tools.ietf.org/rfcdiff?url1=draft-ripke-pcp-tunnel-id-option-
> 02&url2=draft-ietf-pcp-third-party-id-option-00

I talked to Henrik about this.  Tombstone files are obsolete.
The diff links are supposed to appear automatically when
a draft is marked as "replaced by" another draft.   I had done
that when I sent out the WGLC email, but there's apparently some
bug in the tool right now that Henrik is tracking down that caused
a delay.   The diff link does show up now.

-Dave

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 15 Dec 2014 07:22:32 -0800

> a delay.   The diff link does show up now.

Thanks.

-d