I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-abfab-aaa-saml-12
Reviewer: Roni Even
Review Date:2015-12-3
IETF LC End Date: 2015-12-4
IESG Telechat date:
Summary: This draft is almost ready for publication as an Informational RFC.
Major issues:
Minor issues:
1. Why is the RADIUSNasIpAddress a string and not as specified in for
example in RFC2865
2. In general I was wondering why this is an Informational document.
It defines procedures and has normative language.
3. In the IANA consideration in section 11.1, as far as I understand
the IANA attribute type registry you need to ask for values for TBD1 and
TBD2 from the unassigned space (and not the reserved space)
4. In step 2 of figure 7 (section 7.2) the text says "In step 2, the
Relying Party may optionally issue a <samlp:AuthnRequest> message to be
delivered to the Identity Provider using the SAML-Protocol RADIUS
attribute." My reading is that the rest of the steps are when this message
is sent, since it is "may" what happens if the message is not sent?
Nits/editorial comments:
1. In section 1 please expand ABFAB
2. In section 7.2, the text says "To implement this scenario, a profile
of the SAML Authentication Request protocol is used in conjunction with
the SAML RADIUS binding defined in Section 4." I think that the language
should be more normative maybe it should say "To implement this scenario,
this profile of the SAML Authentication Request protocol MUST Be (or
SHOULD if there are other options) used in conjunction with the SAML RADIUS
binding defined in Section 4."