Re: DRAFT Montreal minutes - X#NodeArchitecture comments
>>>>> "William" == William Studenmund <wrstuden@xxxxxxxxxxxxxxxxx> writes:
William> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
William> On Aug 17, 2006, at 6:43 AM, Paul Koning wrote:
>> 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.
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
_______________________________________________
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]