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

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25

Summary: This document is ready for publication as a Proposed Standard RFC

Major issues: None

Minor issues:
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Nits/editorial comments:

[Benjamin Kaduk]

Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.

I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.

-Ben

[Joel M. Halpern]

Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

[Weijun Wang]

Hi Joel and Ben

Author here.

I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".

I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.

Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?

Thanks
Weijun

Post by Joel M. Halpern
Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

[Joel M. Halpern]

Personal opinion:
Given that to my reading "must" is used on the document in both the RFC
2119 sense and in a conventional English language sense, it would be
worth clarifying the intention. As such, I think it would be better to
use the 8174 reference and go through changing the right ones to upper case.

Yours,
Joel

Post by Weijun Wang
Hi Joel and Ben
Author here.
I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".
I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.
Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?
Thanks
Weijun

Post by Joel M. Halpern
Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

[Benjamin Kaduk]

I am inclined to agree that it is better to change the right ones to
upper case -- we really don't have a good reason to still be
producing documents with this type of ambiguity anymore.

Once that is done we can decide whether the change is
substantial enough to require re-running the last call.

-Ben

Post by Joel M. Halpern
Given that to my reading "must" is used on the document in both the RFC
2119 sense and in a conventional English language sense, it would be
worth clarifying the intention. As such, I think it would be better to
use the 8174 reference and go through changing the right ones to upper case.
Yours,
Joel

Post by Weijun Wang
Hi Joel and Ben
Author here.
I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".
I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.
Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?
Thanks
Weijun

Post by Joel M. Halpern
Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

[Weijun Wang]

Thanks for the suggestion. I'll go through the doc and post another version.

--Weijun

Post by Benjamin Kaduk
I am inclined to agree that it is better to change the right ones to
upper case -- we really don't have a good reason to still be
producing documents with this type of ambiguity anymore.
Once that is done we can decide whether the change is
substantial enough to require re-running the last call.
-Ben

Post by Joel M. Halpern
Given that to my reading "must" is used on the document in both the RFC
2119 sense and in a conventional English language sense, it would be
worth clarifying the intention. As such, I think it would be better to
use the 8174 reference and go through changing the right ones to upper case.
Yours,
Joel

Post by Weijun Wang
Hi Joel and Ben
Author here.
I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".
I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.
Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?
Thanks
Weijun

Post by Joel M. Halpern
Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

[Weijun Wang]

Hi Ben

I've posted a new draft at

http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

The only changes since -06 are:

1. Newly added "2. Notational Conventions".

2. Convert some of the keywords to UPPERCASE.

For every occurrence of the keywords, I've marked the UPPERCASE ones red and lowercase ones gray so you can easily spot them. Line numbers are added to the text.

I converted most "must" and "should" to UPPERCASE. There are many "may"s. For those having a subject of "mechanism" or "application", I usually leave them in lowercase. For "implementation", I usually change it to UPPERCASE.

Please take a review. I generated this HTML from the output of "xml2rfc --raw". The "xml2rfc --html" looks too modern for me. If you know a way to generate an HTML like https://tools.ietf.org/html/rfc5653 which has a plain text layout while containing links I'll be happy to create my page based on it.

Thanks
Weijun

[Weijun Wang]

Ping agin. If you don't have any comment, I'll post a -08 I-D draft.

Thanks
Max

Post by Weijun Wang
Hi Ben
I've posted a new draft at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html
1. Newly added "2. Notational Conventions".
2. Convert some of the keywords to UPPERCASE.
For every occurrence of the keywords, I've marked the UPPERCASE ones red and lowercase ones gray so you can easily spot them. Line numbers are added to the text.
I converted most "must" and "should" to UPPERCASE. There are many "may"s. For those having a subject of "mechanism" or "application", I usually leave them in lowercase. For "implementation", I usually change it to UPPERCASE.
Please take a review. I generated this HTML from the output of "xml2rfc --raw". The "xml2rfc --html" looks too modern for me. If you know a way to generate an HTML like https://tools.ietf.org/html/rfc5653 which has a plain text layout while containing links I'll be happy to create my page based on it.
Thanks
Weijun

[Alissa Cooper]

Joel, thanks for your review. I think the WG will need to review the changes to make sure people agree with which keywords become capitalized. I’m holding a DISCUSS about that.

Alissa

Post by Weijun Wang
Thanks for the suggestion. I'll go through the doc and post another version.
--Weijun

Post by Benjamin Kaduk
I am inclined to agree that it is better to change the right ones to
upper case -- we really don't have a good reason to still be
producing documents with this type of ambiguity anymore.
Once that is done we can decide whether the change is
substantial enough to require re-running the last call.
-Ben

Post by Joel M. Halpern
Given that to my reading "must" is used on the document in both the RFC
2119 sense and in a conventional English language sense, it would be
worth clarifying the intention. As such, I think it would be better to
use the 8174 reference and go through changing the right ones to upper case.
Yours,
Joel

Post by Weijun Wang
Hi Joel and Ben
Author here.
I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".
I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.
Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?
Thanks
Weijun

Post by Joel M. Halpern
Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

_______________________________________________
Gen-art mailing list
https://www.ietf.org/mailman/listinfo/gen-art

[Weijun Wang]

I've uploaded an updated version at

http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

before submitting a new I-D draft. This page shows all keywords in color (gray for lowercase, red for uppercase), hopefully this will be easy for everyone to review.

Thanks
Weijun

Post by Alissa Cooper
Joel, thanks for your review. I think the WG will need to review the changes to make sure people agree with which keywords become capitalized. I’m holding a DISCUSS about that.
Alissa

Post by Weijun Wang
Thanks for the suggestion. I'll go through the doc and post another version.
--Weijun

Post by Benjamin Kaduk
I am inclined to agree that it is better to change the right ones to
upper case -- we really don't have a good reason to still be
producing documents with this type of ambiguity anymore.
Once that is done we can decide whether the change is
substantial enough to require re-running the last call.
-Ben

Post by Joel M. Halpern
Given that to my reading "must" is used on the document in both the RFC
2119 sense and in a conventional English language sense, it would be
worth clarifying the intention. As such, I think it would be better to
use the 8174 reference and go through changing the right ones to upper case.
Yours,
Joel

Post by Weijun Wang
Hi Joel and Ben
Author here.
I think I've removed the section because in fact none of the keywords appears as capitalized inside the original document. In fact, RFC 8174 has "that only UPPERCASE usage of the key words have the defined special meanings".
I assume I'll need to go through the document and make some UPPERCASE and some not, depending on the actual meanings.
Or, since this is a bis and changing the cases would be considered an re-intepretation of the whole document (which wasn't my goal), is it more reasonable to keep using RFC 2119 and leave all "must" and "required" in lowercase?
Thanks
Weijun

Post by Joel M. Halpern
Thanks Ben. That would be good.
Yours,
Joel

Post by Benjamin Kaduk
Hi Joel,

Post by Joel Halpern
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-kitten-rfc5653bis-06
Reviewer: Joel Halpern
Review Date: 2018-01-02
IETF LC End Date: 2017-09-11
IESG Telechat date: 2018-01-25
Summary: This document is ready for publication as a Proposed Standard RFC
Major issues: None
Although ID-Nits does not complain about it, I can find no reference to
RFCs 2119 or 8174. Some of the uses of "must" int he document are along
the lines of "inherently follows", which is not normative language. But
other uses are clearly normative in structure. It is unclear why the
reference to RFC 2119 was removed as part of this update.

Thanks for the review -- I'm a bit surprised that id-nits does not
complain about the omission.
I do not know why the -00 dropped that clause, but it does seem like
the current normal text citing 8174 should be added before
publication.
-Ben

_______________________________________________
Gen-art mailing list
https://www.ietf.org/mailman/listinfo/gen-art

[Greg Hudson]

Post by Weijun Wang
I've uploaded an updated version at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

This is a great format for reviewing these changes; thanks for
generating it.

Line 416 does not capitalize "optional" in "optional services", but
lines 385 and 391 do.

Lines 422 and 424 should probably capitalize "should". Line 429 should
probably capitalize "may".

At line 598, I would lean towards leaving "MUST" in lowercase as we are
describing an application requirement, not prescribing one.

Line 1174, I would leave "MAY" in lowercase.

Line 1129, "may" should probably be capitalized.

Line 1369, I would leave "MAY" alone as this seems more descriptive than
prescriptive.

Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
request the default QOP. So I would leave it lowercase (or change the
wording, but I'm not trying to open any more cans of worms).

[Weijun Wang]

Hi Greg

Thank you so much for your careful review. All suggestions accepted.

Post by Greg Hudson

Post by Weijun Wang
I've uploaded an updated version at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

This is a great format for reviewing these changes; thanks for
generating it.

Glad you like it. I have to do this to avoid words like the 2nd MAY in the 3rd paragraph on page 45.

Post by Greg Hudson
Line 416 does not capitalize "optional" in "optional services", but
lines 385 and 391 do.
Lines 422 and 424 should probably capitalize "should". Line 429 should
probably capitalize "may".
At line 598, I would lean towards leaving "MUST" in lowercase as we are
describing an application requirement, not prescribing one.
Line 1174, I would leave "MAY" in lowercase.
Line 1129, "may" should probably be capitalized.

1179?

Thanks
Weijun

Post by Greg Hudson
Line 1369, I would leave "MAY" alone as this seems more descriptive than
prescriptive.
Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
request the default QOP. So I would leave it lowercase (or change the
wording, but I'm not trying to open any more cans of worms).

[Greg Hudson]

On 01/28/2018 08:41 AM, Weijun Wang wrote:>> Line 1129, "may" should
probably be capitalized.

1179?

No, that one looks okay. I think I must have meant line 1229: "The
application may use byte arrays..."

[Weijun Wang]

Post by Greg Hudson
On 01/28/2018 08:41 AM, Weijun Wang wrote:>> Line 1129, "may" should
probably be capitalized.

1179?

No, that one looks okay. I think I must have meant line 1229: "The
application may use byte arrays..."

I see. Accepted.

Thanks
Weijun

[Weijun Wang]

The HTML file updated in place.

Thanks
Weijun

Post by Greg Hudson

Post by Weijun Wang
I've uploaded an updated version at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

This is a great format for reviewing these changes; thanks for
generating it.
Line 416 does not capitalize "optional" in "optional services", but
lines 385 and 391 do.
Lines 422 and 424 should probably capitalize "should". Line 429 should
probably capitalize "may".
At line 598, I would lean towards leaving "MUST" in lowercase as we are
describing an application requirement, not prescribing one.
Line 1174, I would leave "MAY" in lowercase.
Line 1229, "may" should probably be capitalized.
Line 1369, I would leave "MAY" alone as this seems more descriptive than
prescriptive.
Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
request the default QOP. So I would leave it lowercase (or change the
wording, but I'm not trying to open any more cans of worms).

[Weijun Wang]

I will submit a new draft tomorrow if there is no other feedback.

Thanks
Weijun

Post by Weijun Wang
The HTML file updated in place.
Thanks
Weijun

Post by Greg Hudson

Post by Weijun Wang
I've uploaded an updated version at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

This is a great format for reviewing these changes; thanks for
generating it.
Line 416 does not capitalize "optional" in "optional services", but
lines 385 and 391 do.
Lines 422 and 424 should probably capitalize "should". Line 429 should
probably capitalize "may".
At line 598, I would lean towards leaving "MUST" in lowercase as we are
describing an application requirement, not prescribing one.
Line 1174, I would leave "MAY" in lowercase.
Line 1229, "may" should probably be capitalized.
Line 1369, I would leave "MAY" alone as this seems more descriptive than
prescriptive.
Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
request the default QOP. So I would leave it lowercase (or change the
wording, but I'm not trying to open any more cans of worms).

_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten

[Benjamin Kaduk]

I am doing a review now. (Line 413, "SHOULD not" --> "SHOULD NOT"
is all I have so far.)

And I will second Greg's comment about this format being an awesome
way to view these changes -- thank you again for putting them
together!

-Ben

Post by Weijun Wang
I will submit a new draft tomorrow if there is no other feedback.
Thanks
Weijun

Post by Weijun Wang
The HTML file updated in place.
Thanks
Weijun

Post by Greg Hudson

Post by Weijun Wang
I've uploaded an updated version at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

This is a great format for reviewing these changes; thanks for
generating it.
Line 416 does not capitalize "optional" in "optional services", but
lines 385 and 391 do.
Lines 422 and 424 should probably capitalize "should". Line 429 should
probably capitalize "may".
At line 598, I would lean towards leaving "MUST" in lowercase as we are
describing an application requirement, not prescribing one.
Line 1174, I would leave "MAY" in lowercase.
Line 1229, "may" should probably be capitalized.
Line 1369, I would leave "MAY" alone as this seems more descriptive than
prescriptive.
Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
request the default QOP. So I would leave it lowercase (or change the
wording, but I'm not trying to open any more cans of worms).

_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten

[Benjamin Kaduk]

And the rest of the review:

Line 2519, I think should --> SHOULD, since elsewhere we use SHOULD
for sending the error token to the peer.

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.

Line 2668, SHOULD not --> SHOULD NOT

Line 2858, MAY --> may, since this is just describing what some
implementations could be doing and not exactly granting permission
for it.

I guess for consistency I should say the same thing about line 3049.

Line 3716, MUST not --> MUST NOT


In general, things looked quite good; I do not think I can say thank
you enough for putting this together.

Greg, would you be able to sanity-check the above (and one below)
comment?

Thanks,

Ben

Post by Benjamin Kaduk
I am doing a review now. (Line 413, "SHOULD not" --> "SHOULD NOT"
is all I have so far.)
And I will second Greg's comment about this format being an awesome
way to view these changes -- thank you again for putting them
together!
-Ben

Post by Weijun Wang
I will submit a new draft tomorrow if there is no other feedback.
Thanks
Weijun

Post by Weijun Wang
The HTML file updated in place.
Thanks
Weijun

Post by Greg Hudson

Post by Weijun Wang
I've uploaded an updated version at
http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html

This is a great format for reviewing these changes; thanks for
generating it.
Line 416 does not capitalize "optional" in "optional services", but
lines 385 and 391 do.
Lines 422 and 424 should probably capitalize "should". Line 429 should
probably capitalize "may".
At line 598, I would lean towards leaving "MUST" in lowercase as we are
describing an application requirement, not prescribing one.
Line 1174, I would leave "MAY" in lowercase.
Line 1229, "may" should probably be capitalized.
Line 1369, I would leave "MAY" alone as this seems more descriptive than
prescriptive.
Line 3221's use of "SHOULD" is prescriptive, but there's no other way to
request the default QOP. So I would leave it lowercase (or change the
wording, but I'm not trying to open any more cans of worms).

_______________________________________________
Kitten mailing list
https://www.ietf.org/mailman/listinfo/kitten

[Greg Hudson]

On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should
--> SHOULD, since elsewhere we use SHOULD

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
Line 2668, SHOULD not --> SHOULD NOT

Agree.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
I guess for consistency I should say the same thing about line 3049.

I guess "may" here, but no strong opinion.

Post by Benjamin Kaduk
Line 3716, MUST not --> MUST NOT

Agree.

[Benjamin Kaduk]

Post by Greg Hudson
On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should

[line 2519]

Post by Greg Hudson
--> SHOULD, since elsewhere we use SHOULD

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
Line 2668, SHOULD not --> SHOULD NOT

Agree.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
I guess for consistency I should say the same thing about line 3049.

I guess "may" here, but no strong opinion.

Post by Benjamin Kaduk
Line 3716, MUST not --> MUST NOT

Agree.

Thanks for double-checking my work.

-Ben

[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

Post by Benjamin Kaduk

Post by Greg Hudson
On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should

[line 2519]

Post by Greg Hudson
--> SHOULD, since elsewhere we use SHOULD

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
Line 2668, SHOULD not --> SHOULD NOT

Agree.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
I guess for consistency I should say the same thing about line 3049.

I guess "may" here, but no strong opinion.

Post by Benjamin Kaduk
Line 3716, MUST not --> MUST NOT

Agree.

Thanks for double-checking my work.
-Ben

[Benjamin Kaduk]

Post by Weijun Wang
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

Post by Weijun Wang
@@ -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.
@@ -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

Post by Benjamin Kaduk

Post by Greg Hudson
On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should

[line 2519]

Post by Greg Hudson
--> SHOULD, since elsewhere we use SHOULD

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
Line 2668, SHOULD not --> SHOULD NOT

Agree.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
I guess for consistency I should say the same thing about line 3049.

I guess "may" here, but no strong opinion.

Post by Benjamin Kaduk
Line 3716, MUST not --> MUST NOT

Agree.

Thanks for double-checking my work.
-Ben

[Weijun Wang]

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

Thanks
Weijun

Post by Benjamin Kaduk

Post by Weijun Wang
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

Post by Weijun Wang
@@ -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.
@@ -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

Post by Benjamin Kaduk

Post by Greg Hudson
On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should

[line 2519]

Post by Greg Hudson
--> SHOULD, since elsewhere we use SHOULD

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
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.

Post by Greg Hudson

Post by Benjamin Kaduk
Line 2668, SHOULD not --> SHOULD NOT

Agree.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
I guess for consistency I should say the same thing about line 3049.

I guess "may" here, but no strong opinion.

Post by Benjamin Kaduk
Line 3716, MUST not --> MUST NOT

Agree.

Thanks for double-checking my work.
-Ben