Last Call Review of draft-ietf-manet-dlep-25

[Matt Miller]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.

Document: draft-ietf-manet-dlep-25
Reviewer: Matthew A. Miller
Review Date: 2016-11-28
IETF LC End Date: 2016-11-28
IESG Telechat date: 2016-12-15

Summary:

This document is almost ready to publish as a Standards Track
document, but has one major issue that should be resolved, and
some minor issues that may need to be discussed.

Major issues:

* The IANA registries this document establishes are not defined.
One can deduce the required information and its format, but there
is no guidance on review process (for example). I urge the authors
to consult RFC 5226 when revisiting the IANA considerations.

Minor issues:

* I wonder if any consideration was made to use TLS for at least
confidentiality when exchanging DLEP Messages. I can see where
DTLS might not be practicable -- or even possible -- for the
Discovery Signals. However, the session lifecycle for DLEP
Messages makes TLS a better fit.

* In the heartbeats state description (Section 5.3.), it's not
clear that implementations can factor in other received messages
in determining when to send heartbeats. From looking at Appendix
B.7 it's clear that was at least considered, but the text makes no
mention. I think it would be worth expanding on heartbeats to at
least hint at this optimization.

* In the session termination state description (Section 5.4.),
it does not explicitly allow for an unresponsive peer; it states
that an implementation entering this state "MUST wait for a
Session Termination Response Message (Section 10.10) from its
peer", then later hints that an implementation should enter the
Session Reset state when the response is received or it times out.
I suggest that the MUST here explicitly allow for this timeout.

* There seems to be a discrepancy between Section 5.3. "Heartbeats"
and Section 5.4. "Session Termination" with regards to the minimum
number of missed heartbeats before a session should terminate from
no response -- 2 messages versus 4 messages, respectively. I
suggest putting the minimum limit in either Heartbeats or Session
Termination and removing it from the other.


Nits/editorial comments:

* In Section 3.1. "Requirements", the mandate to use RFC5082 is
said twice -- more generally to all of DLEP in the third paragraph
and then specifically to TCP usage in the fifth paragraph.

* In Section 6. "Transaction Model", the term "destination up" is
not capitalized as it is elsewhere.

[Jari Arkko]

Matt,

Many thanks for this.

Authors, did you have any responses on Matt’s comments?

Post by Matt Miller
* The IANA registries this document establishes are not defined.
One can deduce the required information and its format, but there
is no guidance on review process (for example). I urge the authors
to consult RFC 5226 when revisiting the IANA considerations.

What did you have in mind here? At least the -26 specifies Specification
Required for the registries, and given RFC 5226’s guidance on what that
means, I’m not sure what information is missing. Unless, of course, you
think that there should further expert review guidance. Or is the problem

Post by Matt Miller
13.6. DLEP Extensions Registrations
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "Extension Type Values".
The following table provides initial registry values and the
+--------------+----------------------------+
| Code | Description/Policy |
+--------------+----------------------------+
| 0 | Reserved |
| 1 | Credit Windowing [CREDIT] |
| 2-65519 | Specification Required |
| 65520-65534 | Private Use |
| 65535 | Reserved |
+--------------+----------------------------+
Table 3: DLEP Extension types

Jari

[Taylor, Rick (External)]

Hi Matt,

Thanks for the review, some (slightly late) comments inline...

-----Original Message-----
Sent: 28 November 2016 16:58
Subject: Last Call Review of draft-ietf-manet-dlep-25
I am the assigned Gen-ART reviewer for this draft. The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair. Please treat these comments just like any other last call
comments.
For more information, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq >.
Document: draft-ietf-manet-dlep-25
Reviewer: Matthew A. Miller
Review Date: 2016-11-28
IETF LC End Date: 2016-11-28
IESG Telechat date: 2016-12-15
This document is almost ready to publish as a Standards Track document, but
has one major issue that should be resolved, and some minor issues that
may need to be discussed.
* The IANA registries this document establishes are not defined.
One can deduce the required information and its format, but there is no
guidance on review process (for example). I urge the authors to consult RFC
5226 when revisiting the IANA considerations.

We have received similar feedback from the IANA review which we believe we have addressed in draft-26, which is now published. Could you check to see if we have addressed your concerns as well?

* I wonder if any consideration was made to use TLS for at least
confidentiality when exchanging DLEP Messages. I can see where DTLS might
not be practicable -- or even possible -- for the Discovery Signals. However,
the session lifecycle for DLEP Messages makes TLS a better fit.

You are not the only reviewer to raise the thorny issue of TLS. We have attempted to address this in draft-26.

* In the heartbeats state description (Section 5.3.), it's not clear that
implementations can factor in other received messages in determining when
to send heartbeats. From looking at Appendix
B.7 it's clear that was at least considered, but the text makes no mention. I
think it would be worth expanding on heartbeats to at least hint at this
optimization.

As Stan Ratliff replied to Ben Campbell (who also raised this point):

Our intent was for other messages to "count" as heartbeats - Section 5.3.1 (Heartbeats), says in part: "Receipt of any valid DLEP Message MUST reset the heartbeat interval timer (i.e., valid DLEP Messages take the place of, and obviate the need for, additional Heartbeat Messages)."

* In the session termination state description (Section 5.4.), it does not
explicitly allow for an unresponsive peer; it states that an implementation
entering this state "MUST wait for a Session Termination Response Message
(Section 10.10) from its peer", then later hints that an implementation should
enter the Session Reset state when the response is received or it times out.
I suggest that the MUST here explicitly allow for this timeout.

This was raised by at least one other reviewer and has been addressed in draft-26.

* There seems to be a discrepancy between Section 5.3. "Heartbeats"
and Section 5.4. "Session Termination" with regards to the minimum number
of missed heartbeats before a session should terminate from no response --
2 messages versus 4 messages, respectively. I suggest putting the minimum
limit in either Heartbeats or Session Termination and removing it from the
other.

The intention here was to allow 2 timeouts during normal session flow, but wait up to 4 timeout-intervals for a Session termination Response message before aborting the TCP connection.

On the back of other review comments, we may revisit this text an try to declare some variables that can be referenced to aid clarity in these sections.

* In Section 3.1. "Requirements", the mandate to use RFC5082 is said twice --
more generally to all of DLEP in the third paragraph and then specifically to
TCP usage in the fifth paragraph.

This section has been reworked in draft-26, mentioning RFC5082 only once.

* In Section 6. "Transaction Model", the term "destination up" is not
capitalized as it is elsewhere.

Good catch - will fix!

Sorry for the delay in responding, this is the first time I've gone through this process and I'm not entirely up to speak with etiquette!

Regards,

Rick Taylor

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure.

If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system.

Emails to Airbus Defence and Space Limited may be processed, recorded and monitored anywhere in the European Community.


Airbus Defence and Space Limited

Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS.
Registered in England and Wales unde

[Taylor, Rick (External)]

Hi Jari,

I have (belatedly) responded to Matt's comments which were on draft-25. A lot of his points were made by other reviewers and many have been addressed in draft-26 already.

The IANA reviewer gave us good direction to the correct registration entries/format/detail, and I hope we have got them right in the latest draft.

Regards,

Rick Taylor

-----Original Message-----
Sent: 15 December 2016 09:09
To: Matt Miller
Subject: Re: [Gen-art] Last Call Review of draft-ietf-manet-dlep-25
Matt,
Many thanks for this.
Authors, did you have any responses on Matt's comments?

Post by Matt Miller
* The IANA registries this document establishes are not defined.
One can deduce the required information and its format, but there is
no guidance on review process (for example). I urge the authors to
consult RFC 5226 when revisiting the IANA considerations.

What did you have in mind here? At least the -26 specifies Specification
Required for the registries, and given RFC 5226's guidance on what that
means, I'm not sure what information is missing. Unless, of course, you think
that there should further expert review guidance. Or is the problem that the

Post by Matt Miller
13.6. DLEP Extensions Registrations
Upon approval of this document, IANA is requested to create a new
DLEP registry, named "Extension Type Values".
The following table provides initial registry values and the
+--------------+----------------------------+
| Code | Description/Policy |
+--------------+----------------------------+
| 0 | Reserved |
| 1 | Credit Windowing [CREDIT] |
| 2-65519 | Specification Required |
| 65520-65534 | Private Use |
| 65535 | Reserved |
+--------------+----------------------------+
Table 3: DLEP Extension types

Jari
This mail has originated outside your organization, either from an external
partner or the Global Internet.
Keep this in mind if you answer this message.

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure.

If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system.

Emails to Airbus Defence and Space Limited may be processed, recorded and monitored anywhere in the European Community.


Airbus Defence and Space Limited

Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS.
Registered in England and Wales under company number 02449259.

[Jari Arkko]

Excellent - thanks!

Jari

[Matt Miller]

Thanks all. I have not yet reviewed -26 myself, but a quick perusal
makes me think they have been addressed. As for my comments on the
registries:

Defining the review level within the table did throw me off. Looking at
it again, I think it would be helpful to separate out the registry
definition from its initial values, to make it clearer what is expected
from somewhat wishing to add to the registry.

I think I was also expecting some more guidance, at least what someone
wishing to add to the registry could expect from the reviewers.

That said, if IANA and the expert reviewers-to-be are happy with this,
then that's good enough for me.


Thanks again,

- m&m

Matt Miller
Cisco Systems, Inc.

Post by Jari Arkko
Excellent - thanks!
Jari