On Wed, Jul 17, 2019 at 01:10:48PM -0400, Michael Richardson wrote:
> Toerless Eckert <[email protected]> wrote:
> > Errata 5107 on the other hand seems to be asking to remove CTE header
> > by default, but doesn't really say what to do with 7030 base64 payload.
> > One could interpret it to send binary which would be backward
> > incompatible, or one could interpret it as sending base64 by mutual
> > agreement, but without explicitly writing this into a text its
> > guesswork.
>
> Based upon feedback on the -00 and -01, it appears that nobody actually sends
> the CTE header, so we have no signal about it being binary or base64, and
> everyone just sends base64. So the clarification becomes that the CTE
> header is redundant, should be ignored, and the payload is always base64.
Great. That could be written more explicitly in the draft.
> If we did an rfc7030bis, then we might define new end-points, but that seems
> like busy work to me.
Agreed. A small update RFC will be much more economical and if well
written also much easier to understand.
> > What seems to be incomplete in your draft is whether to send or not to
> > sent CTE, it only says to ignore it upon receipt. So, whats the minimum
> > requirement for fully backward compatibility on sending ?
>
> always base64 the payloads
I figured that. But i think you are also saying that you do
not need to send CTE to be backward compatible, thats even better.
> >> 4) ANIMA BRSKI needs to clarify things itself, and I will add a
> >> section on this, but I'm hesistant to add a normative reference here.
> >> I have an idea of appropriate text that I will post on Tuesday.
> >> Getting clarity here is really the most important thing for me.
>
> > I would like to see avoiding to drag this issue into BRSKI text unless
> > we have to. I would simply have a reference to this draft in BRSKI and
> > one sentence about it near the first mentioning of 7030 in BRSKI.
>
> I have added a section to BRSKI that clarifies that, despite EST7030 being
> base64 encoded, BRSKI payloads (voucher, voucher-request) are binary.
Thats ok. to ensure that BRSKI is as independent of an rfc7030 update
draft as possible, but it would be good to also suggest doing this in your updte
draft so that any other rfc7030 extensions could foolow that lead.
Btw: If there is no more feedback from the WGs you addressed in this
mail, please consider asking for a slot on the agenda of eithre of them
anyhow. Much harder for them to ignore the issue in email than in the
room ;-)
(which of course doesn't mean that we shouldn't discuss in ANIMA, but i
guess we agree that any better http/est? expert opinion input would be
helpfull).
Cheers
toerless
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] [email protected] http://www.sandelman.ca/ | ruby on rails
> [
>
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
