RE: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT traversal, M3, also L2/L19/L24)

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

Hi all,

I think how to handle this set of comments is now pretty clear.
I've pasted this discussion thread into the issue tracker at
(http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-ntlp-issues/issue109)
and they will be implemented in version -10.

cheers,

r.

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]] 
> Sent: 16 June 2006 15:30
> To: [e-mail]
> Cc: Hancock, Robert; [e-mail]
> Subject: Re: [NSIS] AD review: draft-ietf-nsis-ntlp-09 (NAT 
> traversal, M3,also L2/L19/L24)
> 
> 
> Hi,
> 
> I think the proposed solution in these email is fine. I am also fine 
> with maintaining the split. But please be clear about it.
> 
> Cheers
> 
> Magnus
> 
> [e-mail] wrote:
> > Hi all,
> > 
> >>> M3. NAT traversal for GIST.
> >>> Section 7.2:
> >>>
> >>> What plans are there for clearly defining NAT behavior 
> for GIST and 
> >>> the relevant NSLPs? I think one should avoid repeating 
> the mistake 
> >>> with NATs of not specifying the behavior sufficiently for 
> NSIS. Thus
> > I 
> >>> think there is need to specify in great deal what is 
> going to happen 
> >>> at the translation.
> >> There is already an individual I-D which describes the 
> >> required behaviour on a NAT, 
> >> draft-pashalidis-nsis-gimps-nattraversal-02.txt
> >> (see in particular section 6). I believe that this document 
> >> should become a working group document (of at least some 
> >> working group - I'm not clear on the relationship with 
> behave here). 
> > 
> > I think that the NAT traversal material should belong in a separate
> > document - as we have seen with STUN, for example, the NAT
> > considerations
> > change - so I think it makes sense to have it separate.
> > 
> >> What we've tried to do so far is distinguish the GIST 
> >> specification, i.e. what nodes implementing GIST have to do, 
> >>from the NAT specification, i.e. what NAT nodes have to do 
> >> with GIST messages.
> >> The overall solution is outlined here in the GIST spec, but 
> >> there is a lot more detail that can be added about what NATs 
> >> should do (specifically in terms of managing their bindings) 
> >> which is not really a concern of the GIST implementor so it 
> >> seems reasonable to keep the two separate.
> > 
> > Agreed.
> > 
> >>> L2. Section 3.3, page 12, second paragraph:
> >>> "  In addition, it should be noted that NAT traversal almost
> > certainly
> >>>     requires transformation of the MRI field in GIST messages (see
> >>>     Section 7.2).  Although the transformation does not have to be
> >>>     defined as part of the standard, the impact on existing
> > GIST-aware
> >>>     NAT implementations should be considered."
> >>>
> >>> It seems that not defining the NAT behavior for GIST can 
> potentially 
> >>> cause interop problems and make it very hard to use. What is the
> > plans 
> >>> for addressing this? Are there already existing GIST-aware NATs?
> >> This is probably badly worded. What we are trying to say is 
> >> that, just as there is a split:
> >> a) the GIST spec, and
> >> b) how NATs handle GIST messages
> >>
> >> when you define a new MRM there are two things to do:
> >> a') how to modify GIST implementations to handle the MRM
> >> b') how to modify NATs to handle the new MRM
> >>
> >> Section 3.3 is saying that the information provided as part of
> >> (a') does not have to define all the details of NAT traversal, 
> >> but that (b') has to be considered, e.g. if necessary as an 
> >> extension to the base GIST nat traversal specification.
> > 
> > I think a rewording of the text in 3.3 would be a good idea.
> > 
> >> (As an aside, there is conceptually a class of MRMs that will 
> >> in fact be transparent to NATs. It may be valuable to 
> >> highlight those in some way so that they can be deployed 
> >> without having to update NATs where the update only consists 
> >> of the information "you don't have to do anything".)
> >>
> >> (Another aside: the GIST NAT traversal functionality has been 
> >> implemented by at least one team. I don't believe it has made 
> >> it into any standard distributions. The 'existing' in the spec 
> >> means 'existing at the time that the new MRM is being proposed'.)
> >>
> >>> L19. Section 7.2, page 74:
> >>>
> >>> "Note that Confirm messages are not translated."
> >>>
> >>> Why isn't them? Also where is that specified? And what is really
> > meant 
> >>> with "not translated"?
> >> Well, the solution is designed so they don't need to be 
> translated. 
> >> (If they did, it would be very tricky, since often they are 
> >> carried in C-mode and are invisible to NATs anyway.) Probably 
> >> the specification should say more explicitly "only Query 
> >> messages and messages with a NTO are translated by the NAT".
> >>
> >> "Not translated" means "the payload of the UDP message is not 
> >> translated". So that can also be made more explicit.
> > 
> > Please do make it more explicit.
> > 
> >>> L24. Section A.3.8:
> >>> "the number of GIST payloads translated by the NAT"
> >>>
> >>> The NAT? There might be several NATs on the path and it 
> is not clear 
> >>> how that is handled. One concern would be if different 
> NATs translate
> > 
> >>> different fields.
> >> The idea is that the 'list of translated objects' field 
> >> contains the objects that have been successfully translated by 
> >> every NAT.
> >> In other words, it is the intersection of the translation 
> >> capabilities of the set of traversed NATs. The first NAT 
> >> initialises it, subsequent NATs may have to remove objects 
> >> which it could not translate.
> >> The "Type-Count" field is just the length of this list (to 
> >> allow the message to be parsed). This needs to be made clearer 
> >> in the spec.
> > 
> > If you can add this to your ToDo list for the update, that would be
> > great.
> > 
> > thanks,
> > John
> > 
> 
> 
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone [phone]
> Torshamsgatan 23           | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: [e-mail]
> 

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