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

[Weijun Wang <[e-mail]>]

https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-07 posted.

Thanks
Weijun

> On Feb 9, 2018, at 6:32 AM, Benjamin Kaduk <[e-mail]> 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 <[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
>>