headers
Vijay K. Gurbani | 10 Feb 22:57
Favicon

APPSDIR rdraft-ietf-pcp-base-22

Document: draft-ietf-pcp-base-22
Title: Port Control Protocol (PCP)
Reviewer: Vijay K. Gurbani
Review Date: Feb-10-2012
IETF Last Call Date: Not known
IESG Telechat Date: Not known

Summary: This draft is almost ready for publication as a Proposed
Standard but has a few issues that should be fixed before publication.

Major issues: 0
Minor issues: 11
Major issues: 0

Issues listed below are in document order.

- S5, the all zeroes IPv4 address as defined by the draft is a
  contribution of the draft itself, right?  That is, at least I am not
  aware whether ::ffff:0:0 is generally used as the all-zero IPv4-mapped
  IPv6 address.  It may well be, in which case this comment can be
  ignored.  But if it is not a general use address and is intended to be
  defined by this draft, I wonder if rfc2119 MUST is appropriate here (as
  in "The all-zeroes IPv4 address MUST be expressed as: 80 bits of
  zeros, 16 bits of ones, and 32 bits of zeros (::ffff:0:0).").

- S6.1, the "Opcode-specific information" block of Figure 2 is not
  discussed at all in the text following Figure 2.

- S6.1, the "PCP Options" block of Figure 2 is not discussed at all in
  the text following Figure 2.  You do provide a Section 6.3 that
(Continue reading)

Permalink | Reply |
headers
Dan Wing | 14 Feb 02:07
Picon
Favicon

Re: APPSDIR rdraft-ietf-pcp-base-22

> -----Original Message-----
> From: apps-discuss-bounces <at> ietf.org [mailto:apps-discuss-
> bounces <at> ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: Friday, February 10, 2012 1:58 PM
> To: apps-discuss <at> ietf.org; draft-ietf-pcp-base <at> tools.ietf.org
> Subject: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22
> 
> Document: draft-ietf-pcp-base-22
> Title: Port Control Protocol (PCP)
> Reviewer: Vijay K. Gurbani
> Review Date: Feb-10-2012
> IETF Last Call Date: Not known
> IESG Telechat Date: Not known
> 
> Summary: This draft is almost ready for publication as a Proposed
> Standard but has a few issues that should be fixed before publication.
> 
> Major issues: 0
> Minor issues: 11
> Major issues: 0
> 
> Issues listed below are in document order.
> 
> - S5, the all zeroes IPv4 address as defined by the draft is a
>   contribution of the draft itself, right?  That is, at least I am not
>   aware whether ::ffff:0:0 is generally used as the all-zero IPv4-
> mapped
>   IPv6 address.  It may well be, in which case this comment can be
>   ignored.
(Continue reading)

Permalink | Reply |
headers
S Moonesamy | 14 Feb 04:18
Favicon

Re: APPSDIR rdraft-ietf-pcp-base-22

Hi Dan,
At 17:07 13-02-2012, Dan Wing wrote:
>I attempted to search for the phrase, and for ::ffff:0:0 and :ffff:0.0.0.0,
>and found no existing RFC using either notation to indicate "all-zeros
>address".  So, this is the first.

Would RFC 5952 be of help?

Regards,
S. Moonesamy
Permalink | Reply |
headers
Vijay K. Gurbani | 24 Feb 22:32
Favicon

Re: 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).

> I adjusted the sentence so it now reads:
>
(Continue reading)

Permalink | Reply |
headers
Dan Wing | 14 Mar 00:38
Picon
Favicon

Re: APPSDIR rdraft-ietf-pcp-base-22

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:vkg <at> bell-labs.com]
> Sent: Friday, February 24, 2012 1:33 PM
> To: Dan Wing
> Cc: apps-discuss <at> ietf.org; draft-ietf-pcp-base <at> tools.ietf.org
> 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,
(Continue reading)

Permalink | Reply |

Gmane