Re: draft-ietf-v6ops-security-overview-06.txt comments

[Jun-ichiro itojun Hagino <itojun@itojun.org>]

>Hi itojun,

	hi!  long time no see!  were you in chicago?

>> 	i'm not too sure if the document have reached WGLC or not, but anyways,
>> 	there are some critical comments coming up from my side.
>> 	http://ipv6samurais.com/ipv6samurais/openbsd-audit/
>> 	(still under development)
>
>Yes -- in fact, it's already in RFC-editor's queue, so the possibility 
>of making non-editorial changes is rather slim.

	ok, i guessed that.

>> 	overall (up to 2.1.9):
>> 	- i'm not too sure if it is appropriate to go into middleboxes too much
>> 	  in this document or not.  the document should clear up its standpoint
>> 	  either to the standards side (like those who write specifications for
>> 	  normal nodes), or to the "real life" side (like those who implement
>> 	  middleboxes)
>
>There has been significant debate about this, and much of it during 
>IESG review (see https://datatracker.ietf.org/idtracker/ballot/2044/), 
>so changes at this time are likely very substantial and not possible.

	maybe you can mark each of the section title with "[spec issue]",
	"[operational issue]" or something.  of course there are some specs
	that are vague between the two.

>> 	- i guess we need some upper-limit on a number of hop-by-hop option
>> 	  headers present on a packet.  i would say "at most 1", as the sender
>> 	  can encodde as many stuffs as needed into a single hop-by-hop option
>> 	  header.
>
>Yes, that would be a good idea, but would need to be done in a spec 
>that updates RFC 2460 or such.

	yup.  cannot wait to see rthdr0 deprecation RFC by the way...

>You may be interested in draft-krishnan-ipv6-hopbyhop-01.txt which 
>goes even a bit further than that.  I guess this could potentially be 
>a good topic for the future IPv6 maintenance WG.

	i will check it out.  thanks!

itojun
# ipv6samurais.com: saving the world with code and sword