headers
David Wysochanski | 1 Aug 2006 18:41
Picon

Re: DRAFT Montreal minutes - X#NodeArchitecture comments

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Jul 31, 2006, at 2:36 PM, David Wysochanski wrote:
> 
>  > Ping on the 2 items below - any comments?
>  >
>  > Also adding a 3rd item:
>  > 3) Change key value format from list-of-values to
>  > "iSCSI-name-value" (see 7/13/06 post).
>  >
>  > For this one, I'd rather leave it as list-of-values, since
>  > this is simple, underscores are just about as readable as
>  > spaces, and iSCSI-name-value seems a little strange
>  > to me in this context.
> 
> Actually, how about "iSCSI-local-name-value".
> 
> The thing I don't like about list-of-values is that it implies, to me 
> at least, list negotiations. Which we don't want here. :-) Also, list-
> of-values just vies us "text-value" plus comma. Among other things, 
> we don't have spaces, nor do we have CR.
> 

Don't you think this would look a little strange though:

X#NodeArchitecture

    Use: LO, Declarative
(Continue reading)

Permalink | Reply | 2 comments |
headers
William Studenmund | 1 Aug 2006 19:07

Re: DRAFT Montreal minutes - X#NodeArchitecture comments


\On Aug 1, 2006, at 9:41 AM, David Wysochanski wrote:

> William Studenmund wrote:
>> Actually, how about "iSCSI-local-name-value".
>> The thing I don't like about list-of-values is that it implies, to  
>> me at least, list negotiations. Which we don't want here. :-)  
>> Also, list-
>> of-values just vies us "text-value" plus comma. Among other  
>> things, we don't have spaces, nor do we have CR.
>
>
> Don't you think this would look a little strange though:
>
> X#NodeArchitecture
>
>    Use: LO, Declarative
>    Senders: Initiator and Target
>    Scope: SW
>
>    X#NodeArchitecture=<iSCSI-local-name-value>
>
>
>
> The reason I think it looks strange is that what is being defined
> is not an iSCSI name.  The "list-of-values" sounds more generic,
> especially if you compare the definitions in 3720.
> Granted, "list-of-values" and "iSCSI-local-name-value" are just
> tags to describe string rules, but it looks odd.
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Wysochanski | 1 Aug 2006 20:40
Picon

Re: DRAFT Montreal minutes - X#NodeArchitecture comments

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> \On Aug 1, 2006, at 9:41 AM, David Wysochanski wrote:
> 
>  > William Studenmund wrote:
>  >> Actually, how about "iSCSI-local-name-value".
>  >> The thing I don't like about list-of-values is that it implies, to 
>  >> me at least, list negotiations. Which we don't want here. :-) 
>  >> Also, list-
>  >> of-values just vies us "text-value" plus comma. Among other 
>  >> things, we don't have spaces, nor do we have CR.
>  >
>  >
>  > Don't you think this would look a little strange though:
>  >
>  > X#NodeArchitecture
>  >
>  >    Use: LO, Declarative
>  >    Senders: Initiator and Target
>  >    Scope: SW
>  >
>  >    X#NodeArchitecture=<iSCSI-local-name-value>
>  >
>  >
>  >
>  > The reason I think it looks strange is that what is being defined
>  > is not an iSCSI name.  The "list-of-values" sounds more generic,
>  > especially if you compare the definitions in 3720.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sandars, Ken | 2 Aug 2006 09:15
Favicon

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:davidw <at> netapp.com] 
Sent: Friday, 14 July 2006 08:34
To: Black_David <at> emc.com
Cc: ips <at> ietf.org
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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Wysochanski | 2 Aug 2006 17:03
Picon

Re: DRAFT Montreal minutes - X#NodeArchitecture comments

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
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
William Studenmund | 2 Aug 2006 20:39

Re: DRAFT Montreal minutes - X#NodeArchitecture comments


On Aug 2, 2006, at 12:15 AM, 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?

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Wysochanski | 2 Aug 2006 21:55
Picon

Re: DRAFT Montreal minutes - X#NodeArchitecture comments

William Studenmund wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Aug 2, 2006, at 12:15 AM, 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?
> 
> 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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sandars, Ken | 3 Aug 2006 09:23
Favicon

RE: DRAFT Montreal minutes - X#NodeArchitecture comments

Hi David,

It might be clearer to rephrase the paragraph to cover the node's
obligations when declaring the key, and when receiving it. Something
like:

    Nodes implementing this key MAY declare the key. Nodes implementing
    this key MAY discard the key values received from other nodes.

    Each node which declares the key 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 which
    implements this key MUST NOT declare "NotUnderstood" as its
    value.

    A node which receives the value "NotUnderstood" for this key SHOULD
    discard the value. Regardless of whether the received value is
    discarded, the key MUST be considered to have been declared. 

Thoughts?
Ken

-----Original Message-----
From: David Wysochanski [mailto:davidw <at> netapp.com] 
Sent: Thursday, 3 August 2006 05:56
To: William Studenmund
Cc: Sandars, Ken; ips <at> ietf.org
Subject: Re: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Wysochanski | 3 Aug 2006 20:51
Picon

Re: DRAFT Montreal minutes - X#NodeArchitecture comments

Sandars, Ken wrote:
> Hi David,
> 
> It might be clearer to rephrase the paragraph to cover the node's
> obligations when declaring the key, and when receiving it. Something
> like:
> 
We can certainly clarify the wording.

>     Nodes implementing this key MAY declare the key. Nodes implementing
>     this key MAY discard the key values received from other nodes.
> 
I'm not sure this is clearer than what I had below but maybe someone
else has can chime in.  The "declare" wording may be more consistent
with 3720 though.

>     Each node which declares the key 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 which
>     implements this key MUST NOT declare "NotUnderstood" as its
>     value.
> 
Seems fine.

>     A node which receives the value "NotUnderstood" for this key SHOULD
>     discard the value. Regardless of whether the received value is
>     discarded, the key MUST be considered to have been declared.
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Koning | 3 Aug 2006 21:04

Re: DRAFT Montreal minutes - X#NodeArchitecture comments

>>>>> "David" == David Wysochanski <davidw <at> netapp.com> writes:

 >> Each node which declares the key 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 which
 >> implements this key MUST NOT declare "NotUnderstood" as its value.
 >> 
 David> Seems fine.

Those are just the standard 3720 rules, right?  It seems confusing to
restate them explicitly, because it creates the impression that this
key uses rules that are different in some way from the usual rules.
If you do want to state the rules explicitly here, you might include
a comment to the effect that "The normal rules for key handling apply,
which are ..."

 >> A node which receives the value "NotUnderstood" for this key
 >> SHOULD discard the value. Regardless of whether the received value
 >> is discarded, the key MUST be considered to have been declared.
 >> 

 David> Isn't this last sentence in conflict with the RFC paragraph I
 David> mention below?  Sending "NotUnderstood" in a key value is a
 David> protocol error, so why would a node receiving it be forced to
 David> consider the other node having declared it?

I agree.  The spec says it's a protocol error, the rules for handling
protocol errors are defined already -- don't mess with it.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane