Pascal Thubert (pthubert) <[email protected]> wrote: pt> · We should not say the following:
txt> When the JRC is not co-located with the 6LBR, then the code point
txt> provides a clear indication to the 6LBR that this is join response
txt> traffic.
pt> This seems to indicate that the traffic class may only be applied to
pt> join response. In the future, we may apply that behavior to other
pt> traffic. That’s linked to the point of having a class.
Maybe we could write:
new> When the JRC is not co-located with the 6LBR, then the code point
new> provides a clear indication to how the 6LBR should prioritize this
txt> traffic.
txt> Companion SF documents SHOULD specify how traffic with code point
txt> AF42 is handled with respect to cell allocation.
pt> I’m not too happy with a SHOULD directed to an unnamed future spec as
pt> opposed to an implementer. Unsure how the IESG will react to that.
I see this as adding a requirement on future SF documents.
So updates draft-ietf-6tisch-6top-protocol section 4.
(It's practically an RFC)
> The Uri-Host option is set to "6tisch.arpa". This is an anycast type of
> identifier of the JRC that is resolved to its IPv6 address by the JP
> Suggestion: "default-jrc.6tisch.arpa".
Why make it longer? Note that it's already to a unique Path-URI (/j), so we
can add new things if it's CoAP.
> All in all, this is an excellent and very clear document, congratulation.
> Do you expect 06 to be ready for WGLC?
I need to do updates to IANA Considerations, but then, I think yes.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
