[saag] AD Review of draft-eastlake-rfc6931bis-xmlsec-uris-17

[Roman Danyliw <[e-mail]>]

Hi!

I performed an AD review on draft-eastlake-rfc6931bis-xmlsec-uris-17.  As this document is AD-sponsored, I would also appreciate additional reviewer either now or when the document enters IETF LC.  My feedback is below:

** I checked all of the new URIs listed in the document.  Generally, they returned a page saying that these identifiers are reserved and pointed back to this document.  The following URIs demonstrated different behavior.  Is this expected or a sign that further coordination with W3C is required?

-- Returns a 404:
http://www.w3.org/2021/04/xmldsg-more#siphash-2-4

-- Returns a generic page on namespaces (but I'll note that these URI are also already defined in [GENERIC], aka https://www.w3.org/TR/xmlsec-generic-hybrid/):

http://www.w3.org/2010/xmlsec-ghc#rsaes-kem
http://www.w3.org/2010/xmlsec-ghc#ecies-kem

** Editorial.  Why do only of some the algorithms have examples?  For example, in the original RFC6931 text, Section 2.1.3 (SHA-384) has one, but Section 2.1.4 (Whirlpool) does not.  Section 2.1.5 (SHA3) was originally in RFC6931 and in this bis got an example (for SHA3-224).  Of the newly added algorithms, Section 2.2.4 (Poly1305), 2.2.5 (SipHash-2-4), 2.2.6 (XMSS), 2.6.7 (ChaCha20) didn't get examples (not an exhaustive list), but Section 2.3.12 (Edwards-Curve) and Section 2.6.8 (ChaCha20+Poly1305) did.

** Abstract.  Editorial.

OLD
   This document updates and corrects the IANA registry for the list of
   URIs intended for use with XML digital signatures, encryption,
   canonicalization, and key management.  These URIs identify algorithms
   and types of information.  

NEW
This document updates and corrects the IANA "XML Security URIs" registry that lists the URIs intended for use with XML digital signatures, encryption, canonicalization, and key management.  These URIs identify algorithms and their associated type information.  

** Section 1.  Typo. s/has has/has/

** Section 1.  Typo. s/elemets/elements/

** Section 2.  This section discusses the namespace change from #xmldsig to #xmldsig-more.  It seems like an introduction of #xmlsec-ghc should also be added here.

** Section 2.2.3. Editorial.  s/is here used/is used here/

** Section 2.2.4.  Typo in the identifier URI:

OLD
http://www.w3.org/2021/04/xml6dsig-more#poly1305
NEW
http://www.w3.org/2021/04/xmldsig-more#poly1305

** Section 2.2.6.  Is there a reason there isn't more narrative text point out the different variants of XMSS the same way that Section 2.1.5 or 2.2.2 ?

** Section 2.6.4.  This is comment on the original text from RFC6931 copied into this document. Why doesn't the full namespace from the "identifiers" list match the example for #psec-kem?  The latter says "xmldsig-more#psec-kem" but the example says "xmlenc#psec-kem".  

** Section 2.6.7.  Typo. s/repreented/represented/

** Section 2.6.7.  Typo. /nexted/nested/

** Section 2.7.2.  Typo. s/specificed/specified/

** Section 2.7.2.  Typo.  In the example:
OLD
/AgreementMethod>

NEW
</AgreementMethod>

** Section 4.2.  Typo in the fragment name of the table (used to update the IANA registry)

OLD
2021/04/xmldsig-more#po1305              

NEW
2021/04/xmldsig-more#po1y305              

** Section 5.1
   The W3C has assigned "http://www.w3.org/2021/04/xmldsig-more#" for
   additional new URIs specified in this document.

"xmlsec-ghc#" is also used.  Perhaps we should ls

** Section 5.2.  Why loosen the registration procedure from specification required to expert review?  The documentation requirement seems nearly equivalent to "specification required".  Given how little churn this gets (especially in new Types), what would be the circumstances where the rigor of a W3C or IETF wouldn't be appropriate?

Regards,
Roman