IETF Logo Mail Archive

[pcp] #75 (third-party-id-option): Dave Thaler's comments on draft-ietf-pcp-third-party-id-option-00

"pcp issue tracker" <trac@tools.ietf.org> Wed, 07 January 2015 22:42 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5281B1A1BA5 for <pcp@ietfa.amsl.com>; Wed, 7 Jan 2015 14:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SykvKcnej1J for <pcp@ietfa.amsl.com>; Wed, 7 Jan 2015 14:42:56 -0800 (PST)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE601A1B93 for <pcp@ietf.org>; Wed, 7 Jan 2015 14:42:56 -0800 (PST)
Received: from localhost ([::1]:41721 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac@tools.ietf.org>) id 1Y8zJO-0003AA-OY; Wed, 07 Jan 2015 14:42:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: pcp issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-pcp-third-party-id-option@tools.ietf.org, dthaler@microsoft.com
X-Trac-Project: pcp
Date: Wed, 07 Jan 2015 22:42:46 -0000
X-URL: http://tools.ietf.org/pcp/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/pcp/trac/ticket/75
Message-ID: <059.b391db7d29982cc510d59e4791c48b07@tools.ietf.org>
X-Trac-Ticket-ID: 75
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-pcp-third-party-id-option@tools.ietf.org, dthaler@microsoft.com, pcp@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: dietz@neclab.eu, quittek@neclab.eu, ralds@tid.es, ripke@neclab.eu, winter@neclab.eu
Archived-At: http://mailarchive.ietf.org/arch/msg/pcp/8A2Dr2HzNTSTYQjd7w-jcXo232M
Cc: pcp@ietf.org
Subject: [pcp] #75 (third-party-id-option): Dave Thaler's comments on draft-ietf-pcp-third-party-id-option-00
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.15
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp/>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jan 2015 22:42:58 -0000

#75: Dave Thaler's comments on draft-ietf-pcp-third-party-id-option-00

 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.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-pcp-third-party-id-
  dthaler@microsoft.com  |  option@tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:  milestone1
Component:  third-       |    Version:  1.0
  party-id-option        |   Keywords:
 Severity:  In WG Last   |
  Call                   |
-------------------------+-------------------------------------------------

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

v2.23.0 | Report a Bug | By Email