Re: DRAFT Montreal minutes - X#NodeArchitecture comments

William Studenmund wrote:
> -----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.
> 

Ok, may have to revisit this one.

I think all the other comments are
the same as David's and/or have been
addressed.

Thanks for the feedback.


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