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

[Michael Richardson <[e-mail]>]

Mirja Kuehlewind <[e-mail]> wrote:
    > Sorry for my late reply (but I guess you could have just went ahead and
    > push a new version anyway…). Please see below.

My edits went into a new version which Malisa did push out.

    >>
    >>
    >>> 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.
    >>
    >> I think you are saying that we should have a default PROBING_RATE, if the JRC
    >> does not specify one.  I think that we assumed that the RFC7257 section 4.8
    >> value of 1 byte/second would apply. please confirm?

    > Yes, stating this explicitly would be good!

-Following {{RFC7252}}, the average data rate in sending to the JRC must not exceed PROBING_RATE.
+Following {{RFC7252}}, the average data rate in sending to the JRC must not exceed PROBING_RATE, which specifies a default of 1 byte/second.

    >>> 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?
    >>
    >> Because RFC6282 (and friends) has specific encoding to omit DSCP if it is zero.

    > I understand what you want to do but saying “does not set” but “should
    > set” seems to be contracting. I think this is only a wording issue
    > though. I guess it could be something like this:

    > "A Join Proxy that does not require a specific DSCP value on traffic
    > forwarded should set it to zero so that it is compressed out.”

Done.

    >>> 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?
    >>
    >> We got pushback about relying on 7252 defaults, because what if they changed.

    > That’s fine but the you need to add all values!

Malisa?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-