Gen-ART LC review of draft-ietf-abfab-aaa-saml-12

["Roni Even" <ron.even.tlv@xxxxxxxxx>]

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.”