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

"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Thu, 15 August 2013 06:09 UTC

Return-Path: <sgundave@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA89A21F8FCE for <netext@ietfa.amsl.com>; Wed, 14 Aug 2013 23:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8n7jFp3n61lx for <netext@ietfa.amsl.com>; Wed, 14 Aug 2013 23:09:37 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id B0FF621F8E40 for <netext@ietf.org>; Wed, 14 Aug 2013 23:09:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3661; q=dns/txt; s=iport; t=1376546976; x=1377756576; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NWw6LH/0xlNo7plXGlHVymCNiwRJrhH+ZIvDDbU7xLs=; b=Y2b0PG2EwYnCnZZsPk0FNW8H4cqBkkeLlS5sECCDvs8kSTmF72at/6lZ vNU0wk4JdUevJ1YMNR2tTQoMFslyoxZXws46NqPYgXwk666qi6ZWcuRE+ ZqJR/vTZRUlvFKnnBjz2YLylC+J3clS7rsxAE24Hich8m+FHCmqULNTmO c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAFJwDFKtJXHB/2dsb2JhbABbgwaBBb8LgR8WdIIkAQEBAQM6PQISAQgYChRCJQIEDgUIiAi6AZAdAjEHgxt3A6k2gxuBaAc7
X-IronPort-AV: E=Sophos;i="4.89,882,1367971200"; d="scan'208";a="247565665"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 15 Aug 2013 06:09:33 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7F69XdG008230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 06:09:33 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 01:09:32 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Brian Haberman <brian@innovationslab.net>
Thread-Topic: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications
Thread-Index: AQHOmX4CvKHqCux6oE2mcSkhuTXL9g==
Date: Thu, 15 Aug 2013 06:09:32 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8103FDA1B@xmb-aln-x03.cisco.com>
In-Reply-To: <51F61D33.6070408@innovationslab.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.210]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3110AF4F97980641A4079873351C34B4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "netext@ietf.org" <netext@ietf.org>
Subject: Re: [netext] Fwd: AD Evaluation : draft-ietf-netext-update-notifications
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2013 06:09:42 -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" <brian@innovationslab.net> 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
>