Subject: RE: (un)necessary features (was: RE: [NSIS] WGLC fordraft-ietf-nsis-ntlp-13.txt)

From: "Cheng Hong" <[email-masked]>
Date: Fri, 20 Apr 2007 19:14:06 +0800

Hi Robert,

Regarding the items you listed out:

> - the authorisation model (mainly 4.4.2) and TLS name 
> checking rules (5.7.3.1)

The authorisation part (4.4.2) seems a bit obscure and contains too many
loosing ends. Also, most part of it sounds informational and belongs to
local node control. There is no requirement that all the nodes behaving
the same or following the same rule.  

Therefore, it would better if this part is moved to the Security
Considerations section after the Peer Node Authentication (8.2). Anyway,
it is not part of the GIST protocol, and also not a issue solved by GIST
itself.
 
> - recommendations on evolvability of D-mode (3.2)

This part sounds OK. 

> - details on IP option handling (5.3.2)
> - guidance on overload protection (mainly 8.4)

This seems like some attempt to counter the DoS attacks. However,
falling back to a non-NSIS node and bypassing the Query does not sounds
correct. Wouldn't it result in the attack propagates the attack to the
whole path? Shouldn't the GIST node drop the excess Query instead?

> - multipath handling (7.1.4)

This seems quite important. If not addressed, GIST implementation might
just breakdown in such environments. 

Regarding the scenarios described in the first paragraph (last sentence)
"For example, ...., or might appear to have disappeared even though it
is still attached to the network via a different route", is it possible
to share a bit more on the use case you envisaged?

Cheers

Cheng Hong

> -----Original Message-----
> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Thursday, April 19, 2007 11:32 PM
> To: Lars Eggert; ext Jukka MJ Manner
> Cc: nsis
> Subject: (un)necessary features (was: RE: [NSIS] WGLC 
> fordraft-ietf-nsis-ntlp-13.txt)
> 
> hi all,
> 
> > -----Original Message-----
> > From: Lars Eggert [mailto:[email-masked]]
> > Sent: 19 April 2007 15:47
> > To: ext Jukka MJ Manner
> > Cc: nsis
> > Subject: Re: [NSIS] WGLC for draft-ietf-nsis-ntlp-13.txt
> > 
> > On 2007-4-19, at 14:35, ext Jukka MJ Manner wrote:
> > > Yet, in a separate email I have suggested the addition of 
> "Peering 
> > > data"
> > > that could be used by NSLPs to give more details for the peering 
> > > decision when receiving a QUERY. This is an important
> > function I would
> > > like to be enabled. I can provide e.g. text for a small 
> subsection 
> > > that identifies the issue, shows the solution and discusses its 
> > > implications on the NSLP layer.
> > 
> > One of the points that came up during the IESG evaluation was that 
> > GIST was already very complex, and other ADs were 
> questioning whether 
> > all the features were really needed or if it could even be 
> understood 
> > and implemented.
> > 
> > I think Magnus and me got the point across that a generic signaling 
> > framework comes with a certain level of complexity, but if the next 
> > revision that hits the IESG adds more features - esp. ones that 
> > apparently aren't required for any existing NSLP - that 
> probably would 
> > send a very wrong message.
> > 
> > The WG needs to really think carefully about this.
> 
> there are a couple of points here.
> 
> 1. for this particular case of early peering data, I believe 
> that the functionality necessary is already in the spec (has 
> been since version 7) and is used by the QoS-NSLP among 
> others. I don't believe anything extra is needed but I'll 
> explain why in a separate mail.
> 
> 2. as a more general point, if people spot functionality or 
> text that they feel is unecessary (for whatever reason) then 
> that would be fine to highlight during the WGLC process. The 
> list of things that have been added recently can be found in 
> the change history
> (E.1 and E.2), and it would be good to focus here 
> particularly if the additions seem worthwhile. some highlights:
> 
> - the authorisation model (mainly 4.4.2) and TLS name 
> checking rules (5.7.3.1)
> - recommendations on evolvability of D-mode (3.2)
> - details on IP option handling (5.3.2)
> - guidance on overload protection (mainly 8.4)
> - multipath handling (7.1.4)
> 
> in particular, for the last two it would be good to know if 
> people find the text helpful or not (since it is mainly 
> informative). Related to the multipath handling discussion is 
> the question of whether GIST should have an explicit routing 
> state removal functionality, which strikes me as a case of 
> premature optimisation compared to what is already possible 
> in the protocol, but which some people have asked for in 
> general terms in the past.
> 
> At the moment I am unaware of any outstanding specific 
> 'feature XXX could be removed' suggestions (there have only 
> ever been very few) but that does not mean that some could 
> not be made.
> 
> r.
> 
> > 
> > Lars
> > 
> > 
> > 
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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