Toerless Eckert <t...@cs.fau.de> wrote:
> Registrars need to discoverable anyhow for their IP address. ANd
> every announcement does include a UDP port number anyhow.
And the protocol which to use on that UDP port.
> And
> expecting that all stateful registrars operations can always be
> runniing over the default coap port is contradicting the
> purpose of discovery and should fail any reasonable INT IESG review
> IMHO.
I don't like this term "stateful registrars".
That implies that there are stateless registrars :-)
There are no such things.
Whether it's DTLS, OSCORE, HTTPS, CoAP or TCP, there is state associated with
all of these things.
_But, I think that you mean that there are registrars that support stateless
proxies_
> Besides, i do not believe that all code on all target devices will
> always share a single coap stack. It would be bad if constrained
> brski would only work well on those most constrained devices where you
> MUST use a single coap stack for code-size reasons, but will not
> work on larger devices where every app easily integrates its own
> coap stack and therefore has its own sockets for it.
I don't really understand this comment at all.
If there is code space for five CoAP stacks, fine.
Then you talk about sockets.
I don't understand where you think we are sharing sockets.
>> > I don't see that implementations would get more complex, but rather
>> > simpler if we simply are able to distinguish the different protocol
options
>> > by their service name/parameters and have proxies/clients be able to
select
>> > them.
>>
>> I think that we did exactly this.
> Will only work if registrars can announce which port runs brski with
est-coaps and
> which port runs brski with est-coap-jpy.
Yes. In which place did I say differently?
> IMHO suggested text:
> Registrars discovered for BRSKI MAY also be used by enrolled devices
> for certificate/key renewal using the enrolled certificate.
But, they can't.
When a pledge discovers a path to a Registrar via a join-proxy, it is on a
untrusted network. Once enrolled, it is on a trusted network.
When a join proxy proxy discovers a Registrar, it may be via some specific
transport ("stateless"), and that Registrar might not even be the right EST
end point on which to renew.
Isn't this why RFC8994 has section 6.2.5.1 on GRASP objective SRV.est?
If you want constrained-voucher (not join-proxy) to include an update to this
to specify how RFC9148 (EST-COAPS) can be announced within this objective,
then I have no problem with that.
https://github.com/anima-wg/constrained-voucher/issues/227
I don't know if we need a new objective, or just a new objective-value.
I think just a new objective-value.
I think that the example in figure 4 is actually wrong, beccause the
objective-value is not correctly explained.
>> > IF implementers of a new variant feel that all existing/deployed
registrars
>> > will and should be able to support the new protocol variant (e.g.:
brski-xmp-xyz),
>> > then that protocol option does not need to come up with a new
>> > variation.
>>
>> You can bikeshed the names. I don't really care.
> Nonono ;-) You (constrained) folks bikeshed' the names by introducing
brki-jp and brki-rjp
> instead of just reusing brki-registrar and brski-proxy from RFC8995. To
save 3 or 6 bytes.
I don't think that we did this to save any bytes.
RFC8995 defines
*objectives* AN_Proxy and AN_join_registrar
with objective-values: "" and "EST-TLS"
It was a mistake to have "" for AN_proxy.
Constrained-join-proxy uses:
*objectives* AN_Proxy and AN_registrar (my mistake, it should be
AN_join_registrar)
with objective-values: "" and "BRSKI_RJP"
BRSKI.RJP was picked to match the mDNS value.
> I only care about distinguishing the names for different protocol
versions so i get
> automatically working registrar and port selection tht will be
interoperavble
> without expecting a superset-of-all-protocols implementation on a
registrars.
Well, I think we are in violent agreement.
It doesn't matter whether the Registrar implements everything. The stateful
and stateless join proxy protocols need to connect to the correct ports
regardless.
>> The "standard" interface from a join proxy to the pledge (if it's DTLS)
is to
>> use CoAP over DTLS, on the port given. The details of how it gets back
to
>> the Registrar is irrelevant to the pledge.
> Right - miscommunication - i was only worried about the pledge knowing
which port a registrar
> supports statefull and/or stateless. The pledge doesn't see a difference.
Good, as long as we agree here.
> I think it would be useful to have a sentence for marketing somehwere in
the constrained
> proxy document saying how this proxy is easily reuseable for any future
enrolment
> protocol variations (for example using the fictional EST-COAP-OSCORE as
an example):
> the whole stateful/stateless operation stays the same, only the
service-names for
> discovery would need to be reinvented. And of course big proxies could
run all those
> protocols in parallel.
I'm worried about implying things which might not turn out to be true, and
which IESG members will jump on implying some kind of magic forward
compatibility with things not yet invented.
Where do you suggest we put this sentence?
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
