On 9 Jul 2014, at 5:02 am, Sandra Murphy <[email protected]> wrote:

> 
> On Jul 7, 2014, at 9:11 PM, Sean Turner <[email protected]> wrote:
> 
>> On Jul 07, 2014, at 19:42, Sandra Murphy <[email protected]> wrote:
>> 
>>> 
>>> On Jul 7, 2014, at 7:00 PM, Geoff Huston <[email protected]> wrote:
>>>> 
>>>> Whats the relationship between this draft and draft-ietf-sidr-rfc6485bis?
>>> 
>>> So you want to know if bgpsec-algs is updating the original RFC6485 or 
>>> updating rfc6485bis?
>> 
>> draft-ietf-sidr-bgpsec-algs adds support for EC public keys & signature 
>> formats to RFC 6485 for BGPsec.  If 6485bis is going to be updated to 
>> include these changes then draft-ietf-sidr-bgpsec-algs can go away but I 
>> didn’t think that was the plan.  Assuming EC algs aren’t incorporated in 
>> 6485bis then draft-ietf-sidr-bgpsec-algs needs to update RFC 6485 or any 
>> document that obsoletes it.  I’m happy to change the updates header info to 
>> “Updates: draft-ietf-sidr-rfc6485bis (once approved)" though if that makes 
>> things crystal clear.
>> 
> 
> The rfc6485bis draft is intended to clean up errors in RFC6485.  That should 
> progress.  Implementations already comply with the corrected text.
> 
> The bgpsec-algs draft is adding new algorithms to be used in new RPKI objects 
> and in the bgpsec protocol.  The bgpsec-algs draft should be updating the 
> rfc6485bis document.  As there's still work in progress here, there should be 
> no problem with the order of publication.  I can see that there are several 
> references to RFC6485 in bgpsec-algs that will have to take the final 
> publication of rfc6485bis draft into account, in order to clear up the 
> relationships.
> 

this seems to me to be a deliberate decision to proliferate more documents.

- we are updating rfc6485 to clean up an error

- we are updating rfc6485 to add crypto profiles for BGPSEC router use

And out of this the chair is saying "lets have TWO documents", RFC6485bis and 
RFC6485bisupdate

If this is what you are saying, then as a WG member I strongly disagree with 
this edict from the chair. We should consider the poor consumer of our various 
efforts and try to consolidate our work, and not proliferate the madness across 
many documents in such a profligate manner! (0.5 :-))

Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to