Re: [Anima] Handling of endpoint path names (from BRSKI-AE discussion today)

["Fries, Steffen" <[e-mail]>]

> From: Toerless Eckert <[e-mail]>
> Sent: Donnerstag, 30. Juli 2020 18:32
 
> 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.

>From my perspective the endpoint naming is independent from BRSKI-AE and we basically came to the discussion based on the illustrative example for the discovery option in BRSKI-AE.  So keeping it in BRSKI-AE and making it independent upon further need also works. We may reuse the text then for a separate document if necessary.
I conclude that the WG is in favor of this way.

Best regards
Steffen

> 
> Cheers
>     Toerless
> 
> > Eliot
> >
> > > On 30 Jul 2020, at 17:46, Fries, Steffen <[e-mail]>
> 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:[e-mail]
> > >
> 
> --
> ---
> [e-mail]