Re: [Gen-art] Gen-ART review of draft-ietf-kitten-extended-mech-inquiry-06.txt

[Suresh Krishnan <[e-mail]>]

Hi Nico,
   Thanks for the quick response. Your responses address all my concerns.

Thanks
Suresh

On 26/05/09 07:09 PM, Nicolas Williams wrote:
> On Tue, May 26, 2009 at 06:12:12PM -0400, Suresh Krishnan wrote:
>> I am the assigned Gen-ART reviewer for
>> draft-ietf-kitten-extended-mech-inquiry-06.txt
> 
> Thanks.
> 
>> Summary: This draft is almost ready for publication as Proposed Standard.
>>
>> Substantial
>> ===========
>>
>> * Section 3.4.4
>>
>> Shouldn't the output "name" be released with GSS_Release_buffer() as well?
> 
> No, because it's bound to be a constant.
> 
> Background: originally the GSS-API required all gss_OID values to be
> released, but in practice it turned out that those were always
> effectively constant, thus gss_release_oid() was unnecessary (except
> when applied to the output of the obsoleted gss_str_to_oid()).
> 
> In this case we're talking about a name that's going to be effectively
> constant too.
> 
>> Minor
>> =====
>>
>> * The IANA considerations section describes the policy for future 
>> allocations as "IESG Protocol Action". Is it possible to use a known 
>> policy (Standards Action or IESG Approval, perhaps) for this?
> 
> Oh, that's a mistake.  I need to dig out what the consensus had been in
> the WG.  We'll definitely correct that during the publication process.
> 
>> * Section 3.4.3
>>
>> GSS_Inquire_mech_attrs_for_mech() needs to be replaced by 
>> GSS_Inquire_attrs_for_mech() as the former does not exist.
> 
> Indeed, that's an editing error on my part.  Good catch.
> 
>> Editorial
>> ==========
>> * Section 3.4.6:
>>
>> Replace
>> "To avoid this error we hereby define new typdefs which
>>                                           ^^^^^^^
>> with
>> "To avoid this error we hereby define new typedefs which
> 
> *nod*
> 
>> * IANA Considerations
>>
>> s/namsepace/namespace/
> 
> *nod*
> 
> Thanks!
> 
> Nico