* Brian Carpenter presenting the draft-ietf-intarea-flow-label-balancing-03

Suresh asking for comments / questions if the presented changes are not acceptable, noone.

Comment from Ted Lemon that there were two DISCUSSes which were going to be dropped with the new revision.

* Juan Carlos Zuniga presenting IEEE 802 OmniRAN



Sri Gundaveli: Do you see any new extensions that are needed by OmniRAN ?

Carlos: I don't. To give you more detail, if MIF believes they benefit from common behavior, this is the interface;
the role of Omniran will be to provide that. IP out of scope for OmniRAN.

Brian Haberman: talking as AD. One of the reasons I encouraged to present, there are tradeoffs for work items - 
one of them is reuse of mobility protocols at the L2 level, but then potentially new APIs on this level that 
may need to be looked at in other protocols. So I'd encourage people who are interested in that to go
and look at IEEE so we're not stepping over ourselves.



* Sheng Jiang presenting draft jiang-config-negotiation-ps

Brian Haberman: Have you presented this in the ops area at all ?

Sheng: we were a little bit late, so we did not get the timeslot in this IETF meeting

Brian: let me channel a few operators I know - dynamic configuration drives them crazy, and they want complete control, becayse they are responsible for everything to work..

Sheng: there's two cathegories of this. If you want to control everything, you want to put human resource there, and it costs. 
Those operators should have very good ability to do everything right. 
We have lots of customers from the ISPs, they want to get their network maintained by third parties - 
they want them working the way they want it. 
The important is the way the ISP wants the network to work.  
Why they want control - because the network does not work the way you want it. Thus the fear of control and autonomic. 

Brian: the point i wanted to make - something that is directly responsible in opsarea by reguirements, 
has by necessity to come from that side of IETF.

Sheng: today we just say this is something that we identified very interesting to work on it. 
Lets work out - there are hard issues.

Brian: I want to encourage you to go to ops side - you will get interesting feedback.

John ... optical networking: you stated that automatic configuration exists in the area of routing, and you want 
to extend to everything. I think it is impossibly anmbitious for a number of reasons. 
Routing protocols are very gramular and evolved over a long period to give some control - 
such protocols in any case reqire a lot of configuration in order to set the constraints.
Like previously mentioned, oeprators need a lot of control, and the self-organizing networks are antithetic to it.

On the other hand there are some new operators thinking new way and want to place some new pieces 
of equipment and make everything work - but not clear what they mean by that.

Also generic configuiratino protocol negotiation may not be sufficiently good at negotiating the specific cases. The constraints between the different 
protocols do not line up. My experience as a protocol designer is that the protocols winnnig are those that are speciifcally crafted for the problem at the time.  My message is that i think you are being too ambitious.

Sheng: we are in the beginning statge and we are going to explore the issues and we will narrow the scope if find necessary

EK: I think some of this conceptually very cool, and has applicabilty in unmanaged networks. But I would say if software devined networks are more programmatic based. 

Dave Thaler: I want to followup n the discussions on the existing protocols, what we want and... There is a discussion in opsarea - 15 minute slot.
Something about ops guidance technologies and adata model,e tc. This comes from 2-3 ways of doing logging, monitoring, etc. Benoit is starting this discussion, I encourage rolling your stuff into that discussion. It's a special case to get the feedback. Participate in that discussion.

Brian Capenter, coauthor. Three things. Bits operating the internet has become very conservative. 
I want to ignore the argument that many ops people who dont want this. 
And if the solution is that we need to manage that using human power thats not going to go anywhere. 
The second is about boiling the ocean, the goal is to produce the design that is general 
enough but can be applied to one target at a time. 
Third thing SDN centralized management - yes, I remember the SNA centralized management, 
and there is scale llimit to centralized solitions, and we should explore the more distributed solutions.

Sheng: IP was designed for distributed. ... Thank you.

* Hosnieh Rafiee presenting draft-rafiee-intarea-cga-tsig

Ted: Given that we do not have DNSX working group anymore, this is not a bad spot for the draft. 
I noticed in the use case models, there is number of use models that are covered the same way or better by the sig0 
and it may help to focus interest on the draft by eliminating the cases that are solvable by sig0 and then 
this leaves only the cases this is well suited for. 

Hosnieh: sig0 is also public/private key and this is also public/private key but with sig0 the human intervention is needed,
here we ried to reduce the human intervention and automate this process this is why we added to the TSIG - 
if the DNS servers do not support it just ignode it, this is why I added the resource record for this.

Suresh: Ted, to paraphrase you you suggest this focus on things not solved by sig0 ?

Ted: the bigger you make the list of things protocol solves - the harder it is to interest peiple - 
if you point out some sales pitches then it is going to be easier.

Zonetransfer - one of the examples where the siz0 will be easier. 
You just punch in the domain name and the there is some interaction but you do not need to copy keys around.

Hosnieh: also you need to generate the keypairs, if we say that we do it at the start of the process, i think it is just to automate this process. 

Ted: I think this is certainly an interesting idea - not particularly saying workdin group ought to adopt it, 
and i am not sure the working group should adopt it but i think it is an interesting and useful work.

Andrew Sullivan: I actually respectuflly disagree that leaving out the sie case that sig0 would solve is the right answer - 
I would like to see only the use cases that sig0 solves - it does not solve anything at large volumes - it is hard to use,etc - 
that is one of the reasons we did not see sig0 deployment. 

We could get last hop of dnssec out of the protocol. There are some that are more important to you than to me but I care about last hop.

Erik Nordmark: one thing you can do in addition to what is there is if you can add or update the things 
in the reverse zone that gives you authoriszation if that host has some cga and has that address, 
then this creates authorization to go and update that - this is something that we do not have the way to solve today.

Suresh: CGA does not say about the ownership opf the FQDN

Erik: yes for the forward tree, but for the reverse three the fact that I got this ip address 
configured gives you the right to configure the reverse tree.

Suresh: how many people read the dradt ? not enough, kets take the discussion on the mailing list.

* Guillaume from Viagenie presenting openv6

Alain Durand: You said something that got me confused. The device with dynamically loaded configuration. 
Is it something you are trying to do or you are trying to push configuration from some config server like netconf or yang ?

Guillaume: the idea is to try to set up the device with flow configuration, not with netconf.

Alain: the question is do you want to have this as a dynamic protocol where the device goes and learn from 
the rest of tne environment or you want this to be configuration driven ? 
In this region I want this protocol, in the other region I want another protocol, and then you use TR-69, etc. 
it is very different model

Guillaume: I understand there are various solutions

(coauthor of the draft) - you can use netconf or TR-69 to configure the device.

Ralf Droms: when you talk about experience in deployment and ability to handle large number of flows simultaneously - 
tell me what scale with the number of flows than with the number of cpes.

Guillaume: once the flows are setup you are ok. The technology here is what you do with the device. 
So you configure per flow which technology you can use with that flow. 

Alain: Looks complicated.

Guillaume: Think not in terms of per-flow technology, but in terms of transitioning between the technology

AY: Did you get the feedback about the complexity of this from the operators ?

Guillaume: I am presenting this for the China Telecom person who could not come, can not answer.

....

Erik Kline: you do have to rely on the new cpe that is capable of all of this

yes this is a virtual cpe

you need to have a cpe which understands how to be virtual cpe

EK: you can not deploy this without changing the existing things today

-- this applies to the device that is in tbe middle of th enetwork ,you do not apply this to the CPE. You are sending the traffic to the middle of 
the network, you decide what you do with it

EK: what is the purpose for standardization ?

-- There is going to be new protocol development

Tina: ... sent me an email asking they will like to do interoperatbility between the two vendors doing this technology. I think they allow for 
interoperability.

-------------

Ted lemon presenting on DHCP configuring applications - threat or danger

Stuart Cheshire - quick suggestion to your presentation the underlying route beyond this is mobility - 20 years ago your workstation did not move, thats what has changed.

Rhhard barnes bbn - i am surprised by the topic of this presentation because this is not what the argument started at

Ted: we have not gotten there, but this is where it start. Remember i said in th ebeginning that it is intermediat The beginning of the discussion 
was about FQDN. 

RB: There is a seciton in the document which says shoud i use DHCPv6. It says DJCPv6 makes sense if things you are configuring are extension of your local network domain. 

Ted: this is exactly the right discussion to have. What we realised in having this conversation is that although it makes sense if 
your device is screwed down to yyour desk id todes not seem to use the dhcp to configure it, but it is wrong to use the dhcpo in these 
cases - the device sodes not know that it is screwed down to the desk.

Ralph: first a public mea culpa, what you were just saying strikes me as right. There is an apparent case for the device that is screwed down to your desk. 
but the device does not have the way to know it is screwed to your desk and you can take it off your desk.

Ted: do you remenber rsh ? do you remember why it was a bad idea ? it relies on the netwrok for the means of authentication. It letts you in if your address is right. And this is the same as DHCP does. And this is not secure, and there is no way to tweak this to make it secure, and if we were to use dhcp 
for this then we need to use different way.

Ralph: security and identification 

Ted: yes

Sri: the application endpoint has the security relation with the server, does it matter ? 

Ted: if it does have, why does it need to ask DHCP about it

Sri: we use it for discovery of the server endpoint

Ralph: suppose i got 2 services that i have security relationships with - which one do i use

Sri: this is about discovering the entity that is close to you; AAA is a cloud. AD is never a single replica exposed.

Joe Hildebrand: I agree DHCP should not be used for anything application does going forward in the future. 
i do not want this agreement to make me believe about sip for existing deploument. 

Ted: SIP is a done deal - the reason i used it is a juicy example

Joe: There is a need for us ti have an interesting fconcugfgaution mechanism for user-facing services, there was a bof acouple of IETFs ago.
I think there are mechanisms we can use for apps, i think the stuff you are going to get to just because what you 


Andrew Sullivan: seems to me the line you are taking here is "either do not use dhcp ptions" or "do not use options that are IP addresses", and if it is, it does not say anywhere in the document. So you shold either say "do not use the names, they are dangerous, and then you have to explain", or then have to expla
where to use and not. It is a tradeoff - if you understand the environment you are in so that the user can be led to the wrong place - not use the dhcp option and if that leads you to "never use the dhcp option" - say that. 

It might be that the correct conclusion that ytou can never make this conclusion, and dhcp options are bad but thi sis not what the document says. 

Ted: dhcp does not provide you hte mechanismto make a decision about network context by now

Andrew: You know about where you deploy ...

Ted: no. The server operator knows what their environment is, but we can not specify how the client could trust the server, the DHCP does not provide that

Andrew This is the same argument we had for uears for opportunistic encryoption. The answer is do the necryoption and figure out later whether you are talking to the right endpoint. And same here, and FQDHN would be much better because it would worn in more envs buit this is what you need to explain

Suresh: one of the decision made between ip and domain is the draft writer, not the implementor. The direction is "do not do ip and name" and then "use ip"

Andrew: this seems completely foalse to mne, If i have control over netwroks i can also route you worpjgluy 


Suresh: IP need to be on path, dbs is off path

Ted: on my machine i have many apps, mail, browser, ... they all have means of athentication to the place i am connecting to. mitm does not affect in this case.
but if i get an address from the dhcp server then i do not have the relationship with that

Andrew: then you should not use it in the first place. 

TEd: should it read "DJCP is never appropriate for configureing applciations? "

Andrew : yes

Ted: i think that. the reason i did not say is ietf does not allow dhc working group to say no to applications, and the distinction where it is approproate and not can not be codified

Andrew: I say exactly the same ting is true about IP and fqdn is true here. it is a tradeoff. there is greater robustness available if you do fqdn and you do more than one endpoint. more than one address. I can do fqdn lookup and get different addresses depending where i dam - like i get the local dns responder depending on where


Ted: read draft-ietf-dhc-totalconf

Andrew: people actually do that and it appears to work

Ted: they do the same thing with dhcp

Andrew: yes, and you can fige more than one address, but you are saying you insist how the server is operated. If the real tradeooff is that the bullet should say "never appropriate" - say that

Dave Thaler: I agree with 60% stuff andrew said, and i have comment on 40 percent. There are 2 related but separaet issue.
1) things that will be per network vs. per user - dhhccp is per-network. If you have app info that should work in the network.
2) notion of trust = when i get the information do i get confidence that it is no tattacer. tjhere are issues that are easier/dicdiculf. 
You sometimes can do something out of band like data level encryoption, that is Andrew's ecample.

Where i disagre with andrew is where he says either disallow altogether

Only use it for the network, and use some limited trust. Sometimes you do not care about the trust but you will verify later on.
principles: per network, and you are willing to trust other mechanisms to do trust

Mikael Abrahamsson: Totally agree it is host and not applocation. e.g multiple routers in the home. it just wont work in that case.

... : Andrew did i hear you correctly you were saying about split horizon dns ? or multiple addresses and you can choose ? You are talking about something
that is specific to the network attachment that you are making but you are allowing more robustness. DNS allows the SRV, etc. If you go to IP 
then all of this has to go back to DHCP server. You can use DNS mechanisms to scale - this seems appealing and they would not make it any worse.

Joe: we did deployments using anycast for dns query, works well as long as dns does not fragment. This allows you to reach the closest dns server, and deploys nicely without any client work to be done

Ted: split horizon 

Joe: effectiveluy, but without client having to do anything specially, just by using DNS.

Ted: we see this in deciding which server to go for your media stream ,etc. If you think dhcp should be used to configure that then you got a point, but i have trouble figuring usei cases

Joe: small number of things need to be configured by the network location, e.g. whiteboard is a service provided ot the room. Very small number of things in terms of applications. This is not going to be prevalent for the new services in the future.

Ted: We are not deprecating this, we just need to have you think whether this is a best way to solve this problem. The reason i mentioned it as an example is simply to get as an example the people can understand.

Stuart Cheshire: I wanted to say Joe sounded like your argument defeated itself. You are configuring location specific white board by virtua of anycast routing and split horizon dns, and not dhcp. So you could hardcode the name of whiteboard by being whiteboard.site - so DHCP does not add anything.

Joe: to respond, the reason i think there is small number of this things, all of them have little to no user interface. The whiteboard will have just space to write. There is no place to magically tpggle the ip.


 ***

Richard: I have not heard anyone asking to remove the advice that you choose one. We talk about guidelines to give whether you choose address or name.
The reason we have is that the discussion is entirely one-sided - ip address, and here is why ip addres. The ask is to have the balanced discussion - 
here is where ip address makes sense, and benefits/drawbacks, and here is where fqdn

Ted: really big ask. i do not know when you can use fqdn

Ralph: to your point a second ago - we havent talked about using DNS in LOns, zigbee alliance talks about DNSSD for some service lookups, zigbee spec 
does not talk about ising DHCP at all, in those environemtns dhcp ois problemati because of multicast

Andrew Sullivan: you do not know whether it is appropriate to use the name, when is it apporp to ise ip ?

Ted: DNS server, NTP server either ip or dns would be fine

Andrew : Seems to me there are tradeoffs there. address has disadvantage it is hardcoded, whereas if it is a name the renumbering deos not affect it

Ted: each time you change network old config no longer available

Andrew: if the operator of the network changes the network but forgets to change the coniguration data. You can have a renumbering and then have a
clock skew. So it seems there is just a tradeoff here. That is an example of a tradeoff. There is a tiny number o fcase where option is a good idea at all
For the most of cases it is abd to use the option oeriod, and it is not in the document at all. What is needed is the section on the original cause 
of this controversy; there is the section that says you ought to use the nubmers, and reasoning to use nunmbers is not there - to me seems names can be just 
as good, and the real tradefoff what happens and why you make the choice.

Stuart: wanted to jump in i think see miscommunication. Andrew talks about stale addresses, you do not propose typing in the address in the server. 
You want to type in the name in the server, so the client gets the name resolved and sent to client.

Suresh: it is between the client resolving and server resolving

Andrew: this allows network context of the client to make this determintation, the client may be in deifferen tlocation and get a different answer.

Ted: dhcp can get a different answer depending on location

...

Dave Thaler: 

***

Mikael: in unified CPE we came up with priorities, it's all very hard over DHCP. can we do it better ? We use dhcp to bootstrap netconf, but it is a hard problem.

Ted: we've gone around on security isseus many times. I remember long time ago we were talking about how to secure dhcpv4, we came with a nice solution but it was so hard to get adoption, and people wanted to keep the use model..

Richard: when i proposed earlier the fair balance approach, you said it was a heavy lift because oyu could not come up with anything positive on fqdn side

Ted: i can not think of a way to - either the protocol does not matter, in which case we have erred on the side of simplicity - this is why dhc working group recommends ip addresses, it worked in the past so it continues to work. ..

Richard: so you do not have objectino in principle ? If we solicit people to provide text to describe theese tradeoffs - can we get at least a proposal on the table to discuss the text ?

Ted: i am afraid what's gonna happen we end up down the whole discussion of having dns know the network topology instead of dhcp. And DNS is supposed to give you the same address...

Joe: not anymore. 

Ted: i know the state of the art

Joe: hey if this is gonna keep coming up, lets at least get it written down, if someone comes along 50 years from now it is at least it is written down.

Ted: this is not a conclusion

Joe: thats what it reads. Discouragement reads to me stronger than you intended.

Richard: thats what we are talking about. You can use fQDN if you use specific reason, else ip addresses.

Ted: agreed