Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments

[David Wysochanski <[e-mail]>]

It is an excellent point which I think also was brought up in Montreal
(see Final minutes by David Black).  However, I believe I have addressed
this concern with the following text in the latest version I posted to
the list on 07/13/2006 06:34 PM (see draft-ietf-ips-iscsi-nodearch-key-01r2.txt):

    Nodes implementing this key may choose to only transmit the
    key, only log the key values received from other nodes, or both
    transmit and log the key values.  Each node choosing to implement
    transmission of the key values MUST be prepared to handle the
    response of [RFC3720] compliant nodes that do not understand the
    key ([RFC3720] states that compliant nodes MUST respond with
    X#NodeArchitecture=NotUnderstood).

Does this paragraph address your concern?


Sandars, Ken wrote:
> 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:[e-mail]]
> Sent: Friday, 14 July 2006 08:34
> To: [e-mail]
> Cc: [e-mail]
> 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.
> 
> 
> [e-mail] 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ips