Re: [Gen-art] [kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06

[Benjamin Kaduk <[e-mail]>]

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 <[e-mail]> 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
>