Hi, Suresh, I think some of the points/questions that I asked in my e-mail were had not raised before.
And I think that even if the document were to continue in its current form, those questions should be answered -- and possibly the answers should be incorporated in the document. So I look forward to the aswers... :-) Thanks! Kind regards, Fernando On 22/12/2010 02:01 a.m., Suresh Krishnan wrote: > Hi Fernando, > > On 10-12-21 06:53 PM, Fernando Gont wrote: >> Folks, >> >> FWIW, I never got a response to these comments I sent a while ago.... > > I understood your comments as agreeing with Ran's (and they have not > been resolved either). The points you, Ran and Tony raised about the > scope of the draft being larger than it should be are all valid, but all > the additional features (other than just the common format) have been > added due to feedback from the working group (mailing list and face 2 > face meetings). We will discuss with the chairs and see what is an > acceptable way forward. > > Thanks > Suresh > >> >> Thanks! >> >> Kind regards, >> Fernando >> >> >> >> >> -------- Original Message -------- >> Subject: Some comments questions on draft-krishnan-ipv6-exthdr-08 >> Date: Wed, 17 Nov 2010 11:50:40 -0300 >> From: Fernando Gont <[email protected]> >> To: [email protected] <[email protected]>, Suresh Krishnan >> <[email protected]>, [email protected], [email protected], >> [email protected] <[email protected]> >> >> Folks, >> >> Some comments/questions regarding the aforementioned I-D: >> >> * Meta: >> As noted by Ran Atkinson, I think you should clearly state what sort of >> options that would not fit in the Hop-by-Hop or the Destination Options >> headers you think could be specified (that would warrant yet another >> extension header) -- Existence of this would be the motivation (or lack >> of) to pursue the proposal in this document. >> >> Specific comments: >> >> * Section 2 states: >> >>> The intention of the base IPv6 Specification [RFC2460] that >>> destination hosts not be permitted to skip unknown extension headers >>> continues to apply. >> >> Isn't this I-D all about allowing nodes to skip unknown headers?? >> >> >> * Section 2 states: >> >>> Another one is that this generic extension header conserves values in >>> the IPv4 protocol numbers registry. >> >> Of the top of my head, less than 25% of that space is used. And this is >> not going to change much (at least in the IPv4 world), as it is >> virtually impossible to use such packets across unmanaged NATs. >> >> >> * Setion 2 (2. Generic IPv6 Extension Header (GIEH) format). >> >> Why not simply enforce a TLV format? (i.e., no "Specific Type" at all) >> >> >> >> * Section 4 >> >>> 4. Exceptions >>> >>> The the Generic IPv6 extension header is generic enough that it is >>> suitable to use for most applications. However, it is possible that >>> the GIEH does not satisfy the requirements in all cases where new >>> extension headers are required. Hence, the existence of this >>> generic header does not necessarily preclude the definition of new >>> independent IPv6 extension headers. >> >> If this not going to be enforced for all new headers, is this worth the >> effort? >> >> >> * Section 5 (Future work) >> >>> From the PoV of a firewall, this is simple: either the traffic complies >> with my policy, or I block it. >> >> Put another way: if the extension header is unknown, this is the reason >> (other than the unknown syntax) for the firewall to block it. >> >> Thanks! >> >> Kind regards, > > -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
