Subject: [apps-discuss] APPS area review of: draft-ietf-abfab-gss-eap-06

From: William Mills <[email-masked]>
Date: Tue, 22 May 2012 16:31:08 -0700 (PDT)

Major:

Section 5.8: still lists "Open issue: handling of lifetime parameters."

Minor:

Section 3.4: "RFC editor, remove the remainder of this subjection prior to publication.", do you mean "subsection" here? 

Section 5:  The format of "length" should be more clearly defined her.  A more detailed definition appears to live as the last three sentences in 5.6.3, which seems odd.

Nits:

Section 5.5.1 & 5.5.2: Is the phrase "It is always critical." something with specific meaning?  Otherwise simply stating that these tokens are REQUIRED, is probably sufficient.

Section 6: 3rd paragraph, "procedur" needs an "e" on the end.

Section 7.1:  "[this spec" wants a closing square bracket.

Section 7.3:  The choice of registered values seems odd;  non-sequential, and slightly inconsistent (request vs. response not in consistent numerical order).  Doesn't matter since it's constants.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 May 2012 05:09:09 -0400

Thanks so much for your review.

>>>>> "William" == William Mills <[email-masked]> writes:

    William> Major:

    William> Section 5.8: still lists "Open issue: handling of lifetime
    William> parameters."

Simon pointed this out in WGLC; the text has been removed. No one wants
to deal with this and we agree that if we did it would be a MAY/SHOULd
implement.

    William> Minor:

    William> Section 3.4: "RFC editor, remove the remainder of this
    William> subjection prior to publication.", do you mean "subsection"
    William> here?

I do; fixed.

    William> Section 5: The format of "length" should be more clearly
    William> defined her.  A more detailed definition appears to live as
    William> the last three sentences in 5.6.3, which seems odd.

Description fixed; thanks.

    William> Nits:

    William> Section 5.5.1 & 5.5.2: Is the phrase "It is always
    William> critical." something with specific meaning?  Otherwise
    William> simply stating that these tokens are REQUIRED, is probably
    William> sufficient.
Please see the section titled Processing Received tokens.

The second paragraph defines required tokens (inner token is invalid in
a given state unless subtoken is included).
The third paragraph in that section defines critical subtokens (receiver
must fail if receiver does not understand the token).

So, required and critical are different.

    William> Section 7.3: The choice of registered values seems odd;
    William> non-sequential, and slightly inconsistent (request
    William> vs. response not in consistent numerical order).  Doesn't
    William> matter since it's constants.

Agreed.  I don't want to break interoperability with existing
implementations to fix it though. Changing this definitely would create
interop issues.