Re: DRAFT Montreal minutes - X#NodeArchitecture comments

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 13, 2006, at 10:44 AM, David Wysochanski wrote:

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

It could also be that we just kinda forgot the exact wordings. Now  
that I look at it, it seems ok. So perhaps just mentioning  
Operational Negotiation Only somewhere in the text is ok.

>>         - 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?

Yes, 255. The long keys are rarely used, so we wanted to keep this a  
short one.

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

Well, we can get a lot in 255 bytes. :-)

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

I think that you'll get back a "NotUnderstood" response, but we  
should check into this. :-)

>>         - 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?

I think the initial thought was something more along the lines of  
making sure there is a 12.whatever (less than 22) style block. And I  
think there is.

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

No. I think spaces could be quite useful. My idea is to suggest that  
we make this key use "iSCSI-name-value" format. That would let us  
have a 255 byte UTF-8 string, which can encode a lot of stuff.

I think it's ok for commas to be in there. The difference between  
having commas in an "iSCSI-name-value" and a "list-of-values" is that  
the latter is a list of things that make sense to iSCSI negotiation.  
Like Auth methods or CHAP hashes. But this key isn't supposed to be  
processed by login negotiation (it's passed around as an opaque  
string), so just happening to have commas in it is fine. They merely  
only have meaning for humans looking at the logs.

Take care,

Bill
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEtqMlDJT2Egh26K0RAlsiAJoCI92ub7cwPfV2uycCrnGZnWK5KACfYaau
0jQ/KXw1Iz251NLeqqzOFwo=
=LO0p
-----END PGP SIGNATURE-----

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