[kitten] Genart telechat review of draft-ietf-kitten-rfc5653bis-06

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Weijun Wang
Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/.

@@ -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 <[hidden email]> 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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
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 <[hidden email]> 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
>

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

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

Thanks
Weijun

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

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
12