On Thu, Jul 30, 2020 at 06:06:09PM +0200, Eliot Lear wrote:
> Steffen
>
> I enjoyed today???s discussion. My suggestion is a short document that does
> not CHANGE endpoints but simply creates new ones that have the same
> functionality as the old ones. That doesn???t require an ???Updates???
> header, and based on that I think you might even keep these in the same
> document. Would people be ok with that?
Right. So the question is keep it in the document or put it into a separate
small one. The small one would allow other derivative work not to have to
have BRSKI-AE as a normative reference, which may be better if its got nothing
to do with BRSKI-AE.
I guess we can delay the decision up to the point when we do see such other
derivative work coming up, and then decide whether to separate out the
new /brski naming from the doc. As long as there is no such additional doc,
we keep things in BRSKI-AE as they are right now.
Cheers
Toerless
> Eliot
>
> > On 30 Jul 2020, at 17:46, Fries, Steffen <[email protected]> wrote:
> >
> > Hi,
> >
> > Based on the discussion of splitting up the voucher handling endpoint
> > naming issues from BRSKI-AE today, I just wanted to ensure I got the way
> > forward right.
> > From the Etherpad discussion I understood Michael that he would not be too
> > happy with having a BRSKI update right after BRSKI publication as RFC. I
> > think finalizing the discussion on the list was advised.
> >
> > What we discussed in the WG meeting was to have a separate short document,
> > basically defining a renaming or alternatively an alias for the current
> > endpoints, which allows to keep the current implementations as is.
> > Hence, the draft would relate to all of the endpoints defined in section 5
> > of BRSKI for the domain registrar facing the pledge (and potentially also
> > the MASA), which are:
> > /.well-known/est/requestvoucher used by pledge to registrar but also
> > from registrar to MASA
> > /.well-known/est/voucher_status used by pledge to registrar
> > /.well-known/est/requestauditlog used by registrar to MASA
> > /.well-known/est/enrollstatus used by pledge to registrar
> >
> > From Toerless I understood that he would like to not change the current
> > draft as it is already in the final state and rather provide an update as
> > separate document.
> > From Michael I understood he would not be keen on having a fast update for
> > the BRSKI document. At least not for a renaming of the defined endpoints.
> > Also the IESG may view this as too fast.
> > Eliot stated that there are already implementations out there that utilize
> > the /est approach. So having aliases could be one way of dealing with it,
> > but this would double the endpoints at least for the four stated ones
> > above.
> >
> > Both approaches have there merits. Having the endpoints distinct from the
> > beginning allows a clearer separation of the functionalities, for the
> > pledge and for server side handling. Specifically if we later on allow for
> > alternative enrollment protocols in BRSKI-AE and define the discovery
> > approach, it will lead to less confusion to align the naming with the
> > corresponding functionality. From that perspective, my gut feeling would be
> > that an integration into base BRSKI may be more appropriate. On the
> > contrary, it will slow down the process, but somebody stated that there are
> > examples that these changes have been also done in the past and could be
> > done fast.
> >
> > What do you suggest as way forward?
> >
> > Best regards
> > Steffen
> >
> >
> > --
> > Steffen Fries
> > Siemens AG, Corporate Technology
> > mailto:[email protected]
> >
--
---
[email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
