Subject: [Nsis-imp] Unknown GIST version number

From: "Christian Dickmann" <[email-masked]>
Date: Fri, 24 Mar 2006 19:03:24 +0100

Hi Robert,

I got a question about an error condition: 
In GIST-09 A.1. the draft says:
"Parsing failures may be caused by unknown Version or Type values,
   inconsistent R flag setting, or a Message Length inconsistent with
   the set of objects carried.  In all cases the receiver MUST if
   possible return a "Common Header Parse Error" message
   (Appendix A.4.4.1) with the appropriate subcode, and not process the
   message further."

I wonder if an unknown version should really result in an error. 
If the node is just an intermediate node, why shouldn't it just forward
the message? Otherwise new GIST versions could be a deployment problem.
Did I miss some note in the draft about this topic, or is there any
other reasoning?

Thanks,
Christian Dickmann

_______________________________________________
NSIS-imp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis-imp

---

From: "Hancock, Robert" <[email-masked]>
Date: Sat, 25 Mar 2006 12:25:03 -0000

Hi Christian,

It's a good question, and deserves some discussion. The rationale
is in fact based on a consideration of what we should define now
to ease deployment in the future:

*) at the moment there is only one version, so the condition is not
exercised (except by erroneous implementations)

*) if a new version is created (which I doubt in the near future),
then the specification will have to define how to handle backwards
compatibility. if the new version includes the old as a subset, then
the question will be whether to try the newest version by default or
not when initiating signalling. for the long term efficiency, it's
nicer to be optimistic and leave open the option to negotiate down.

In this case, if the rule was 'forward transparently' then the first
node to deploy the new version would never find any peers, even though
it could interact quite happily with nodes supporting earlier versions.
The 'reject with error' rule allows the node to detect the condition
and retry with a lower version number (in fact, it should be able to
choose immediately the right version based on what is reported in the
error).

Hope this seems reasonable,

r.

-----Original Message-----
From: Christian Dickmann [mailto:[email-masked]]
Sent: Fri 24/03/2006 18:03
To: [email-masked]
Subject: [Nsis-imp] Unknown GIST version number
 
Hi Robert,

Thanks,
Christian Dickmann

-- 

Visit our website at www.roke.co.uk

Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.

The information contained in this e-mail and any attachments is proprietary to
Roke Manor Research Ltd and must not be passed to any third party without
permission. This communication is for information only and shall not create or
change any contractual relationship.

---

From: "Christian Dickmann" <[email-masked]>
Date: Sat, 25 Mar 2006 14:58:25 +0100

Hi Robert,

your reasoning sounds OK to me. Just one additional question:

Is the current GIST spec Version 0 or 1? I did not find any value

in the draft.

Christian Dickmann

________________________________

From: Hancock, Robert [mailto:[email-masked]] 
Sent: Saturday, March 25, 2006 1:25 PM
To: Christian Dickmann; [email-masked]
Subject: RE: [Nsis-imp] Unknown GIST version number

Hi Christian,

r.

-----Original Message-----
From: Christian Dickmann [mailto:[email-masked]]
Sent: Fri 24/03/2006 18:03
To: [email-masked]
Subject: [Nsis-imp] Unknown GIST version number

Hi Robert,

Thanks,
Christian Dickmann

-- 

Visit our website at www.roke.co.uk <http://www.roke.co.uk/>  

The information contained in this e-mail and any attachments is
proprietary to 
Roke Manor Research Ltd and must not be passed to any third party
without 
permission. This communication is for information only and shall not
create or 
change any contractual relationship. 
_______________________________________________
NSIS-imp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis-imp

---

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 27 Mar 2006 10:16:27 +0100

aha - well, that is an excellent question.
 
i think the implementors have converged on the value 1, presumably by
telepathy...
 
i will add a note to the tracker on this.
 
thanks,
 
r.

	-----Original Message-----
	From: Christian Dickmann [mailto:[email-masked]] 
	Sent: 25 March 2006 13:58
	To: Hancock, Robert; [email-masked]
	Subject: RE: [Nsis-imp] Unknown GIST version number

	Hi Robert,

	Is the current GIST spec Version 0 or 1? I did not find any
value

	in the draft.

	Christian Dickmann

	Hi Christian,
	
	It's a good question, and deserves some discussion. The
rationale
	is in fact based on a consideration of what we should define now
	to ease deployment in the future:
	
	*) at the moment there is only one version, so the condition is
not
	exercised (except by erroneous implementations)
	
	*) if a new version is created (which I doubt in the near
future),
	then the specification will have to define how to handle
backwards
	compatibility. if the new version includes the old as a subset,
then
	the question will be whether to try the newest version by
default or
	not when initiating signalling. for the long term efficiency,
it's
	nicer to be optimistic and leave open the option to negotiate
down.
	
	In this case, if the rule was 'forward transparently' then the
first
	node to deploy the new version would never find any peers, even
though
	it could interact quite happily with nodes supporting earlier
versions.
	The 'reject with error' rule allows the node to detect the
condition
	and retry with a lower version number (in fact, it should be
able to
	choose immediately the right version based on what is reported
in the
	error).

	r.

	-----Original Message-----
	From: Christian Dickmann [mailto:[email-masked]]
	Sent: Fri 24/03/2006 18:03
	To: [email-masked]
	Subject: [Nsis-imp] Unknown GIST version number
	
	Hi Robert,
	
	I got a question about an error condition:
	In GIST-09 A.1. the draft says:
	"Parsing failures may be caused by unknown Version or Type
values,
	   inconsistent R flag setting, or a Message Length inconsistent
with
	   the set of objects carried.  In all cases the receiver MUST
if
	   possible return a "Common Header Parse Error" message
	   (Appendix A.4.4.1) with the appropriate subcode, and not
process the
	   message further."
	
	I wonder if an unknown version should really result in an error.
	If the node is just an intermediate node, why shouldn't it just
forward
	the message? Otherwise new GIST versions could be a deployment
problem.
	Did I miss some note in the draft about this topic, or is there
any
	other reasoning?
	
	Thanks,
	Christian Dickmann

	-- 

	Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN,
UK. 
	
	The information contained in this e-mail and any attachments is
proprietary to 
	Roke Manor Research Ltd and must not be passed to any third
party without 
	permission. This communication is for information only and shall
not create or 
	change any contractual relationship. 

--