11 Jul 2012 21:48
14 Jul 2012 05:08
Re: draft-ietf-abfab-gss-eap-naming believed ready for last call
Jim Schaad <ietf <at> augustcellars.com>
2012-07-14 03:08:59 GMT
2012-07-14 03:08:59 GMT
Major NONE - I agree the document is ready for last call and progression Minor 1. Just because I keep having to go and read the SAML document every time, it might be useful to provide an example in paragraph 1 of section 3 about what makes a first part and a second part. I would pass the document without this, it is just a suggestion. 2. In section 3 paragraph 2 - Suggest changing the first occurrence of URI to URN so that sentence 2 and 3 use the same name for this value (URN vs URI). 3. In section 5, I thought we had agreed that there should be a statement that "The values, prior to receiving the access-accept message, are undefined." 4. Section 6.1 - I think this is correct. s/is always authentic when present/is always authenticated when present/ If I am wrong (which is possible) then I am not sure what the word authentic is supposed to be. I don't think it currently makes sense. The argument against the above is the following on sentence which states that a new GSS-API mechanism may allow it to be unauthenticated. 5. Section 6.1 - unclear if this is useful information or not. Might want to say that for GSS-API-EAP, it is the same as "urn:ietf:gss:radius-attribute TBD".(Continue reading)
14 Aug 2012 17:47
Re: draft-ietf-abfab-gss-eap-naming believed ready for last call
Sam Hartman <hartmans <at> painless-security.com>
2012-08-14 15:47:14 GMT
2012-08-14 15:47:14 GMT
>>>>> "Jim" == Jim Schaad <ietf <at> augustcellars.com> writes:
Jim> 1. Just because I keep having to go and read the SAML document
Jim> every time, it might be useful to provide an example in
Jim> paragraph 1 of section 3 about what makes a first part and a
Jim> second part. I would pass the document without this, it is
Jim> just a suggestion.
I'd love to include an example here.
I'll try to update code prior to IETF LC ending.
Jim> 3. In section 5, I thought we had agreed that there should be
Jim> a statement that "The values, prior to receiving the
Jim> access-accept message, are undefined."
I thought the first paragraph was adequate, but expanded it somewhat.
Let me know how we're doing now.
Jim> 4. Section 6.1 - I think this is correct. s/is always
Jim> authentic when present/is always authenticated when present/ If
Jim> I am wrong (which is possible) then I am not sure what the word
Jim> authentic is supposed to be. I don't think it currently makes
Jim> sense. The argument against the above is the following on
Jim> sentence which states that a new GSS-API mechanism may allow it
Jim> to be unauthenticated.
Added hopeful clarity to this paragraph.
Jim> 5. Section 6.1 - unclear if this is useful information or not.
Jim> Might want to say that for GSS-API-EAP, it is the same as
(Continue reading)
22 Aug 2012 13:23
Re: draft-ietf-abfab-gss-eap-naming believed ready for last call
Jim Schaad <ietf <at> augustcellars.com>
2012-08-22 11:23:51 GMT
2012-08-22 11:23:51 GMT
> -----Original Message----- > From: Sam Hartman [mailto:hartmans <at> painless-security.com] > Sent: Wednesday, August 15, 2012 1:17 AM > To: Jim Schaad > Cc: abfab <at> ietf.org > Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last > call > > >>>>> "Jim" == Jim Schaad <ietf <at> augustcellars.com> writes: > > Jim> 1. Just because I keep having to go and read the SAML document > Jim> every time, it might be useful to provide an example in > Jim> paragraph 1 of section 3 about what makes a first part and a > Jim> second part. I would pass the document without this, it is > Jim> just a suggestion. > > I'd love to include an example here. > I'll try to update code prior to IETF LC ending. Hope to see it. > > > Jim> 3. In section 5, I thought we had agreed that there should be > Jim> a statement that "The values, prior to receiving the > Jim> access-accept message, are undefined." > > I thought the first paragraph was adequate, but expanded it somewhat.(Continue reading)
RSS Feed