Subject: [pcp] #73 (third-party-id-option): Dan Wing's comments on draft-ietf-pcp-third-party-id-option-00

From: "pcp issue tracker" <[email-masked]>
Date: Thu, 11 Dec 2014 21:16:06 -0000

#73: Dan Wing's comments on draft-ietf-pcp-third-party-id-option-00

 * 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).

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-third-party-id-
  [email-masked]        |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  minor        |  Milestone:  milestone1
Component:  third-       |    Version:  1.0
  party-id-option        |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/pcp/trac/ticket/73>
pcp <http://tools.ietf.org/pcp/>

---

From: "pcp issue tracker" <[email-masked]>
Date: Thu, 11 Dec 2014 21:17:31 -0000

Comment (by [email-masked]):

 Dan adds:

 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.

  party-id-option        |  Resolution:
 Keywords:               |

Ticket URL: <https://tools.ietf.org/wg/pcp/trac/ticket/73#comment:1>
pcp <http://tools.ietf.org/pcp/>