https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-07 posted.
Thanks Weijun > On Feb 9, 2018, at 6:32 AM, Benjamin Kaduk <[email protected]> wrote: > > 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
