On 31-Jul-20 05:14, Brockhaus, Hendrik wrote: > Toerless > > I have one question to better make up my mind. > How long do you thing would the change to the BRSKI document delay the > approval process?
That is utterly unpredictable. Since this is a real technical change, we'd need the chairs to formally establish WG consensus and then, as far as I can tell, we have invalidated the IETF Last Call and so we're back to that and a Security Area review etc. After recent experience, I have no idea whatever how long that would take. So I *strongly* believe that we should make a separate document. It's an extension, not a change, so it really doesn't need an Updates: tag. Brian > Finally this change is quite easy to explain. And from my point of view, > doing this change to BRSKI before approval, would be, from a standardization > point of view, the clearest solution. > > Hendrik > >> -----Ursprüngliche Nachricht----- >> Von: Toerless Eckert <[email protected]> >> Gesendet: Donnerstag, 30. Juli 2020 18:32 >> An: Eliot Lear <[email protected]> >> Cc: Fries, Steffen (CT RDA CST) <[email protected]>; Michael >> Richardson <[email protected]>; Brockhaus, Hendrik (CT RDA CST SEA-DE) >> <[email protected]>; [email protected] >> Betreff: Re: Handling of endpoint path names (from BRSKI-AE discussion today) >> >> 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 > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
