Re: DRAFT Montreal minutes - X#NodeArchitecture comments

A couple comments a points for clarification, while this is fresh on
everyone's minds below.

> iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 
> min
>         (draft-ietf-ips-iscsi-nodearch-key.txt)
>
>         WG Discussion:
>         - Key should be allowed only after Authentication.  Revise draft
>                 to impose this restriction
>
This is actually already in there if you read the fine print of the 
"Use" portion of
the declaration and note that "Any-Stage" is not there (see Section 12 
in 3720).
Since it has come up repeatedly though from various people, I will add some
text to point this out explicitly and refer to Sections 11 and 12 of 3720.


>         - Make sure it's a regular-size text key (not a big one, like the
>                 one used for the large numbers involved in some
> authentication
>                 methods).
>
Was the comment to limit the value size to 255 bytes, i.e. a single
"text-value" (or "simple-value"), as defined by 3720, or something
else?

I liked the comma separated values and list-of-values seemed to
fit well.  But if there are concerns about key length I suppose we
can add an explicit max length of the list-of-values.  Another reviewer
raised the question about the maximum length early on so perhaps
an explicit limit is the way to go here.

>         - "protocol logic": crucial point is that **behavior** is the 
> same
>                 independent of presence, absence, or content of the key.
> Add
>                 or revise text to make this point.
>
Was the consensus that the original term, "functional behavior",
was clear enough, and I just muddied the water by trying to
make it more crisp?

>         - Document behavior of RFC 3720-compliant implementation that
>                 receives this new key and does not understand it, and how
>                 the other side deals with the resulting response.
>
Ok.

>         - "configure different levels" text needs to be rephrased to be
>                 specific that the amount of detail is what changes across
> levels.
>
I'm not sure about this comment because I thought the existing text
does just that.  Here's what the text says today:

    all
    implementations of this extension key SHOULD provide an 
    administrative mechanism to configure different levels of
    detail in the extension key values and MUST provide an
    administrative mechanism to disable sending the key.



>         - Align ability to configure amount of details with "SHOULD NOT"
>                 in Section 1.2 about administrative setting of key value.
>                 (the prior "SHOULD NOT" appears to conflict with this
> "SHOULD").
>
Point taken - will work on it.

>         - Double-check there is a 3720-format definition of the key,
>                 including description clearly in the draft. 
>
Was the comment that the existing declaration in section 2
conforms to section 12 of 3720, and specifically, section
12.22?

>         - Make the examples phony (no real company names), and remove
>                 the double quotes ("), as they don't appear on the wire.
>
Ok.  Main intent in providing company names was to show valid
examples for implementers but I will remove them.  Note that
RFC 2616 does have valid examples

   Examples:

       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
       Server: Apache/0.8.4


>         - Spaces are forbidden in text strings.  See RFC 3720, Section 
> 5.1,
>                 and feel free to ask on the list for options on how to 
> deal
>                 with this.
>
Good catch - looks like I got carried away in my intent to provide
clear examples.


_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips