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

From: Dave Thaler <[email-masked]>
Date: Mon, 5 Jan 2015 19:39:34 +0000

As a reminder, this WGLC will conclude in 2 days.
Please review and send comment.

-Dave

> -----Original Message-----
> From: Dave Thaler
> Sent: Wednesday, December 10, 2014 8:50 AM
> To: [email-masked]
> Subject: WGLC: draft-ietf-pcp-third-party-id-option-00 comments due by JAN 7
> 
> 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: Dave Thaler <[email-masked]>
Date: Wed, 7 Jan 2015 22:41:39 +0000

A copy with my comments inline is now at
http://research.microsoft.com/~dthaler/draft-ietf-pcp-third-party-id-option-00.pdf

Summary:
1) Too many places are still worded to be about "tunnel ID" rather than "third party ID".
   This draft shouldn't assume tunnels, that's just one example case.
2) Need to explicitly state the assumption that the same PCP-IWF serves multiple subscribers.
    (It was implicit currently, but should be explicit.)
3) Need to explicitly state the assumption that the PCP client and PCP server have some
    out-of-band mechanism to agree on what to put in the THIRD_PARTY_ID field.
    (Again it was implicit, but should be explicit.)
4) Section 5.2 on processing a request needs to cover the success case, not just the error case.
    And I believe that behavior changes the basic rules in RFC 6887 and hence this document
    should Update 6887.  I.e. you cannot simply implement this as a layer on top of an
    unmodified 6887-compliant PCP implementation.
5) Section 5.3 on processing a response has a new requirement "SHOULD report an error"
     which is not in RFC 6887 section 11.4 or 12.4.   Is this really a requirement?  I'm ok
    either way, but not sure why this specific error response would be special in terms
    of what should be reported to somewhere.

-Dave

> Sent: Monday, January 5, 2015 11:40 AM
> To: [email-masked]'
> Subject: RE: WGLC: draft-ietf-pcp-third-party-id-option-00 comments due by
> JAN 7
> 
> > 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.
> >
> > 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
> >
> >  This draft is a work item of the Port Control Protocol Working Group
> > of the IETF.
> >
> > 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.
> >