Re: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT)

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Sat, 09 August 2014 16:54 UTC

From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Pete Resnick <presnick@qti.qualcomm.com>, The IESG <iesg@ietf.org>
Thread-Topic: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT)
Thread-Index: AQHPs/KRzTLoFyChrkGU8CY7ut7DRg==
Date: Sat, 09 Aug 2014 16:54:21 +0000
Message-ID: <D00B9BCD.157CA3%sgundave@cisco.com>
In-Reply-To: <20140807035939.14978.80901.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.3.120616
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5AC7D8FB7D4BA446A32F8138AE67E6D1@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/4ZjTsCBbpfWFLE_QctNIEQLRv1s
Cc: "netext@ietf.org" <netext@ietf.org>, "netext-chairs@tools.ietf.org" <netext-chairs@tools.ietf.org>, "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" <draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org>
Subject: Re: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT)
Precedence: list

Hi Pete,

Thanks for the review. Please see inline.

On 8/6/14 8:59 PM, "Pete Resnick" <presnick@qti.qualcomm.com> wrote:

>Pete Resnick has entered the following ballot position for
>draft-ietf-netext-pmip-cp-up-separation-05: No Objection
>
>When responding, please keep the subject line intact and reply to all
>email addresses included in the To and CC lines. (Feel free to cut this
>introductory paragraph, however.)
>
>
>Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>for more information about IESG DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>A few weirdnesses in section 4:
>
>   There can be multiple
>   instances of the LMA User Plane Address mobility option present in
>   the message, one for IPv4 and the other for IPv6 transport.
>   
>Do you really mean "there can be multiple instances", or do you rather
>mean "there can be either one or two instances: One for IPv4, one for
>IPv6, or one for each of them"?

We tried to say there can be one or two instance of the option (option
format in Section 4), one for each IP version.

OLD:

The LMA User Plane Address mobility option is a new mobility header
   option defined for use with PBU and PBA messages exchanged between
   the LMA and the MAG.  This option is used for notifying the MAG about
   the LMA's user plane IPv6 or IPv4 address.  There can be multiple
   instances of the LMA User Plane Address mobility option present in
   the message, one for IPv4 and the other for IPv6 transport.

NEW:

The LMA User Plane Address mobility option is a new mobility header
   option defined for use with PBU and PBA messages exchanged between
   the LMA and the MAG.  This option is used for notifying the MAG about
   the LMA's user plane IPv6 or IPv4 address. There can be zero, one or
two instances of the LMA User Plane Address mobility option present in
the message. When two instances of the option are present, one instance
of the option must be for IPv4 transport and the other instance must be
for IPv6 transport.

(Or, please suggest text)

>
>      ...the IP address field
>      in the option can be either a zero-length field, or...
>
>Two instances of the above. Should that "can" be a MUST?
>'

Yes. Thanks.

OLD:

o  When using IPv4 transport for the user-plane, the IP address field
      in the option can be either a zero-length field, or a 4-octet
      field with ALL_ZERO value.

   o  When using IPv6 transport for the user-plane, the IP address field
      in the option can be either a zero-length field, or a 16-octet
      field with ALL_ZERO value.

NEW:

o When using IPv4 transport for the user-plane, the IP address field
in the option MUST be either a zero-length field, or a 4-octet
field with ALL_ZERO value.

o When using IPv6 transport for the user-plane, the IP address field
in the option MUST be either a zero-length field, or a 16-octet
field with ALL_ZERO value.

>   ...the IP address field in the option MUST be set...
>
>In the above and the two bullet items below it: Shouldn't the "MUST be"
>in each one instead be "is"? There's no protocol requirement there. What
>else *could* an implementation do?
>

Ok.

OLD:

o  When using IPv4 transport for the user-plane, the IP address field
      in the option MUST be the IPv4 address carrying user-plane
      traffic.

   o  When using IPv6 transport for the user-plane, the IP address field
      in the option MUST be the IPv6 address carrying user-plane
      traffic.

NEW:

o  When using IPv4 transport for the user-plane, the IP address field
      in the option is the IPv4 address carrying user-plane
      traffic.

   o  When using IPv6 transport for the user-plane, the IP address field
      in the option is the IPv6 address carrying user-plane
      traffic.

Regards
Sri

>
>_______________________________________________
>netext mailing list
>netext@ietf.org
>https://www.ietf.org/mailman/listinfo/netext

[netext] Pete Resnick's No Objection on draft-iet… Pete Resnick
Re: [netext] Pete Resnick's No Objection on draft… Sri Gundavelli (sgundave)
Re: [netext] Pete Resnick's No Objection on draft… Pete Resnick
Re: [netext] Pete Resnick's No Objection on draft… Sri Gundavelli (sgundave)