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

From: "Sandars, Ken" <[email-masked]>
Date: Wed, 2 Aug 2006 00:15:23 -0700

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

---

From: David Wysochanski <[email-masked]>
Date: Wed, 02 Aug 2006 11:03:24 -0400

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?

---

From: William Studenmund <[email-masked]>
Date: Wed, 2 Aug 2006 11:39:53 -0700

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

We talked about this in Montreal. Or I tried to a bit.

At this point, I think we have to accept "NotUnderstood" as a valid  
response to the key, indicating that the other side doesn't  
understand. We can't do anything different.

We thus should state that "NotUnderstood" is an invalid  
X#NodeArchitecture value (you MUST never attempt to assert that it's  
your architecture value), and its presence in a response should be  
taken to mean the responder doesn't understand the key.

Take care,

Bill

---

From: David Wysochanski <[email-masked]>
Date: Wed, 02 Aug 2006 15:55:59 -0400

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Ah, thanks for pointing out that last part.

I think RFC3720 already handles usage of "NotUnderstood" as a
value for any key.  I can add an explicit sentence forbidding
its use as you've stated, but I didn't get that was what was
desired from the final minutes.

Here's the section from 3720, p. 54 I'm referring to:

    The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
    reserved and MUST ONLY be used as described here.  Violation of this
    rule is a protocol error (in particular the use of "Reject",
    "Irrelevant", and "NotUnderstood" as proposed values).

Here's what the final minutes had:

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

Finally, some new proposed text with the explicit forbidding of
"NotUnderstood" (see the last sentence).

    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).  In addition, a node implementing
    transmission MUST NOT transmit "NotUnderstood" as its value,
    as this is a reserved value for all keys [RFC3720].