RE: DRAFT Montreal minutes - X#NodeArchitecture comments

Hi David,

Making an extension key 'Declarative' seems problematic.

Implementations which do not recognise the key will reply with
X<blah>=NotUnderstood. This may upset the proposer since "NotUnderstood"
is unlikely to be an acceptable use of the new key.

"NotUnderstood" could be treated as a special case, but do we really
want a special case?

Thoughts?
Ken



-----Original Message-----
From: David Wysochanski [mailto:[email protected]] 
Sent: Friday, 14 July 2006 08:34
To: [email protected]
Cc: [email protected]
Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments

I think the attached addresses all of the comments below (or is pretty
close).  I know the format is wrong in some cases (pages too long, etc)
but I'll fix that later.  Diffing should be simpler.

Some remaining points still for discussion:
1) Still not sure about proper use / behavioral text
2) Now explicitly states the key may be sent in either normal or
discovery sessions.

Specific comments / explanations below.


[email protected] wrote:
> 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.
> 

This has been fixed with a small change to the first sentence of
paragraph 3, section 1.2 and added a second paragraph in section 2.


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

Addressed in Section 2.


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

I put back the "functional behavior" term and made my added "protocol
logic" sentence parenthetical.
Please let me know if this hits the mark.


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

Adddressed with last paragraph added in 1.2.
The paragraph starts with a short discussion about possible valid
implementations, which complements part of the latter security section.


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

I think this is clearer now.  Please see paragraph 2, section 3.


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

Also, I think addressed with slight modification to 3rd paragraph of
section 1.2


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

I double checked this and I think for the most part it is there.
However, upon examination and more thinking, I do not see or remember a
reason to preclude use in discovery sessions (again, logging may be
useful), and 3270 does not seem to forbid declarative keys in discovery
sessions (are declarative keys "requests"?).  Thus, I've clarified some
text to make this clear.  Please let me know if there are objections to
this.  If so, I will add "Irrelevant when: SessionType=Discovery" to the
key declaration and remove the references to discovery sessions.


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

Done.


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

Replaced all spaces with underscores.



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