RE: [Nsis-imp] some clarification questions regarding GIMPS

["Hancock, Robert" <[e-mail]>]

and a brief followup on the cookie front:

for *interoperability* the only thing that is required is to
copy the cookies correctly between Q/R/C messages. so, for
testing, that is the only thing that will get exercised.

the *generation and validation* you do is up to the implementation 
and not visible externally (you might just generate a random
number and not validate anything). we will give informative
examples in the spec of how to do a good job, however. but 
in any case we will ensure that they don't violate the basic
design goals (e.g. stateless handling of an initial query.)

r.


> -----Original Message-----
> From: Hancock, Robert 
> Sent: 26 April 2005 11:48
> To: Georgios Karagiannis; [e-mail]
> Subject: RE: [Nsis-imp] some clarification questions regarding GIMPS
> 
> 
> hi georgios,
> 
> thanks for the questions! see in line...
> 
> > -----Original Message-----
> > From: Georgios Karagiannis [mailto:[e-mail]] 
> > Sent: 26 April 2005 10:44
> > To: [e-mail]
> > Subject: [Nsis-imp] some clarification questions regarding GIMPS
> > 
> > 
> > Dear all
> > 
> > We at the moment implementing the GIMPS protocol and we find 
> > that there are some issues
> > that would need some clarification, etc.
> > 
> > These issues are:
> > 
> > 1- For the implementation of the discovery mechanism,it is 
> > important to know 
> > if a procedure has to be implemented to check whether the 
> > sender of the 
> > Query cookie is also the sender of the confirm cookie.
> 
> this is a hard question. the ideal answer is 'yes' but, given
> that the purpose of the 3 way handshake is supposed to allow 
> the responding node to forget the query contents and work only
> with the confirm, it is not clear to me at the moment that it
> is possible in general, unless the responder cookie is designed
> to refer to information that will be repeated in the confirm.
> (we have started this discussion at 
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue17)
> 
> we need to do more work on this, and i have text lying around,
> but still need to make it comprehensible (and plausible).
> 
> > 
> > 2- The value of the D-flag that corresponds to the upstream and 
> > downstream has to be specified.
> 
> do you just mean 'is 1 up and 0 down or the other way round'?
> or something more subtle?
> 
> > 
> > 3- The function of the source prefix and destination prefix of the 
> > MRI object has to be defined.
> 
> this is to allow wildcarding on address fields. the signalling message
> delivery uses the actual addresses, but the MRI is interpreted as
> referring to the whole subnet (e.g. might be used by an NSLP as a
> wildcard in a traffic classifier). GIMPS should reject 'too broad'
> wildcards (in a manner to be defined in the next version of the
> draft).
> 
> > 
> > 4- In our implementation we are only using IP-Ver 4. 
> > Therefore it might be 
> > useful to know if the entire 32 bit word for the Flow Label 
> > parameter in the 
> > MRI object must be ignored or set to zero (empty object).
> 
> wrong on both counts (see
> http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue34
> which we wrote during the interoperability testing
> in minneapolis). the short answer is:
> if the flag for a field in set in the first word, the field must
> be present and interpreted as significant
> otherwise, the field must not be present at all.
> 
> (this is supposed to be implied by the ':' symbols in the box
> notation indicating 'optional fields' but I accept it is a bit
> hard to spot and the next version will be more explicit.)
> 
> at the moment my expectation is not to try to pin down exactly
> which version/flag combinations must be supported, but to 
> rely on common sense (e.g. people won't generate MRIs with v=4
> and F set) and defining a general purpose ICMP-like 'parameter 
> problem' message to allow people to report that they don't like
> particular settings. i'd appreciate input on that, however.
> 
> hope this helps,
> 
> r.
> > 
> > Could you clarify the above?
> > 
> > Best regards,
> > Georgios
> > 
> 
> _______________________________________________
> NSIS-imp mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis-imp
> 

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