On Thu, Feb 08, 2018 at 11:36:23AM +0800, Weijun Wang wrote: > Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/.
Great! I think that once you submit the new revision, it's up to Ekr to verify that the diff addresses the point raised by Alissa/Joel and then inform the secretariat that the document is approved. Thanks again, Ben > > @@ -410,7 +410,7 @@ > of sequence. > > Anonymous Authentication: The establishment of the security > - context SHOULD not reveal the initiator's identity to the context > + context SHOULD NOT reveal the initiator's identity to the context > acceptor. > > Some mechanisms may not support all OPTIONAL services, and some > @@ -2665,7 +2665,7 @@ > ability may depend on the availability of system resources at the > time that wrap is called. However, if the implementation itself > imposes an upper limit on the length of messages that may be > - processed by wrap, the implementation SHOULD not return a value that > + processed by wrap, the implementation SHOULD NOT return a value that > is greater than this length. > > Parameters: > @@ -2855,7 +2855,7 @@ > The implementation MAY constrain the set of processes by which the > inter-process token may be imported, either as a function of local > security policy, or as a result of implementation decisions. For > - example, some implementations MAY constrain contexts to be passed > + example, some implementations may constrain contexts to be passed > only between processes that run under the same account, or which are > part of the same process group. > > @@ -3046,7 +3046,7 @@ > public boolean isProtReady() > > Returns "true" if the per-message operations can be applied over the > - context. Some mechanisms MAY allow the usage of per-message > + context. Some mechanisms may allow the usage of per-message > operations before the context is fully established. This will also > indicate that the get methods will return actual context state > characteristics instead of the desired ones. > @@ -3713,7 +3713,7 @@ > > outputToken The output token that SHOULD be sent to the peer. > Can be null if no such token is available. It > - MUST not be an empty array. When provided, the > + MUST NOT be an empty array. When provided, the > array will be cloned to protect against > subsequent modifications. > > Thanks > Weijun > > > On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk <[email protected]> wrote: > > > > On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote: > >> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should > > [line 2519] > >> --> SHOULD, since elsewhere we use SHOULD > >>> for sending the error token to the peer. > >> > >> No opinion. You could make a case for "that should be sent" being > >> either descriptive on the token or prescriptive on the application. > > > > Re-reading, I agree with you and retract the suggestion. > > > >>> Line 2561, I could go either way on "may" vs. "MAY" -- the argument > >>> for the former would be that it's just stating an attribute of the > >>> operation, and this text is describing something specified elsewhere > >>> and not introducing any restrictions or giving guidance on it. > >>> Similarly for acceptSecContext on line 2597. > >> > >> I think that's a MAY. It seems prescriptive on the method implementation. > > > > Okay. > > > >>> Line 2668, SHOULD not --> SHOULD NOT > >> > >> Agree. > >> > >>> Line 2858, MAY --> may, since this is just describing what some > >>> implementations could be doing and not exactly granting permission > >>> for it. > >> > >> Sure, and it's an example. > >> > >>> I guess for consistency I should say the same thing about line 3049. > >> > >> I guess "may" here, but no strong opinion. > >> > >>> Line 3716, MUST not --> MUST NOT > >> > >> Agree. > > > > Thanks for double-checking my work. > > > > -Ben > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
