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

From: "Sandars, Ken" <[email-masked]>
Date: Mon, 7 Aug 2006 14:05:19 -0700

Hi Paul,

In [RFC3720] it is ALWAYS an error when the value of a declared key is
"NotUnderstood". Hence this document needs to state the (slightly)
altered processing of this key.

Cheers
Ken

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]] 
> Sent: Monday, 7 August 2006 23:51
> To: Sandars, Ken
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Ips] DRAFT Montreal minutes - 
> X#NodeArchitecture comments
> 
> >>>>> "Ken" == Ken Sandars <Sandars> writes:
> 
>  Ken> Hi David, Yes, you've got the angle I'm coming from. 
> It's  Ken> important to express the idea that while it is a 
> declared key,  Ken> the rules for declared keys are being 
> slightly bent such that it  Ken> is not a protocol error to 
> receive a "NotUnderstood" in the  Ken> context of the other 
> node processing it as an offered key.
> 
> So why is that new?  It should be the common rule for all 
> declared keys.
> 
> 	paul
> 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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

---

From: Paul Koning <[email-masked]>
Date: Mon, 7 Aug 2006 17:24:46 -0400

>>>>> "Ken" == Ken Sandars <Sandars> writes:

 Ken> Hi Paul, In [RFC3720] it is ALWAYS an error when the value of a
 Ken> declared key is "NotUnderstood". Hence this document needs to
 Ken> state the (slightly) altered processing of this key.

Actually, what we have here is a 3720 bug.  If a new key is
declarative, an old implementation does not know that and will (or
may?) treat it as a negotiated key, and reply with NotUnderstood.

That case is not specific to X#NodeArchitecture.  So it shouldn't be
treated as a special case there; instead it should be noted as a
bugfix to 3720.

The fix is easy: a "NotUnderstood" value for a declarative key is
ignored.  

	  paul

---

From: Julian Satran <[email-masked]>
Date: Tue, 8 Aug 2006 12:46:02 +0300

Paul is right. Julo

Paul Koning <[email-masked]> 
08/08/06 00:24

To
[email-masked]
cc
[email-masked], [email-masked]
Subject
RE: [Ips] DRAFT Montreal minutes - X#NodeArchitecture comments

                   paul

---

From: David Wysochanski <[email-masked]>
Date: Thu, 10 Aug 2006 10:09:21 -0400

Should this one go into the implemeters guide then?

(I know I still owe the list an update addressing Ken's
other point about an implementation that does not log and
does not transmit the key.)

Julian Satran wrote:
> 
> Paul is right. Julo
> 
> 
> *Paul Koning <[email-masked]>*
> 
> 08/08/06 00:24
> 
> 	
> To
> 	[email-masked]
> cc
> ------------------------------------------------------------------------
>

---

From: William Studenmund <[email-masked]>
Date: Thu, 10 Aug 2006 11:09:58 -0700

> Should this one go into the implemeters guide then?

I think so. And we can add a reference from this draft to it, so only  
the implementer's guide contains the "what to do" text.

Take care,

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 16 Aug 2006 22:50:51 -0700 (PDT)

Hi Ken,

Can you please point me to RFC 3720 text that says
NotUnderstood is always an error? 

The closest I can find is in section 5.2, page 55:

"All keys in this document, except for the X extension
formats, MUST be supported by iSCSI initiators and
targets when used as specified here. If used as
specified, these keys MUST NOT be answered with
NotUnderstood."

AFAICT, this is in fact suggesting the opposite..

Thanks. 

Mallikarjun

> The fix is easy: a "NotUnderstood" value for a

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Paul Koning <[email-masked]>
Date: Thu, 17 Aug 2006 09:43:04 -0400

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 Mallikarjun> Hi Ken, Can you please point me to RFC 3720 text that
 Mallikarjun> says NotUnderstood is always an error?

 Mallikarjun> The closest I can find is in section 5.2, page 55:

Page 54, second paragraph:

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

"as described here" is as responses to negotiating keys.  The text
already explicitly disallows their use as proposals.  

A declaration isn't exactly the same as a proposal, but it certainly
isn't a reply to a proposal, so by the above text "NotUnderstood" is
prohibited. 

The 3720 bug is this: an implementation that doesn't understand a key
doesn't know whether that key is declarative or negotiated.  If it
assumes the latter it would have to reply NotUnderstood.  If in fact
it was a declarative key then by the current text that's a protocol
violation. 

A good way to fix this is to add two rules:

1. If a key is not understood, it is assumed to be a negotiation
   key (and a NotUnderstood reply must be sent).
2. If a declarative key is sent, and a reply is received from the
   other end with that key and a value of NotUnderstood, this is
   a protocol violation only if the key is required to be implemented.
   If it was not required (i.e., X# keys) then a NotUnderstood
   reply must be silently ignored.

	 paul

---

From: William Studenmund <[email-masked]>
Date: Thu, 17 Aug 2006 11:50:02 -0700

>    reply must be silently ignored.

I like the proposed fix. The two comments I have are:

1) While X# keys are not required to be understood, any future  
"normal" keys we define will also fall into this category for  
existing devices.

2) I note that a device may chose to pretend it doesn't understand a  
key that isn't mandatory, even though it really does. For  
X#NodeArchitecture, a device may answer with differing levels of  
detail. The lowest level may well be to pretend that the key's not  
understood. In such a case, the device MUST fully pretend it doesn't  
understand, and as per rule (1) above, it MUST not offer the key and  
MUST respond with "NotUnderstood."

Note: this is a different behavior from understanding  
X#NodeArchitecture and choosing not to declare a value to the other  
side.

Take care,

Bill

---

From: Paul Koning <[email-masked]>
Date: Thu, 17 Aug 2006 14:54:47 -0400

>>>>> "William" == William Studenmund <[email-masked]> writes:

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

 William> On Aug 17, 2006, at 6:43 AM, Paul Koning wrote:

 >> key (and a NotUnderstood reply must be sent).  2. If a declarative
 >> key is sent, and a reply is received from the other end with that
 >> key and a value of NotUnderstood, this is a protocol violation
 >> only if the key is required to be implemented.  If it was not
 >> required (i.e., X# keys) then a NotUnderstood reply must be
 >> silently ignored.

 William> I like the proposed fix. The two comments I have are:

 William> 1) While X# keys are not required to be understood, any
 William> future "normal" keys we define will also fall into this
 William> category for existing devices.

True.  So replace "i.e." by "e.g.".

 William> 2) I note that a device may chose to pretend it doesn't
 William> understand a key that isn't mandatory, even though it really
 William> does. For X#NodeArchitecture, a device may answer with
 William> differing levels of detail. The lowest level may well be to
 William> pretend that the key's not understood. In such a case, the
 William> device MUST fully pretend it doesn't understand, and as per
 William> rule (1) above, it MUST not offer the key and MUST respond
 William> with "NotUnderstood."

 William> Note: this is a different behavior from understanding
 William> X#NodeArchitecture and choosing not to declare a value to
 William> the other side.

I'm not sure whether that is a distinction without a difference.  Does
it matter whether you can do that?  Do we need any extra text to make
it legal to do that?  I don't think so; if a key is optional then not
implementing it is allowed.  "Not implementing" may be a runtime
choice, not just a design-time choice.

If we do need that text for X#NodeArchitecture, it belongs in the
spec for that key, it isn't part of the 3720 fix.

     paul

---

From: William Studenmund <[email-masked]>
Date: Thu, 17 Aug 2006 12:09:32 -0700

> spec for that key, it isn't part of the 3720 fix.

I'm sorry. I don't think we need to change the text for item (2). I  
just wanted to make sure that we'd thought about it. And I also  
wanted to put a discussion of it into the mail archives. :-)

I agree that "Not implementing" can be a run-time choice.

Take care,

Bill

---

From: "Sandars, Ken" <[email-masked]>
Date: Thu, 17 Aug 2006 14:55:04 -0700

Hi Paul,

Well put. Couldn't have done it better with a room full of wordsmiths. 

Thanks,
Ken :-)

> Sent: Thursday, 17 August 2006 23:43
> To: [email-masked]
> Cc: Sandars, Ken; [email-masked]; [email-masked]
>  Mallikarjun> Hi Ken, Can you please point me to RFC 3720 
> text that  Mallikarjun> says NotUnderstood is always an error?
> 
> "as described here" is as responses to negotiating keys.  The 
> text already explicitly disallows their use as proposals.  
> 
> A declaration isn't exactly the same as a proposal, but it 
> certainly isn't a reply to a proposal, so by the above text 
> "NotUnderstood" is prohibited. 
> 
> The 3720 bug is this: an implementation that doesn't 
> understand a key doesn't know whether that key is declarative 
> or negotiated.  If it assumes the latter it would have to 
> reply NotUnderstood.  If in fact it was a declarative key 
> then by the current text that's a protocol violation. 
>

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 17 Aug 2006 15:54:53 -0700 (PDT)

Hi Paul,

I am still not sure I see the "bug" in 3720.  The text
you cite is immediately preceded by this sentence in
3720:

"However, the answer for a key
not understood MUST be key=NotUnderstood."

This applies to *all* keys, negotiated or declarative.
 The "as described here" text you cite is reinforcing
this universal applicability.

And the verbiage two paras below: "All keys in this
document, except for the X extension formats,.....MUST
NOT be answered with
NotUnderstood" offers even more guidance for this
specific thread.

So I guess I do not see a problem.  I am really trying
not to add "clarifications" to RFC 3720, when 3720 is
unambiguous (which I think it is in this case).

Regarding your proposed #2, I am not sure a proposer
should ever "silently ignore" a a "NotUnderstood"
response.   A NotUnderstood response always has a
semantic requirement on the proposer: not to use
protocol behavior associated with the key within the
scope of the key (connection/session).

Regards.

Mallikarjun

--- Paul Koning <[email-masked]> wrote:

> understand a key

---

From: Paul Koning <[email-masked]>
Date: Thu, 17 Aug 2006 21:00:09 -0400

>>>>> "Mallikarjun" == Mallikarjun C <[email-masked]> writes:

 Mallikarjun> Hi Paul, I am still not sure I see the "bug" in 3720.
 Mallikarjun> The text you cite is immediately preceded by this
 Mallikarjun> sentence in 3720:

 Mallikarjun> "However, the answer for a key not understood MUST be
 Mallikarjun> key=NotUnderstood."

 Mallikarjun> This applies to *all* keys, negotiated or declarative.
 Mallikarjun> The "as described here" text you cite is reinforcing
 Mallikarjun> this universal applicability.

Consider the top of page 53.

For declarative keys, there IS no response.  An occurrence of a
declarative key is always taken to be a declaration.  And declarations
are not allowed to contain the value "NotUnderstood".

The sentence you quoted ("the answer for a key not understood..."
implies that a not-understood key is assumed to be a proposal, not a
declaration, which matches my point 1.

The issue is that the rule at the top of page 53 is incomplete,
because it doesn't cover the case of a not-understood key.  For those,
a reply may appear though it wasn't expected (the protocol says that
there is no reply to declarations).  And that reply will have a
NotUnderstood value, which isn't a legal declarer-value.

 Mallikarjun> Regarding your proposed #2, I am not sure a proposer
 Mallikarjun> should ever "silently ignore" a a "NotUnderstood"
 Mallikarjun> response.  A NotUnderstood response always has a
 Mallikarjun> semantic requirement on the proposer: not to use
 Mallikarjun> protocol behavior associated with the key within the
 Mallikarjun> scope of the key (connection/session).

True for negotiations, but I don't see how declarative keys,
especially optional ones, can have a semantic effect on the sender
that depends on whether they are understood or not.  Certainly the
X#NodeArchitecture key doesn't.  I'd argue that a key that has
semantic effects at the sending end must necessarily be a negotiation
key, not a declarative key, because declarations by definition can
only affect actions taken by the recipient.

     paul

---

From: "Mallikarjun C." <[email-masked]>
Date: Mon, 21 Aug 2006 15:21:15 -0700 (PDT)

When I read 3720, it is clear to me that the first
processing rule is about comprehending the key. 
Declarative vs. negotiated processing rules can only
follow comprehension - if an implementation does not
recognize a key, declarative vs. negotiated handling
is moot.  A proposer thus must always be prepared for
the eventuality of lack of comprehension by the other
side, unless the key is defined in 3720 itself.

But I now see that that's clearly not how you read it.
 I will add some text along the above lines in the
absence of objections.

Mallikarjun

---

From: William Studenmund <[email-masked]>
Date: Mon, 21 Aug 2006 18:32:36 -0700

>  I will add some text along the above lines in the

Sounds good!

Take care,

Bill

---

From: "Sandars, Ken" <[email-masked]>
Date: Mon, 21 Aug 2006 22:39:29 -0700

Hi Mallikarjun,

The penny drops! Adding that clarification would be excellent.

Thanks,
Ken

> From: Mallikarjun C. [mailto:[email-masked]] 
> Sent: Tuesday, 22 August 2006 08:21
> To: [email-masked]
> When I read 3720, it is clear to me that the first processing 
> rule is about comprehending the key. 
> Declarative vs. negotiated processing rules can only follow 
> comprehension - if an implementation does not recognize a 
> key, declarative vs. negotiated handling is moot.  A proposer 
> thus must always be prepared for the eventuality of lack of 
> comprehension by the other side, unless the key is defined in 
> 3720 itself.
> 
>  I will add some text along the above lines in the absence of 
> objections.
> 
> 
> Mallikarjun
> 
> 
> Tired of spam?  Yahoo! Mail has the best spam protection 
> around http://mail.yahoo.com 
>