Hiya, On 09/05/2019 12:49, Joel M. Halpern wrote: > A big part of the problem I see, which I see addressed by this draft, is > that as currently constituted we can not fix many existing protocols > without doing a major modification to address security and / or privacy > issues. I guess we may have different definitions of "fix":-) I totally agree that it's not feasible to address all legacy security and privacy issues in all bis documents. I don't agree that bis documents ought get a free pass wrt such issues where they exist. > > Hence the bit of text being discussed about not having DISCUSS or > Abstain on the basis of not fixing existing security and privacy issues > is important. > > ADs are free to comment, and every WG I have seen takes such comments > seriously. So if the AD thinks there is a simple improvement in > security and / or privacy that ought to be included, they can ask about it. In my little head, that is what most security/privacy DISCUSS ballots on bis drafts tend to be. Adam's draft seems to me to call for ADs to not ask/chat/discuss such issues, and I don't agree with that level of non-discussion being the expectation. Cheers, S. > > Yours, > Joel > > On 5/9/19 6:28 AM, Stephen Farrell wrote: >> >> Hiya, >> >> I've read the draft and like it except for the bit >> SM quotes below. >> >> On 09/05/2019 09:34, S Moonesamy wrote: >>> Hi Adam, >>> >>> There is the following sentence in Section 3.2 of >>> draft-roach-bis-documents-00: >>> >>>   "IESG members SHOULD NOT issue DISCUSS or ABSTAIN ballot positions >>>    based on unchanged text except as described in Section 3.3." >> >> I'm fine with the idea that the IESG would mostly just >> review the diff, and the IESG do need to respect the >> fact that existing RFC text has IETF consensus, but I >> don't think it's ok to try to force ADs to ignore security >> or privacy issues that the proponents of a bis would >> like to ignore. I read the text above as doing that. I'm >> not saying that all such things ought always be fixed in >> bis drafts as we clearly do not do that, but a SHOULD NOT >> DISCUSS seems wrong. >> >> Separately, if enough ADs ABSTAIN then the draft should >> have a problem. ABSTAIN ballots weren't that common when >> I was on the IESG so unless that's changed a lot I don't >> think that clause is useful or advisable. >> >> So if that text stays in, I would hope that ADs would >> ignore it and try do what they consider correct. That may >> be another argument to not have a SHOULD NOT - just say >> that the goal is to keep reviews to the diff. >> >> Lastly, I'd leave out that text because even if it were >> what the IESG wanted, it ought be in the discuss-criteria >> IESG statement and not in an RFC/BCP that derives from >> this draft. (It is good that it's there now, so I can >> whine about it though:-) >> >> Cheers, >> S. >> >> >>> >>> Why is an ABSTAIN an issue? >>> >>> What about IESG member "comments"? Can those comments be ignored? >>> >>> Regards, >>> S. Moonesamy >>> >>> >
Attachment:
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
