Re: [netext] AD Review : draft-ietf-netext-pd-pmip

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Brian, all,

Apologies for the late reaction on this.

We have just posted a new revision (-10) of the draft, addressing your
comments. Please see inline below some answers.

On Wed, 2013-08-14 at 16:17 -0400, Brian Haberman wrote:
> All,
>       I have performed my AD review of draft-ietf-netext-pd-pmip.  I 
> apologize for it taking as long as it did.  Overall, I am supportive of 
> this work, but I have some concerns.  I *think* most of my concerns have 
> to do with a lack of clarity in the spec caused by the layout of the 
> draft.  Of particular concern is the overabundance of bullet lists in 
> sections 5.1.2.

[Authors] We have tried to reduce the use of the bullet lists, as well
as to reorganize a bit the text.

> 
>       Please let me know if you need additional detail on any of these 
> comments.  Otherwise, I will await a revised version that the WG is 
> happy with.
> 

We would like to ask the WG to check whether they are happy with current
revision of the document.

> 
> 1. In the Abstract, mention that prefix delegation is being described in 
> relation to DHCPv6-PD

[Authors] Done.

> 
> 2. The Introduction says prefix delegation via DHCPv6 or through other 
> mechanisms.  Later, the draft says DHCPv6 or static configuration.  I 
> can see how both of those could be made to work, but I am leery of 
> mentioning some future PD protocol.  How would that work?  How would you 
> know which mechanism is being used?  Will the same PMIPv6
> signaling suffice for a future PD protocol?  I think it makes sense to 
> stick to what we know how to do today.

[Authors] The specification focuses on DHCPv6-PD, but also allows for
static configuration or access technology specific mechanisms. We have
clarified the text, so we do not mention any future PD protocol.

> 
> 3. Figures 2-4 are never referenced in the text.

[Authors] Fixed.

> 
> 4. Intro uses MAG without expansion or definition.

[Authors] Fixed.

> 
> 5. Introduction defines egress and ingress interfaces, but should 
> explicitly state these terms are defined from the perspective of the 
> mobile network.  I would actually move these definitions to section 2 
> and describe the MR function in relation to the mobile network and the 
> point-of-attachment.

[Authors] Done.

> 
> 6. How do the definitions in section 2 relate to the definitions in RFC 
> 4885?

[Authors] We have clarified this.

> 
> 7. Section 3.1 - any additional assumptions about how an MR knows which 
> interface to use when making DHCPv6 requests?

[Authors] We assume the egress interface is used. We have explicitly
added this in the text.

> 
> 8. Sections 3.2.1 and 3.2.2 are rather sparse in descriptive text.  It 
> would be good to briefly describe the steps outlined in the 
> corresponding figures.

[Authors] Done.

> 
> 9. Section 5.1.2 - Fourth bullet says the MAG MAY choose to send PBA 
> after getting a DMNP_IN_USE return code.  Why would it (or not) do that?

[Authors] This was a typo. It should say "PBU". We have fixed it.

> 
> 10. The bullet lists in 5.1.2/5.2.2 (and child sections) are confusing. 
>   The high-level bullets read like they should just be paragraphs.  The 
> sub-list in bullet two and five are items that need to
> be considered if stated conditions are met, correct?.  And am I correct 
> in that there must be 3 instances of the DMNP option in the PBU?

[Authors] We have made some changes there to make this more clear.

> 
> 11. Structure of 5.1.2.1 is confusing.  Can DHCP-MAG Interactions be 
> promoted to 5.1.3 and then have 5.1.3.1 describe when MAG is DR and 
> 5.1.3.2 describe when LMA is DR?

[Authors] Done.

> 
> 12. Bullet 2 of the DR at the MAG scenario is confusing. If the DR and 
> MAG are co-located, what interactions are beyond the scope of this 
> document?  Or is this more of the interactions between two processes 
> running on the same platform?

[Authors] It is more on the interactions between the two processes. We
have rewritten that piece of text to make it more clear.

> 
> 13. If the MR roams to a MAG that does not support PD, is there specific 
> behavior the MR needs to exhibit wrt the LFNs?

[Authors] We have added some text on this. Basically, we assume that all
MAGs supports PD. If not, that would make the MR loose the delegated
prefixes, and therefore the LFNs would loose them. We mention that the
MR may explicitly deprecate the addresses used by the LFNs or just leave
them expire.

> 
> 14. Is there a preference (operational issues) for running the DR at the 
> LMA rather than the MAG, or vice versa?  If so, should that be noted?

[Authors] Although we do not have a super strong preference, it is
simpler to run the DR on the MAG. so a single protocol interface is used
between the MAG and the LMA. We have added some text on this.

> 
> 
> Regards,
> Brian