Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[e-mail]]
> Sent: Friday, February 24, 2012 1:33 PM
> To: Dan Wing
> Cc: [e-mail]; [e-mail]
> Subject: Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22
> 
> Dan: Sorry for the delay in responding.  Day job gets in the
> way.
> 
> Please see inline for residual comments.  I am skipping all
> those that we agreed on for brevity.  Thanks for attending to
> these!
> 
> On 02/13/2012 07:07 PM, Dan Wing wrote:
> >> - S7.1, second-to-last paragraph: I suspect that if more than one
> >> server was specified in the server list, the client will cycle
> >> through and try the next server.  I also note that this document
> >> only considers one server, so exact guidance is not provided on
> >> what to do when a PCP client has more than one server.
> >
> > We are purposefully silent on multiple servers, because we expect
> that
> > to be described in a later document.  There are a lot of nuances and
> > details related to multiple servers, including a multi-homed network
> > (where you purposefully want to talk to one server, or both servers,
> > for different reasons).  Such a network is purposefully out of scope.
> >
> > However, we wanted the text to allow a list of servers to be
> returned,
> > so that we could do something with that list in the future.
> 
> Sure; maybe a small indented note will help the reader that you allow
> a list of servers for future extensibility but in this draft you are
> only considering the case where this list has a singleton element.  (I
> know I would have found such a note helpful as an implementer).

During IESG review, there were two Comments of a similar nature.  It seemed
the "list" is what triggered the confusion, so I added the sentence starting
with "Thus," which tries to explain what we meant by the "default router 
list".  -24 now reads:

  2. the default router list (for IPv4 and IPv6) is used as the list	
  of PCP Server(s). Thus, if a PCP client has both an IPv4 and	
  IPv6 address, it will have an IPv4 PCP server (its IPv4 default	
  router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6	
  default router) for its IPv6 mappings.


> > I adjusted the sentence so it now reads:
> >
> >          The PCP client SHOULD impose
> >          an upper limit on this returned value (to protect against
> >          absurdly large values, e.g., 5 years), and the suggested
> values
> >          are 24 hours for success responses and 30 minutes for error
> >          responses.
> >
> > which should be clearer?
> 
> Perfect.  Thanks!
> 
> >> - S16.2: To protect against Advanced Threat Model attacks, the
> >>    draft assumes a PCP security mechanism that provides channel
> >>    authentication and encryption.  However, no further information
> >>    is provided for such a mechanism.  Will it help to provide
> >>    any candidates for such a mechanism (TLS?  S/MIME?) or is there
> >>    something entirely different in mind?
> >
> > The candidate at this time is draft-wasserman-pcp-authentication,
> > which uses EAP.  However, it is not yet a working group document
> > and it seemed premature to cite it.
> 
> ... even as an Informational Reference?

We have a DISCUSS from Stephen Farrell that we don't have anything
implementable in Section 16.2.  As of -24, I did not add a 
citation to draft-wasserman-pcp-authentication.  

> > Thanks for your review!
> 
> No problem; thank you for paying attention to my comments!

Thanks for your review!

-d


> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [e-mail]
> Web:   http://ect.bell-labs.com/who/vkg/