[6tisch] Mirja Kühlewind's Discuss on draft-ietf-6tisch-minimal-security-13: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-6tisch-minimal-security-13: 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-6tisch-minimal-security/



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

1) I hope this point can be resolved quickly as it seems to only need a bit
more specifics but I think this part is not sufficient:

Sec 6.1: "The Join Proxy implements a data cap on outgoing
   join traffic through CoAP's congestion control mechanism."

I think this needs an normative requirement here. Congestion control is
supposed to avoid network overload but also to make use available resources.
The congestion control as currently defined  for CoAP would probably limit the
join traffic appropriately (to something like one packet per RTT likely) but
CoAP could in theory use any time a different more aggrieve congestion and
therefore just relying on congestion control generically doesn't seem to be
sufficient. I recommend to define a hard limit, e.g. 1 packet per RTT or 1
packet per 3 seconds if RTT is unknown (as recommended in RFC8085) and say that
this can be achieved by congestion control as specified in the base CoAP spec.
Further on there seems to be an implicit requirement that the JP MUST implement
rate limit using the PROBING_RATE parameter, however, that is never explicitly
spelled out as a normative requirement. However, if this rate is not provided
by the JRC, it doesn't seem that any rate limiting has to be enforced. So maybe
it would be good to be more strict here.

2) Also, not  sure if this editorial or a real issue but I'm not sure I fully
understand this sentence:

Sec 6.1.1: "A Join Proxy that does not set the DSCP on traffic
   forwarded should set it to zero so that it is compressed out."
If the proxy does NOT SET DSCP, why should it SET it to zero? I would think it
either sets it to AF43 or it does nothing about it because DSCP is not really
used in that network. I guess it's not a big issue and setting to zero seems
fine as well but I'm afraid I don't understand the intent here and when exactly
the Proxy is supposed to set to AF43 or bleach.

3) This may also be mostly editorial but just to be sure: Section 7.2 provides
default values for some of the CoAP transport parameter (where 2 of 3 are the
same as defined in RFC7252) but not for all. Why is that?

4 ) And then finally on references (again):
Given that use of I-D.ietf-core-stateless is recommend, I believe it should be
normative (and wait for publication of that doc).


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

I'm putting this one question in the comments section because there is no
concern that it does not work as specified but I wonder about the design of the
Parameter Update Response Message. Given the Parameter Update Message is a
confirmable CoAP message that is transmitted reliable and the content of the
Parameter Update Response Message is empty, why do you need to send the
Parameter Update Response Message at all?

And some minor comments (mostly editorial proposals):

0) I'd recommend to "Constrained Join Protocol (CoJP)" in the document title to
make clear that this is a protocol spec and not "only" and abstract framework
or something...

1) Sec 3: Maybe I'm missing something but this seems contradictory:
"Provisioning the network identifier is RECOMMENDED."
And then at the end of that paragraph: "This parameter MUST be provisioned to
the 6LBR pledge."+

2) Sec 4.3.2: Not sure I fully understand the context of this sentence:
"The JP operates as the application-layer proxy."
Maybe "... operates as an application-layer proxy" or probably even better
"operates as application-layer proxy" ? Also at this part of the document it is
not clear that the proxy actually interprets the CoAP message. I recommend to
mention this earlier in the doc and maybe add a forward reference to section 7.

3) Sec 5: Maybe just to be absolutely clear:
OLD: "When sending frames during the join process, the pledge sends
   unencrypted and unauthenticated frames."
NEW: "When sending frames during the join process, the pledge sends
   unencrypted and unauthenticated frames at the link layer."

4) Sec 6: "As a special case, the 6LBR pledge is expected to have an additional
   network interface ..."
MAYBE: "As a special case, the 6LBR pledge may have an additional
   network interface ..." ?