Subject: [Dime] AD review of draft-ietf-dime-pmip6-lr-06

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Jan 2012 14:24:25 +0100

This is the AD review of draft-ietf-dime-pmip6-lr-06. In general the
document is in good share. I have a few comments listed below, but these
do not prevent sending the document to IETF Last Call. Please consider
the comments together with the other comments that you may receive
during the last call. 

The Comments are divided in T-Technical and E-Editorial

T1. Section 3.1:

> The MIP6-Agent-Info grouped AVP (AVP Code 486) is defined in
   [RFC5779].  This AVP is used to carry LMA addressing in AAA response.

Actually the MIP6-Agent-Info grouped AVP is defined in [RFC5447] and
extended in [RFC5779].

T2. In Section 3.4: 

> The LMA SHOULD support
      this policy feature on a per-MN and per-subscription basis.

First, this is the only usage of a capitalized keyword, and it treggers
an id-nits error because there is no 2119 boilerplate and reference. You
need to decide whether to take it out, or leave it but in this case add
the boilerplate and referance to [RFC2119]

Second, is this really a SHOULD? When would the LMA not support this
feature? 

E1. Section 3.4:

> This
   document defines new capability flag bits according to the IANA rules
   in RFC 5447.

s/new capability flag bits/one new capability flag bit/

E2. Also in Section 3.4:

s/it indicate that both MN and CN/it indicates that both MN and CN/

E3. Section 4.2: 

> In the case where MNs belong to the different LMAs,
   MAG1 or LMA1 should has already known the recipient of localized
   routing is LMA2.

This sentence is broken, needs to be fixed.

E4. In the IANA Considerations section it would be useful to add that
the new value in the Mobility Capability registry corresponds to the new
capability flag bit defined in section 3.4

E5. Add a note to the Change Log section to be taken out at publication.

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jan 2012 11:20:09 +0800

Hi, Dan:
Thank for your careful detailed review, please see my comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Sent: Monday, January 09, 2012 9:24 PM
Subject: [Dime] AD review of draft-ietf-dime-pmip6-lr-06

> Actually the MIP6-Agent-Info grouped AVP is defined in [RFC5447] and

[Qin]: You are right, AVP Code 486 is defined in RFC5447 rather than RFC5779, 
I will fix this in the new version.

> the boilerplate and referance to [RFC2119]

[Qin]: Okay, I can add the boilerplate and reference to RFC2119. But it seems only
this place needs RFC2119 language. Nowhere else.

> Second, is this really a SHOULD? When would the LMA not support this

[Qin]: My understanding is yes. In the case of Direct routing of IP packets between MNs anchored to the same MAG
, LMA would not support this feature.

> s/new capability flag bits/one new capability flag bit/

[Qin]: Okay.

> s/it indicate that both MN and CN/it indicates that both MN and CN/

[Qin]: Okay.

> This sentence is broken, needs to be fixed.

[Qin]: Yes, I think this can be fixed by removing should. Thanks.

> capability flag bit defined in section 3.4

[Qin]: This was discussed before  the WGLC. In the early version we added the new value
0x0000080000000000 to the the new capability flag bit. One suggestion from Jouni I remembered
is the new value should be decided by IANA folks. So in the version 06, I change the value
 0x0000080000000000 to TBD.
I am okay to put the new value back if you think it necessary we should do that.

> E5. Add a note to the Change Log section to be taken out at publication.

[Qin]: Okay. Thanks.
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 10 Jan 2012 11:12:18 +0100

Hi Qin,

Thank you for your quick response. 

No need to issue a revised version now. I am sending the document to
IETF Last Call, and you can implement the changes that address my
comments together with other comments that you may receive during the
IETF Last Call. 

See in-line a few notes. 

Regards,

Dan

> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Tuesday, January 10, 2012 5:20 AM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [Dime] AD review of draft-ietf-dime-pmip6-lr-06
> 
> Hi, Dan:
> [Qin]: Okay, I can add the boilerplate and reference to RFC2119. But
it
> seems only

[[DR]] One is enough to justify the need for the boilerplate and
reference. So either you add these or you renounce to using capitalized
SHOULD. 

> [Qin]: My understanding is yes. In the case of Direct routing of IP
> packets between MNs anchored to the same MAG

[[DR]] Is this not a determined by the topology in deployment? It seems
to me that an LMA implementation MUST support the feature, but it will
not be activated in the cases of Direct routing. 

> is the new value should be decided by IANA folks. So in the version
06,
> I change the value
> I am okay to put the new value back if you think it necessary we
should
> do that.
[[DR]] It's OK to let IANA decide what bit to allocate for the new
capability. What I am missing is the text linking the allocation to the
new capability flag bit mentioned in section 3.4.

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Jan 2012 09:59:13 +0800

I see and also agree with your notes, thanks.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 10, 2012 6:12 PM
Subject: RE: [Dime] AD review of draft-ietf-dime-pmip6-lr-06

Hi Qin,

See in-line a few notes. 

Regards,

Dan

it

06,
should