jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-lamps-documentsigning-eku

Commentary: Addressing  's .
The term "Document Signing" in this document refers to digitally
signing contents that are consumed by people.  To be more precise,
contents are intended to be shown to a person with printable or
displayable form by means of services or software, rather than
processed by machines.
The term "Document Signing" in this document refers to digitally
signing contents that are consumed by people.  To be more precise,
contents are intended to be shown to a person with printable or
displayable form by means of services or software, rather than
primarily processed by machines.
This procedure is intended to permit or prohibit presence of a
certain KeyPurposeId or complete absence of KeyPurposeIds.  It is
outside the scope of this document, but the relying party can
permit or prohibit combinations of KeyPurposeIds, instead of
single KeyPurposeId.  A consideration on prohibiting combinations
of KeyPurposeIds is described in the Security Considerations
section of this document.  If both "Excluded KeyPurposeId" and
"Permitted KeyPurposeId" exists, the relying party or the relying
party software proresses each restriction on "Excluded
KeyPurposeId" first, and then processes each restriction on
"Permitted KeyPurposeId".
This procedure is intended to permit or prohibit presence of a
certain KeyPurposeId or complete absence of KeyPurposeIds.  It is
outside the scope of this document, but the relying party can
permit or prohibit combinations of KeyPurposeIds, instead of a
single KeyPurposeId.  A consideration on prohibiting combinations
of KeyPurposeIds is described in the Security Considerations
section of this document.  If both "Excluded KeyPurposeId" and
"Permitted KeyPurposeId" exists, the relying party or the relying
party software proresses each restriction on "Excluded
KeyPurposeId" first, and then processes each restriction on
"Permitted KeyPurposeId".
Draft: draft-ietf-lamps-documentsigning-eku

Commentary: I also checked : 
 It checked
IANA is requested to make one assignment for the TBD2 in the id-kp-
documentSigning object identifier (OID), as defined in Section 3.1,
in the "SMI Security for PKIX Extended Key Purpose" (1.3.6.1.5.5.7.3)
registry.  The other assignment for the TBD1 in Appendix A for the
id-mod-docsign-eku ASN.1 module X.680 object identifier (OID), as
defined in Appendix A, in the "SMI Security for PKIX Module
Identifier" (1.3.6.1.5.5.7.0) registry.
Draft: draft-ietf-lamps-documentsigning-eku

Commentary: Addresses GENART comment .
IANA is requested to make one assignment for the TBD2 in the id-kp-
documentSigning object identifier (OID), as defined in Section 3.1,
in the "SMI Security for PKIX Extended Key Purpose" (1.3.6.1.5.5.7.3)
registry.  The other assignment for the TBD1 in Appendix A for the
id-mod-docsign-eku ASN.1 module X.680 object identifier (OID), as
defined in Appendix A, in the "SMI Security for PKIX Module
Identifier" (1.3.6.1.5.5.7.0) registry.
Draft: draft-ietf-lamps-documentsigning-eku

Commentary: Some editorial fixes pointed during WGLC
Document Signing applications MAY require that the Extended Key Usage
extension be present and that a id-kp-documentSigning be indicated in
order for the certificate to be acceptable to that Document Signing
application.
Document Signing applications MAY require that the Extended Key Usage
extension be present and that the id-kp-documentSigning be indicated
in order for the certificate to be acceptable to that Document
Signing application.
As described in RFC5280, EKU extension may, at the option of the
certificate issuer, be either critical or non-critical.
If there are restrictions set for the replying party and relying
party software, then process the KeyPurposeId(s) as described
below.
If there are restrictions set for the relying party and relying
party software, then process the KeyPurposeId(s) as described
below.
"Permitted KeyPurposeId" is a KeyPurposeId which the relying
party or the relying party software accepts.  Examples of
"Permitted KeyPurposeId" are, presence of this general document
signing KeyPurposeId and/or protocol specific document signing-
type KeyPurposeIds.  If a KeyPurposeId of the certificate meets
the condition set by a "Permitted KeyPurposeId" restriction,
the certificate is acceptable.  Otherwise, relying party or the
relying party software rejects the certificate.
While a specific protocol or signing scheme may choose to come up
with their own KeyPurposeIds, some may not have significant motive or
resources to set up and manage their own KeyPurposeIds.  This general
document signing KeyPurposeId may be used as a stop-gap for those
that intend to define their own KeyPurposeId or those who do not
intend to set up an KeyPurposeId but still would like to distinguish
document signing from other usages.
While a specific protocol or signing scheme may choose to come up
with their own KeyPurposeIds, some may not have significant motive or
resources to set up and manage their own KeyPurposeIds.  This general
document signing KeyPurposeId may be used as a stop-gap for those
that intend to define their own KeyPurposeId or those who do not
intend to set up a KeyPurposeId but still would like to distinguish
document signing from other usages.
Draft: draft-ietf-lamps-documentsigning-eku

Commentary: there was two more remaining human . 
 on the section 4 , it seems better to change some of " EKU " to " KeyPurposeId " or " EKU values " to highlight following . excluded EKUs procedures checks , whether EKU values contain some OID(KeyPurpiseId ) , or absence of EKU extension . permitted EKU procedures check , whether EKU values contain some OID(KeyPurposeId ) . 
 Current expression on " Excluded EKUs procedure " and " Permitted EKU procedure " seems unclear about whether that procedure prohibits or allows , existence of certain key purpose identifier in the extended key usage value ( partial match ) , OR certain set of key purpose identifier is on key usage value(exact match ) . my intension was the former . I will review , and will fix that expression if it were unclear . In addition , I will add " restrictions set is derived and implemented from ( or configured with ) the policy to which the implementation conforms . " to clarify policy handling by RP or implementer .
Term of "Document Sign" in this document is digitally sign contents
that are consumed by humans.  To be more precise, contents are
intended to be shown to human with printable or displayable form by
means of services or software, rather than processed by machines.
Term of "Document Sign" in this document is digitally sign contents
that are consumed by people.  To be more precise, contents are
intended to be shown to person with printable or displayable form by
means of services or software, rather than processed by machines.
Draft: draft-ietf-lamps-documentsigning-eku

Commentary:  sent me these off list . 
 It look good to me .
The signed contents of Internet-Drafts are primarily intended to be
consumed by human.  To be more precise, contents are intended to be
shown to human in a printable or displayable form by means of
services or software, rather than processed by machines.  To validate
the digital signature which is signed to contents intended to be
consumed by human, implementations MAY perform the steps below as a
certificate validation.
The signed contents of Internet-Drafts are primarily intended to be
consumed by people.  To be more precise, contents are intended to be
shown to a person in a printable or displayable form by means of
services or software, rather than processed by machines.  To validate
the digital signature on the contents that is intended to be consumed
by people, implementations MAY perform the steps below as a
certificate validation.
Draft: draft-ietf-lamps-documentsigning-eku

Commentary: I reviewed and approved this pull request . 
 Upon further reflection it seems like RFC 7299 and 8358 are informative instead of normative references .
RFC5280 specifies several extended key purpose identifiers for X.509
certificates.  In addition, several extended key purpose identifiers
were addedRFC7299 as public OIDs under the IANA PKIX Extended key
purpose identifiers arc.  While usage of the any extended key usage
value is bad practice for publicly trusted certificates, there is no
public and general extended key purpose identifier explicitly
assigned for Document Signing certificates.  The current practice is
to use id-kp-emailProtection, id-kp-codeSigning or vendor defined
Object IDs for general document signing purposes.
RFC5280 specifies several extended key usages for X.509 certificates.
In addition, several extended key usage had been addedRFC7299 as
public OID under the IANA repository.  While usage of any extended
key usage is bad practice for publicly trusted certificates, there
are no public and general extended key usage explicitly assigned for
Document Signing certificates.  The current practice is to use id-kp-
emailProtection, id-kp-codeSigning or vendor defined Object ID for
general document signing purposes.