I didn't catch a lot of the names and may
be really off on the names of the RRs and drafts and the like.
--asp
reworking agenda - randy's laptop does not work so went off old one
kre remembered corrections
kitchen sink not being discussed here
skip break - no coffee
purpose of group is to push things PS->DS
map
all set to go w/ testing of insecure, but problems w/ mailing list
if you think you are on the list, send map email
think know 3 implementation of dynimic update/notiffy
- notify - are 2 parts
- same with update
may have 1 example of each; prob have 2 of all of them
need independant implementation of each end
need to demo each proto is interopable w/ 2 impls of each proto
do not need to demo that update is interoperable with notify
dynamic update is kinda uless w/o notify - so testing dynamic will also
test notify
let them know if dont get email by friday
secure dynamic update - one impl in progress - tis
is one other also - rob stevens, competivive automation
need to give justification of why you want to subscribe to list or will
ignore
ohta
have mailing list w/ 10 people
2.5 implementations
martic chapple (??) - seems to be working
prati opta (??) - not yet public, doing private testing now, maybe this month
josh, doing ixfer, not done yet
hope tests to begin this month
do each of the 4 drafts have test plans?
which? one does - map
please share the test plans publically
what is dns testing event in sj?
vixie: imc is doing an event on jan 27 in bay area
don't know why they are doing this but vixie will be there
with several versions of bind
also microsoft will be there
someone from usoft: goal is to test on a wide scale
- test dynamic update, and dhcp/dns interaction
- hopes that there are multiple implementations
test plan? not yet; hope to be one
report? hope so
please do it formally so that results can be public and usable
- results will not be public
- thus is not useful for this working group
classless - iesg wants some change; waiting for new draft from authors
issue is the / in the example
agreement to change has been done
mild disagreement which way to change
change has not been done
1101 examples should be removed
bush: would kre/bush change the draft and get the authors to resubmit
local-names - informational
test-tlds - bcp
kitchen-sink - need time to update doc
ncache - author not here, kre speaking
vixie: yes, is ok
kre: we are done
in last call
DS
vixie on tsig
- way to do cheap security until real thing is there
all comments are now in or answered
will go to last call after notice comes out
no more comments, no more issues, will issue last call
local-compression
peter is not here
reading his email message
draft is out
implementation in progress
modifing debugging tool in progress
testing need guinne pig RR
ask IANA for RR - GP
should be more than 1 domain name in the RDATA
maybe RP RR?
could use the SOA....
suggest - use SOA
bug in section 5, will be fixed
kre: are only 4 type codes; 2 already used, this will eat 1 more
- is this worth it?
there is also a canadate for other bit
can also have all 4 bits set mean extend bit - to get 6 more bits
bush: please bring this discussion up on the list
dns error (?)
got comments
authors finger pointing who to do next draft
internationalization concerns
dname
other concerns
prob at least 2 more drafts needed
please send in more comments
donalds udp draft
way of getting bigger udp response
objections heard - forwarding of queries via path of servers that
may not understand this may cause loss of data
- problems of recursive queries
- most queries don't need this
use tcp instead? overhead?
larger udp may be less load than using tcp
do you need to know path mtu?
scheme may be too complex - to figure out how big a udp response
to ask for
vixie: on really advanced system, you might be able to find how
big a udp socket you can use
- but if this comes out, and makes things more
usable, then vendors will give us this knob
need to specify a resonable default behaviour if you don't
have any better info of what to use - perhaps 1280
dnssec is the problem we are trying to solve here
so might be possible to change the dnssec to say that
security aware resovlers should do something like this
vixie: 2 other concerns - are a huge base that does not look at rcode
on queries, so if there are resolvers that send
garbage, new server will do something whako and
thus not work; and strict servers that do not
implement this may ignore these queries
- will check the root server to see they get rcode with
random data
vixie has another proposal that was more complex, will look
at merging these
simplicity is good, but it also has to work
vixie draft: like tsig, add rr in addition section, cache info
no ambiguity if you get answer back
more bits to put size, so less ambiguity
vixie's way may be a better way of additional funcionality
hop-by-hop or end-to-end attribute
further discussion on the list
128bit ipv6 addr, rfc 1880 for quad RR
view addr different, split into pieces - 8+8 or routing goop
thus how to renumber a site & change all of the quad RRs
- esp w/ security & having to resign all of the records
- takes too long
so how to change so that don't need to resign if renumber, plus
get more than 1 prefix
so add bit length of prefix plus pointer to the rest of the stuff
and pointers can recurse
should gain bits at every lookup
- is it an error to loose? or stay the same?
can trade off efficiency of building data vs doing lookups
need to make sure # of bits is not fixed
also need to do reverse lookups
so, should we do this? does it make sense?
really an ipng draft, but want feedback from dns community
additional section should be filled in as much as possible with
the rest of the quads
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
draft needs work
rd length will be different from what it is now
resolver does the combining of these to make real addr
does this give us variable length addrs????
can end up with more than 1 real addr as you do the combining
name compression is unresolved issue
ignore the d-bit hack in this stuff
d-bit (another draft)
in-addr lookups (for above) are problems
need to track delegation heirarchy
keep going until you get to the host
but need to store this delegation stuff in the dns
stored as
number of bits in this delegation
owner names
so N.N.N.N.N.N...ip6.int. Dbit M dns.name
where NNNN is addr and M is how many more to add
but things are in binary, not text/bcd
this presentation was not clear
not sure if this fits the way the we do delegations????
where is authority break?
is it like NS or something else?
this idea has been around for a while
this draft does *not* match the way that i do delegations.
how do you do a lookup on a site local or xx local addr?
lots of discussion ensused.
trying to delegate on bit boundaries.
or just do the cidrized in-addr trick (at least to all but the
bottom nibble).
or do bit.bit.bit.bit.....
