Dave,
> 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.
Yes, please do that.
> > - 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?
Limiting the value size to 255 bytes was the intention.
> 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.
An explicit limit is probably a good idea, as an implementation that
receives this key and doesn't recognize it may only log the first
255 bytes, so imposing that as a max limit may encourage more useful
behavior from implementations that aren't expecting the key.
> > - "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?
The "protocol logic" wording is not inherently a problem, but it is
important
that the on-the-wire "behavior" is unchanged, and "behavior" is an important
word.
> > - 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.
"levels of detail" seems to be less than perfectly clear. Talking
about being able to set "amount of information" provided to one of
several levels, and perhaps "verbosity" or "verbosity level" of
the key could be clearer.
> > - 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?
If it does, I think you're done. We weren't 100% sure in the meeting.
> > - 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
The big concern was use of company names. Example, Inc. is definitely
ok, and non-offensive parodies of the company names used are probably
fair game (Dave Noveck may already be thinking up some of the latter).
> > - 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.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.