[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

RE: DRAFT Montreal minutes - X#NodeArchitecture comments



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.


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

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

[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! ;-)


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

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


[IETF]     [Linux iSCSI]     [Linux SCSI]     [Linux Resources]     [Yosemite News]     [IETF Announcements]     [IETF Discussion]     [SCSI]

Add to Google Powered by Linux