[manet] Mirja Kühlewind's Discuss on draft-ietf-manet-dlep-26: (with DISCUSS and COMMENT)

["Mirja Kuehlewind" <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-manet-dlep-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Am I missing something or does the doc not specify which policy/policies
should be used for registration of new values in these new registries?
(Also previously mentioned by the tsv-art reviewer - thx!)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Technical comments:
1) You say
"If a Signal is received with a TTL value that is NOT equal to 255,
   the receiving implementation MUST ignore the Signal."
and 
"If a packet in the TCP stream is received with a TTL value other than
   255, the receiving implementation MUST immediately transition to the
   Session Reset state."
However, there is no requirement that the initial TTL must be 225. I
guess you can just add a sentence to require this from the sender.

2) You say:
"If an unrecognized, or unexpected Signal is received, or a received
   Signal contains unrecognized, invalid, or disallowed duplicate Data
   Items, the receiving implementation MUST ignore the Signal."
Would it make sense to also send an error signal in this case or was this
omitted as it could be used as a DoS reflector? If so, maybe add a
sentence. 

3) in section 10.5:
"DLEP Heartbeats are not fully established until receipt of the
   Session Initialization Response Message (Section 10.6), and therefore
   implementations MUST use their own timeout and retry heuristics for
   this Message."
I'm not sure if re-trying makes sense given that TCP should deliver the
data reliably here. I guess time-out to terminate the TCP and a local
error log would be more appropriate.

4) section 11.16:
"The Latency value is reported as transmission delay.  The calculation
   of latency is implementation dependent.  For example, the latency may
   be a running average calculated from the internal queuing."
Not sure if this is very useful. I would either recommend to define to
report the average (or max?) latency (where the calculation is still of
course implementation specific) or have three different items for min,
max, and current average.

Editorial comment: 
The 2119 boilerplate has a weird position as part of a subsection. I
assume that this is intended to say that the normative text starts here
but it could also be interpreted to be just part of the subsection. Also
having 'Requirements' (3.1) as subsection of 'Extension' (3) seems to be
an error. I would suggest to have the 2119 boilerplate as well as the
Requirements section both as own main level sections. And sec 3 and sec 7
are both called 'Extensions'...?

Further:
I didn't see a reply to the tsv-art review by Micheal Scharf. Have those
comments be addressed?
Here is his review on -25:
This draft is basically ready for publication, but has nits that should
be fixed before publication.

TSV-ART review comments:

* I think the DLEP protocol makes an implicit assumption that the 1-hop
link between the router and the modem is unlikely to become a bottleneck,
e.g., because its bandwidth is larger than the maximum possible bandwidth
of the modem. I assume that in typical deployments this condition can be
fulfilled, and the hop count limitation provides some safety measures.
Yet, the link between the router and modem could possibly run over a
tunnel, with unknown performance characteristics (e.g., another wireless
backhaul link). It is unclear what a router would indeed learn from the
information provided by DLEP in such a case. This scenario is not the
target environment for the protocol, but it would make sense to more
explicitly spell out that assumption, e.g., in Section 1.  

Other comments:

* Page 9: "If the router and modem support both IPv4 and IPv6, the IPv6
transport MUST be used for the DLEP session." seems inconsistent with
page 21: "For routers supporting both IPv4 and IPv6 DLEP operation, it is
RECOMMENDED that IPv6 be selected as the transport."

* I am not an IANA expert but at first sight the IANA section does not
comprehensively describe the policy for modifying the IANA registries
(Section 4 in RFC 5226). Is it "Standards Action"? This in particular
matters for the extensions in Section 13.6.