RE: DRAFT Montreal minutes - X#NodeArchitecture comments
Hi David,
Yes, you've got the angle I'm coming from. It's important to express the
idea that while it is a declared key, the rules for declared keys are
being slightly bent such that it is not a protocol error to receive a
"NotUnderstood" in the context of the other node processing it as an
offered key.
And yes, if you're going to spell out the use cases, I think you need to
cover them all.
As you say, little more wordsmithing and it should be gold!
Cheers
Ken
> -----Original Message-----
> From: Dave Wysochanski [mailto:davidw@xxxxxxxxxx]
> Sent: Monday, 7 August 2006 17:06
> To: Sandars, Ken
> Cc: ips@xxxxxxxx; William Studenmund
> Subject: Re: DRAFT Montreal minutes -
> X#NodeArchitecture comments
>
> Sandars, Ken wrote:
> > Hi David,
> >
> > Comments inline [Ken]
> >
> > Cheers
> > Ken
> >
> > > -----Original Message-----
> > > From: David Wysochanski [mailto:davidw@xxxxxxxxxx] >
> Sent: Friday,
> > 4 August 2006 04:52 > To: Sandars, Ken > Cc:
> ips@xxxxxxxx; William
> > Studenmund > Subject: 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.
> > > >
> > >
> > > Isn't this last sentence in conflict with the RFC paragraph I >
> > mention below?
> >
> > [Ken] No. The idea is to catch the required behaviour. It has to
> > consider that to the nodes who know, the key is
> declarative, while for
> > others the key is negotiated (hence the NotUnderstood response is
> > legal). Thus the negotiation engine needs to track that once it has
> > declared the key the other node is only allowed to:
> > (1) declare a valid value for the key, or
> > (2) send a response of "NotUnderstood", or
> > (3) do nothing more with the key.
> >
>
> I think I understand where you are coming from though I don't
> think these last two sentences are necessary - it is an
> implementation problem right? You have a "key type" of
> declarative or negotiated, and you have to pick one. If you
> pick "declarative", then you have the problem of recording
> the "NotUnderstood" value. But in that case, the code should
> always handle "NotUnderstood" as a reserved value, and not
> record it, per the spec. If a node sends a special X# or X-
> key, it should always know how to respond to other nodes that
> don't implement the key. When you write the code for the
> special key you have to take that case into account, which is
> why I'd guess this case came up in Montreal.
>
> Am I on the right track?
>
>
> >
> > > Sending "NotUnderstood" in a key value is a > protocol
> error, so
> > why would a node receiving it be forced to > consider the
> other node
> > having declared it?
> > >
> >
> > [Ken] It's not a protocol error for a node which doesn't implement
> > this extension key.
> > Don't confuse the term 'declare' with 'propose'/'accept'.
> Nodes which
> > implement this key know it's a Declarative key; for other
> > implementations the key is negotiated.
> >
> Ok well, by putting in the sentences you were proposing, it
> read like people needed to know they couldn't initiate the
> "NotUnderstood"
> declaration. This should be clear from the original 3720 rules.
>
>
> > [Ken] The reason it should be considered 'declared' is
> because it has
> > been received (parameter negotiation engines tend to get
> this right).
> > It will be a protocol error if the other node sends it again
> > (obviously in error). This applies equally to nodes which
> are aware of
> > the key and those which are not. I also wanted to indicate
> that even
> > if the value of the received key is not used in the
> intended logging
> > role (say is discarded), the parameter negotiation engine
> still needs
> > to note that the other node has sent it once and to barf if
> it sees it again.
> >
> Right. Redeclaration of the key is forbidden, per p. 3 of
> the ID, and 3720. I really think you're stating what should
> already be clear.
> It is good discussion for implementors, but I'm not sure we
> need to add more wording.
>
>
> > [Ken] For example, consider a broken implementation which
> thinks it's
> > cute to declare the key, but doesn't update its reception engine to
> > recognise the inbound key (because it isn't interested in
> logging the
> > info). This is test suite paradise! ;-)
> >
>
> But that's clearly a buggy implementation. Do we really need
> to add more words for that?
>
> >
> > > Note also that I added this wording:
> > > 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
> > >
> > > to match some of the wording in the security section:
> > > For the above target, an appropriate implementation might be
> > > logging of received key values, but no transmission
> of the key.
> > > For the initiators, an appropriate implementation might be
> > > transmission of the key, but no logging of received
> key values.
> > >
> > > I was also thinking from my developer's hat and >
> > compartmentalizing the differing parts of the
> implementation > (which
> > have different things to think about). On my end I > have two
> > different coding items to track the transmission of > the
> key vs the
> > logging.
> > >
> >
> > [Ken] Fair enough, but what about the option to not send
> and to not log?
> > That's why I proposed a different set of words for that part.
> >
>
> Ah - sure that is valid and a reasonable case - you have
> switches for sending and logging, and both are off by
> default. In that case you wouldn't send "NotUnderstood" in
> response to another node's declaration, but would just
> silently discard.
>
> Is this case the root of your original post where you
> suggested new wording?
>
> If so, I agree that the current wording I have doesn't cover
> that case, so let me think some more about it. Perhaps some
> of what you originally proposed is what we want. But I think
> some of the explicit statements about "NotUnderstood" are
> redundant and may muddy the water.
>
>
> > >
> > > > Thoughts?
> > > > Ken
> > > >
> > > > -----Original Message-----
> > > > From: David Wysochanski [mailto:davidw@xxxxxxxxxx] > > Sent:
> > Thursday, 3 August 2006 05:56 > > To: William Studenmund > > Cc:
> > Sandars, Ken; ips@xxxxxxxx > > Subject: 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.
> > > > >
> > > >
> > > > 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].
> > > >
> > >
> >
>
> _______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ips
>
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]
