Subject: [Gen-art] Gen-ART review of draft-ietf-mext-nemo-pd-06.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 20 Sep 2010 08:47:43 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft. For background on Gen-ART, please see the FAQ at 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq

Please resolve these comments along with any other comments you may receive.

Document: draft-ietf-mext-nemo-pd-06.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 17-Sept-2010
IETF LC End Date: 21-Sept-2010

Summary: The document is almost ready for publication as a standards 
track RFC, but has some small issues that should be polished.

Major issues: none

Minor issues:

- I noticed that the document does not contain as much normative text as 
I would have expected. For example, see the 3rd and following paragraphs 
in Section 3.1, which describe the exchanges of messages between the MR 
and the HA. I understand that anything that is normatively described in 
RFC 3315 or  RFC 3633 does not need to be repeated normatively here. But 
there is quite a lot of text an non-normative statements. Is this done on 
purpose?

- On the second paragraph in Section 3.3, the text describes an update to 
the procedures of RFC 3315. Therefore, RFC 3315 should be listed in the 
cover page of the draft as "Updates: RFC 3315". This is for the RFC 
Editor to properly update the RFC database and when people search for RFC 
3315 they can find that there is an update in your draft.

- Considering the dependency on draft-ietf-mext-rfc3775bis, I think this 
draft should be promoted to a normative reference (so, a moved from 
Section 8.2 to 8.1).

Nits/editorial comments:

- Section 3, first paragraph, at the end of the second sentence, the text 
reads:

    "In this extension, an MR uses..."

It is not clear to me if "this extension" refers to "NEMO Basic Support 
protocol" or "the document you are currently reading". Please, make it 
explicit

- Another ambiguity. The third paragraph on Section 3 reads:

     To use DHCPv6PD for NEMOs, the HA assumes the role of the DR, and the
     MR assumes the role of the RR when located at home, and the role of a
     DRA co-located with the RR function, when the MR is away from home.

The sequence of two ", and ..." makes it difficult to digest the text. I 
recommend something around these lines:

     To use DHCPv6PD for NEMOs, when the MR is located at home the HA 
assumes the role of the DR and the MR assumes the role of the RR. 
However, when the MR is away from home, in addition to the roles when the 
MR is located at home, the MR also assumes the role of a DRA co-located 
with the RR function.

- Section 3.1, second paragraph, the text reads:

     Since the MR may not have yet requested any prefixes,
     implicit BU signaling MUST be used.

In order to properly address statement of compliance towards this RFC, 
can you please turn the sentence involving the normative "MUST" from 
passive into active?

- Expand terms at first occurrence. This include at least "BU".

- It would be nice to see formal references when an RFC is named. For 
example, in Section 3.1 there are quite many references to other RFC 
numbers without a formal reference to the documents listed in Section 8. 
There are other instances of this issue throughout the document.

- Not being myself familiar with the technology described here, it has 
been a bit hard to read the document due to the large amount of acronyms. 
If possible, I would recommend the authors to expand all the acronyms for 
helping those like me.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 20 Sep 2010 17:06:16 -0700

Hi Carlos and Miguel,

> Carlos Jesús Bernardos Cano wrote:
> 
> Hi Miguel,
> 
> Thanks for your comments. Please see inline below.
> 
> On Mon, 2010-09-20 at 08:47 +0200, Miguel A. Garcia wrote:
> > reviewer for this draft. For background on Gen-ART, please see the
> > FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> >
> > Reviewer: Miguel Garcia <[email-masked]> Review Date:
> > 17-Sept-2010 IETF LC End Date: 21-Sept-2010
> >

[...]
 
> > - On the second paragraph in Section 3.3, the text describes an
> > update to the procedures of RFC 3315. Therefore, RFC 3315 should be listed
> > in the cover page of the draft as "Updates: RFC 3315". This is for the
> > RFC Editor to properly update the RFC database and when people search
> > for RFC 3315 they can find that there is an update in your draft.
> 
> OK, thanks for pointing this out.

I do not think this specification updates RFC 3315: This specification has no impact on an implementation that only implements RFC 3315 and does not implement this specification.
 
--julien

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Sep 2010 17:50:31 -0700

Thanks for your review!

Jari

Miguel A. Garcia kirjoitti:
> reviewer for this draft. For background on Gen-ART, please see the FAQ 
> at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
>
> - I noticed that the document does not contain as much normative text 
> as I would have expected. For example, see the 3rd and following 
> paragraphs in Section 3.1, which describe the exchanges of messages 
> between the MR and the HA. I understand that anything that is 
> normatively described in RFC 3315 or  RFC 3633 does not need to be 
> repeated normatively here. But there is quite a lot of text an 
> non-normative statements. Is this done on purpose?
>
> - On the second paragraph in Section 3.3, the text describes an update 
> to the procedures of RFC 3315. Therefore, RFC 3315 should be listed in 
> the cover page of the draft as "Updates: RFC 3315". This is for the 
> - Considering the dependency on draft-ietf-mext-rfc3775bis, I think 
> this draft should be promoted to a normative reference (so, a moved 
> from Section 8.2 to 8.1).
>
>
>
> Nits/editorial comments:
>
> - Section 3, first paragraph, at the end of the second sentence, the 
> text reads:
>
> It is not clear to me if "this extension" refers to "NEMO Basic 
> Support protocol" or "the document you are currently reading". Please, 
> make it explicit
>
> The sequence of two ", and ..." makes it difficult to digest the text. 
> I recommend something around these lines:
>
> However, when the MR is away from home, in addition to the roles when 
> the MR is located at home, the MR also assumes the role of a DRA 
> co-located with the RR function.
>
> numbers without a formal reference to the documents listed in Section 
> 8. There are other instances of this issue throughout the document.
>
> been a bit hard to read the document due to the large amount of 
> acronyms. If possible, I would recommend the authors to expand all the 
> acronyms for helping those like me.
>
> /Miguel
>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 21 Sep 2010 01:23:37 +0200

Hi Miguel,

> there is quite a lot of text an non-normative statements. Is this done on 

No, it is not done on purpose. We can add normative text as you suggest.

> draft should be promoted to a normative reference (so, a moved from 

Right, this has also be pointed out by other reviewers. We'll perform
that change, and we are also considering -- as suggested by Jari -- to
reference RFC3775 instead to avoid publishing delays.

> protocol" or "the document you are currently reading". Please, make it 

OK, agree. Just for your clarification, it refers to the NEMO Basic
Support protocol. We'll change it.

> MR is located at home, the MR also assumes the role of a DRA co-located 

OK, thanks. We'll make a modification along your proposed text.

> can you please turn the sentence involving the normative "MUST" from 

OK, we'll do it.

> - Expand terms at first occurrence. This include at least "BU".

OK, this has been also pointed out by another reviewer. We'll go through
the whole text and ensure terms are properly expanded.

> There are other instances of this issue throughout the document.

OK, we'll do it.

> If possible, I would recommend the authors to expand all the acronyms for 

This has also be pointed out by another reviewer. We'll try to avoid
make such a heavy use of acronyms by expanding some of them.

Thanks again for your comments!

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 21 Sep 2010 07:54:18 +0200

> I do not think this specification updates RFC 3315: This specification has no impact on an implementation that only implements RFC 3315 and does not implement this specification.

Let me highlight this text in Section 3.3:

    Querying an HA to determine if it provides DHCPv6PD requires a small
    modification to the operation of DHCPv6 as described in RFC 3315.

Isn't that a confession of this document updating RFC 3315? Isn't it so 
that if someone has implemented RFC 3315 and now wants to implement this 
draft and integrated, it needs to slightly change its implementation of 
RFC 3315? Therefore, I believe this draft updates RFC 3315.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 23 Sep 2010 09:30:13 -0700

Hi Miguel,

[ I am CC'ing Dan and Jouni here because Jouni had a related comment in his OPS-DIR review. ]

Miguel A. Garcia wrote:
> >>> update to the procedures of RFC 3315. Therefore, RFC 3315 should be
> >>> listed in the cover page of the draft as "Updates: RFC 3315". This is
> >>> for the RFC Editor to properly update the RFC database and when people
> >>> search for RFC 3315 they can find that there is an update in your draft.
> >>
> > I do not think this specification updates RFC 3315: This
> > specification has no impact on an implementation that only implements
> > RFC 3315 and does not implement this specification.
> >
> > --julien
> 
> that if someone has implemented RFC 3315 and now wants to implement
> this draft and integrated, it needs to slightly change its implementation of

No, there are no changes to implementation required, only to operation of the DHCPv6 implementation. Section 3.3 recommends that the client be configured retransmits no more than five times its Solicit message, instead of forever as recommended by 3315. Section 3.3 also explains why this recommendation is made (to allow for a mobile router to try different HAs until it finds one that supports DHCPv6 prefix delegation.

How about we clarify the text as below:

   Querying an HA to determine if it provides DHCPv6PD requires different
   operational variables than those recommended by the DHCPv6 specification
   [RFC 3315]. RFC 3315 recommends that under normal circumstances, a host will
   continue to send DHCPv6 Solicit messages until it receives a response 
   (see Section 17 of RFC 3315), i.e., the Maximum Retransmission Duration (MRD) 
   and Maximum Retransmission Count (MRC) are both set to zero. However, an HA may not
   respond to the Solicit messages from the MR because the HA does not support
   DHCPv6 prefix delegation.  Therefore, when querying an HA to determine if the
   HA provides DHCPv6PD service, it is RECOMMENDED that MRD and MRC be set to
   non-zero values so that the MR discontinues sending Solicit messages to the 
   HA after sending 6 Solicit messages, and conclude that the HA will not provide
   DHCPv6PD service.  Sending 6 queries provides enough reliability for scenarios 
   in which the wireless connectivity is lost for a short period after sending the
   first BU message.

--julien

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 24 Sep 2010 08:35:22 +0200

Hi Julien:

My opinion is that, even when the implementation is not updated, but just 
the operation of RFC 3315, I think this is an update to the text written 
in RFC 3315.

I think you should follow the advice of your AD. I am just pointing out 
my opinion, but I have no decision power here.

BR,

        Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain