> From: Toerless Eckert <[email protected]> > 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 <[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
