Subject: Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 15 Aug 2013 06:09:32 +0000

Hi Brian,

We've posted the updated doc. Some comments below.

1.  >>Potentially some some new work items that we can point to. If there
are Active I-D's will add a reference.
>That would be useful. Just make sure they are informative references so
>that this spec does not get held up on a reference to an I-D.

Did not find any new items that we can reference here.

2. Some changes in normative language

Earlier text was bit loose on the use of "SHOULD", as supposed to "MUST",
fixed it.

3. - I would like to see some more guidance given to IANA on where the new
registries should be placed in their protocol hierarchy.

On cross checking, this seemed OK. But, may be we mis-understood the
comment.

4. Made other changes as agreed

Please let me know if this is OK.

Regards
Sri

On 7/29/13 12:43 AM, "Brian Haberman" <[email-masked]> wrote:

>Hi Sri,
>      I have deleted those points where there is no additional
>discussion needed...
>
>On 7/27/13 7:09 PM, Sri Gundavelli (sgundave) wrote:
>>> * Section 4
>>>
>>> - Is there any guidance needed on managing the wrapping of the Sequence
>>> #'s?
>>
>> We just require some random number, without collusions. We can add some
>> text to say how to manage that field.
>>
>
>Ok.  Just ensure that the descriptive text does not impact the Sequence
># usage defined in the base PMIPv6 spec.
>
>>>
>>> - Are there informative references that could be added for mobility
>>> options other than the vendor-specific ones?
>>
>>
>> Potentially some some new work items that we can point to. If there are
>> Active I-D's will add a reference.
>>
>
>That would be useful.  Just make sure they are informative references so
>that this spec does not get held up on a reference to an I-D.
>
>>>
>>> - Can you provide an example of where an LMA would not request an ACK
>>> for a UPN?
>>
>>
>> Message String extension. LMA sending some status messages related to
>>the
>> service its offering. These service message may not need Ack's.
>>
>> Also, a UPN message with NR=RE-register may not need a Ack messages. The
>> LMA after sending the UPN message with that NR code can wait the PBU
>> message.
>>
>
>So, is it worth mentioning these in the draft?  It seems that the LMA is
>in full control of whether an ACK is needed, but it *could* be useful to
>describe the *types* of options that do not need an ACK.
>
>I am not insisting on this.  Just trying to see if such an addition
>would make the spec easier to understand/implement.
>
>>>
>>> * Section 5.2
>>>
>>> - I am surprised by the use of SHOULD (SHOULD NOT) for re-transmission
>>> rules.  When would you expect these rules to be ignored?
>>
>>
>>
>> Ok. Will review this again.
>>
>
>If the SHOULDs are appropriate, it would be good to describe a scenario
>(or type of scenaro) where the SHOULD would be ignored.
>
>>>
>>> * Section 6.1
>>>
>>> - The 2nd bullet is useless.  If an implementation does not support
>>> these messages, they wouldn't know to look here for responses.  The
>>>base
>>> PMIPv6 spec covers the response message for unknown message types.
>>
>> This is about LMA sending a UPN message to a MAG that does not support
>>and
>> how to deal with that scenario.
>> If the response to a UPN message is a Binding Error message, then the
>>LMA
>> can be forced not to send any more UPN messages.
>>
>
>Given that section 6.1 talks about MAG considerations, it seemed odd to
>describe how the MAG is supposed to respond if it doesn't support this
>function.
>
>Regards,
>Brian
>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 15 Aug 2013 09:11:20 -0400

Hi Sri,

> On cross checking, this seemed OK. But, may be we mis-understood the

I just want the document to be explicit that IANA actions 3 and 4 will 
create registries under the "Mobile IPv6 Parameters" registry 
(https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml).

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 15 Aug 2013 14:29:54 +0000

Hi Brian,

Thanks for the clarification. That will make IANA related text complete.
We will make that change.

Regards
Sri