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

[Brian Haberman <[e-mail]>]

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