Ah so I guess this one is informational so it could proceed without the waiting for all the refs, but I do think we can ask the RFC editor to hold it for at least the normative refs. When progressing a block of drafts, there’s always a bunch of tradeoffs to deal with: 1) Will the IESG be upset by having to read a couple of hundred pages, 2) What’s the right order of the drafts to hit the IESG agenda, 3) Will we need to change something in the overview draft, etc. I’ve come to think that when the WG thinks a draft is done we should push it upstream and let them deal with it in the order that it comes. We can let the IESG place discusses that hold the draft before it gets to the RFC editor based on whatever criteria they feel is appropriate, or the RFC editor can hold it because of their processes - basically we should get things off our plate ASAP so that we can focus on other things. Obviously YMMV.
spt On Oct 13, 2015, at 09:39, Samuel Weiler <[email protected]> wrote: > The doc cites a bunch of i-d's. Under previous practice, that would have > left it languishing in the RFC Editor queue waiting for the others. If that > were the practice now, I would suggest we hold it and release all of the docs > as a group, which would permit later changes to this doc if needed. I think > current practice does allow citing i-d's (though version numbers need to be > specified), but I'm wondering if we wouldn't be better off waiting. This is > the first BGPsec doc many will read - I would prefer to have it be correct > and complete even if we make changes in the other docs along the way. > > Other than that, no issues with the doc - it's in good shape. > > Minor nits sent separately to the editors. > > -- Sam Weiler > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
