Minutes IETF100: intarea
minutes-100-intarea-00

IntArea WG Agenda
IETF 100 - Singapore
15:20-16:50        Wednesday November 15, Afternoon Session I, Collyer

Chairs:
Juan Carlos Zuniga (JCZ) (SIGFOX)
Wassim Haddad (WH) (Ericsson)
Minutes taken by Ian Farrer

1. Agenda Bashing, WG & Document Status Updates (Chairs)
   10 minutes

Eric Nordmark (EN) - I have some updates to do on
draft-intarea-broadcast-updates.

2. TSV WG Updates, Gorry Fairhurst (GF)
   15 minutes
   draft-ietf-tsvwg-le-phb-02
   draft-fairhurst-tsvwg-datagram-plpmtud-01
   draft-ietf-tsvwg-ecn-experimentation-07

No comments.

3. Discovering Provisioning Domain Names and Data, Eric Vyncke (EV)
   20 minutes
   draft-ietf-intarea-provisioning-domains-00

Ian Farrer (IF) - Thanks for the document. I would like to see something
dealing with backwards compatibility for non-PvD aware hosts in the document.
EV - The authors have discussed this and think we have a solution. IF - That
was quick.

Ted Lemon (TL) - The configuration is different when there is one RA with all
prefixes. I would like to see a solution that allows us to make a PVD invisible
to a client that doesn't understand them

Lorenzo Colitti (LC) - not a fan of having implicit PVDs specific to the
link-local. One example is if RDNS. If you have two implicit PvDs you have a
broken configuration

EV - Any suggestions?

LC - Yes, put them in the same PvD. If they are conflicting then they are today
and they will be tomorrow. Tommy Pauly (TP) - I think that's a good point. As
part of this, if we want them to be explicit, you can put the same name in
them. This can work if you have one implicit. May be a problem if you don't
know what you're doing. To Ted's point. This needs to be addressed: 2 ways have
been discussed - 1, Containerized, (legacy would be outside a container). Could
work, but it's ugly. Long term compromise for short term fix. 2, Change how an
RS is sent out to indicate that PvD is supported and get a unicast RS with PVD
back. Could use a new multicast address. Old hosts would see what they see
today. TL - The way we looked at solving this problem is to have PVD
sub-options, containing info about which name server to contact for the PvD.
The only problem is if there is not enough space in the RA message. EV - 1
issue - like Tommy said, we're making a solution for the short term, not the
long term. LC - Ted, one of the main things we've improved is using http over
TLS can be much more easily extended. The 2 multicasts isn't super elegant, but
it can go away.

Bob Hinden (BH) - I made this comment before. I object to the use of URLs here.
Poor fate sharing properties. I'm not convinced you need that much data you
can't put it in datagrams. Appendix B has info about billing. This isn't
mentioned in the draft. We shouldn't be doing a billing document. EV - I'll
removing the billing EV - We need to agree to disagree about the fate sharing
of HTTP. There's a lot of information that needs to be conveyed BH - It's
fragile. It seems getting stuff from the web makes my head hurt. EV - It isn't
nice but it is sufficient BH - I think it isn't actually

LC - We thought about this a lot. The initial configuration in the RA must be
atomic and give you everything you need. The additional information is metadata
for higher layers. You must have full connectivity without the metadata that
you might never need. If we have a hard separation then it makes sense to use
this. Pierre Pfister (PP) - Everything needed for networking is in the RA. The
additional information is for applications. The way apps decide which PvD to
use. EV - We have an implementation in Linux and all networking is in kernel.
BH - Is this in the draft EV - Not all of it BH - You can understand my
confusion EN - So if PVD retrieval doesn't work, then the host still works TP -
It will still work without it. Captive portal needs more info. We believe that
it's better to put it somewhere that can be extended. LC -- Simultaneous PVD
and place to get the info

EN- What does HTTPS provide? Do the host have a list of root CAs, self signed
certificates? What problem is this solving? EV - You're going to have root CAs
EN - This needs to be written

TL - I don't know what the trust model for this. Who can claim an FQDN?
EV - Same as an SSID
TL - And that's a problem
EV - If you know the name and that it's fetched by SSL you can trust it.
TL - A localised name can't be trusted.
TP - I agree with (Ted's) point. The CAPPORT API can deal with with this. There
should be an IANA key registry for key. Putting stuff in UI is problematic. One
problem of a name as an identifier. Some attribute like a name would allow an
app to find a service from a name. Use cases like that are useful.

Suresh Krishnan (SK) AD hat off - A scoping statement would be useful. If you
add all of this stuff, you will end up with something like the old MIF draft.
Something with the failure cases would help specify what's going on. EN -
Thanks for your advice.

***** Conversation missed - Etherpad stopped working *****

TL - If you specify a PvD uses a zone, doesn't it imply a PvD represents that
zone?

BH - The security section has 2 sentences. I don't think that's adequate.
EV - It's a -00 version. There was a lot of discussion on privacy in Prague.
When we retrieve the data for the PvD server, it's likely to be hosted in the
domain that it is serving. We know that host OS's will try and discover if it
has a 'real' Internet connection. What is more private?

LC - I was able to read section 6 while you were talking about it. What is the
threat model? Is it that this user is running a version of an OS that uses
PvDs? The doc doesn't say. EV - The SSL server will know that an IPv6 address
is active. LC - It's not hard for a network to know what addresses are active
on the network. EV - We need to describe the threat against privacy in the
draft.

LC - Has the kernel patch for the implementation been sent upstream?
EV - It's done but not upstreamed.
LC - Please upstream ASAP. The linux kernel uses a value of SHA-1 that was
taken from a draft. It was changed in the RFC. They will not accept patches to
fix this. We need a version with an ND option code that won't change sooner
rather than later.

Mark Townsley (MT) - To upstream it, we need a real code for the ND option. We
need a consensus call from the group so we can't get a code allocated. SK - I
explained the procedure. The request needs to come from the working group and
I'll do it as fast as I can. BH - This seems a long way from being done. It
seems premature to get a code allocated. MT - It's not like this just appeared,
it's been going on for years. There's been multiple Hackathons,
implementations. If we screw up, we can get another code. the process exists
for a reason, we don't need an RFC for it. Wassim Haddad (WH) - We’ll ask for
consensus on the ML

LC - Is there a process for calling back a code? The RFC says when the space is
85% full, then reclaimable codes can be reclaimed. Can we have a code with an
expiry date? MT - There is an IANA process. SK - Early allocations expire.
After time, it will just go away.

4. Guidelines for packet timestamps, Tal Mizrahi (TM)
   10 minutes
   draft-mizrahi-intarea-packet-timestamps-01

Alexander Petrescu (AP) - 1st time I've seen this. I wondered if your request
for comment was for other protocols that use timestamp information. TM - It
could AP - Ones for localisation like GPS or IEEE. These are important to me.
Do you want to list them? TM - Please read the draft and send comments.

5. Identifier-locator Addressing for IPv6, Tom Herbert (Remote) (TH)
   10 minutes
   draft-herbert-intarea-ila-00

SK - Is this a one off or will a bunch follow? Will there be 20 other
documents. This will make a difference on where the work should be done. TH - I
would prefer it to be one doc if possible. I think it's simple enough. We need
an ILA specific control plane document we could use

SK - That requires scoping. One this we talked about is if you run it at
internet scale you need something else. Scoping the document will help here.
What I suggest is scope and provide deployment scenarios TH - in the examples
it's scoped to one domain. Using it instead of segment routing

Sri Gundavelli (SG )- Where do you keep the mapping table? Central or
distributed? Th - There's ILA routers and ILA nodes. The routers will have the
whole table SG - If it's applicable for mobile environments, would it scale to
100 million entries? TH - It would have to be sharded. Routers contain a
different shard. SG - there's a lot of extensions. You'll need a lot of
infrastructure for it to work. TH - I agrees. I liken it to IP. Routing
protocols are developed separate from IP LC - It's hand-wavy to say 'it's
sharded'. You need a clearer deployment statement. LC - Another point, it's not
in the draft - how do you do mobility with /64s. It seems that there's not
enough bits. TH - You have a locator plus something that's in the upper 64
bits. I need to write it up. LC - You'd have a better chance of getting
consensus if you explained it.

6. SOCKS v6, Vladimir Oltenau (Remote) (VO)
   10 minutes
   draft-olteanu-intarea-socks-6-01

Ben Schwartz (BS) - The token window system looks over engineered for the
purpose. Is it intended for something else like access limits? VO - It's just
for rejecting duplicates. Chiefly for replay attacks BS - We could fix 32-bit
as the entire space VO - The client is free to spend those tokens out order BS
- We can require them to be spent in order VO - They can be concurrent, and may
not be processed in order. BS - Thanks, that's helpful. We may be able to find
another design, but it's helpful to know why you made those decisions.

Stuart Cheshire (SC) - Minor point: on the last slide you mean if x<=1
VO - Yes, sure!

7. Architectural Considerations for Latency Critical Communications, Daniel
King (DK)
   10 minutes
   draft-xia-latency-critical-communication-00

AP - Do you make a distinction between low latency and ensuring low latency?
DK - Remote surgery is an example where latency and also ensuring packet
delivery is done. Paul Congdon (PC) - Are you just interested in latency DK -
There's ways of looking at latency and the micro aspects of latency. Setting up
and also measuring.