Re: [nscp] Notes from meeting at IETF 78

["Ning KONG" <[e-mail]>]

Hi Jelte,

I found one error.

Yao Jiankang (?): Lots of people have manual name servers so once one
of the name server configuration is modified managers have to modify
each name server themselves.

Yao Jiankang (?) should be changed to Ning Kong, thanks ;-)

Regards,
Ning


-----原始邮件----- 
From: Jelte Jansen
Sent: Wednesday, September 15, 2010 5:38 PM
To: [e-mail]
Subject: [nscp] Notes from meeting at IETF 78

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

here are the minutes from the informal meeting we had in Maastricht. Thanks 
to
Shane for making them. Any errors or omissions are entirely my fault.

Jelte



NSCP informal, unofficial, non-BAR, pre-BoF
2010-07-26 11:30

18 attendees

Jelte Jansen gives some history history:
The DCOMA closed task force produced a requirements draft.

Proposed protocols by Roy Arends (draft-arends-nscp-00) and
John Dickinson (draft-dickinson-dnsop-nameserver-control-00)
[editor's note: the first one was mainly intended to (re)start
discussion on the subject]

CNNIC proposal to put configuration into DNS zone data
(draft-kong-dns-conf-auto-sync-01)

There is a requirements draft in the DNSOP wg
(draft-ietf-dnsop-name-server-management-reqs-04)
Peter Koch: This is ready to go.

Jelte: Anyone read John Dickinson's draft?
(2 hands)
Stephen Morris: Draft got little comments or feedback.
Stephen: Work not in remit of dnsop or dnsext, but all interested
parties go to dnsop, dnsext, or both.

Lars-Johan Liman: Hassle to start new working group.
Jelte: Hope was to get new WG with very clear charter. "Intend to
finish within 18 months."
Wes Hardaker: Other option would be something like ops-area WG. To me
it sounds like a separate WG might be wise.
Jelte: In Dickinson's draft, he mentions "this should be specified
in another RFC" several times, so there may be need for multiple
documents.

James Galvin: Expecting fair amount of discussion. Less useful if you
expect a lot of discussion. Do we think there will be a lot of
discussion?
Joao Damas: Draft addresses some requirements... but language used to
express policy is a nightmare. Really overkill. Not bad to leverage
things that are already there... NETCONF is not bad, but YANG is a bit
of a nightmare. Specification is 200 pages long!
Jelte: I do expect discussion if there is real interest. Expecting
developers from the name servers to have comments about what is common
functionality.
Joao: NETCONF has capabilities, so you only have to decide on a set.
The YANG part...
Wes: If you're going to go down the road of NETCONF, it only makes
sense to define it in YANG. That is where the IETF is going... they
claim it is easy. But they also wrote 200 pages... but it's a good
document... Otherwise the IESG may say "why didn't you use the data
modeling language?"
Joao: Possibly, the IETF being what it is, that comment is very valid.
Not a lot of vendors who make DNS software have a special group to
configure the name server itself. The people who are on the operation
side of DNS know what they need from a name server, but I don't think
they are like a Cisco or a Juniper who have a user interface group. I
am concerned we will get YANG wrong.
Shane Kerr: This is the kind of thing that needs to be discussed,
maybe not here.

Stephen: When we did the NSCP draft, we wanted to come up with enough
common functionality to have a protocol. You run a risk that you can
only start & stop them!
Shane: The DCOMA output had enough functionality that a protocol maes
sense...
Stephen: It's when you get into specifics.
Jelte: One thing that makes it obvious is the discussion about views!

Wes: I think a good starting point would be to take the servers out
there and make a comparison chart of features to control & configure.
Document what ones are similar enough that aligning the data model
will be trivial.
Joao: I think the authors did do this. It's not explicit there, but
there seems to be a worthwhile set of common things. (The Dickinson
draft.)


Liman: What would be preferrable from the implementation side?
XML-based netconf or something else?
Jelte: For me as a developer it does not matter as long as it is in
libraries we can include. XML is still in NETCONF so you'd need that.


Jelte: So I do get get the feeling there is interest in this work.
Would people help?
[ some assention ]
Liman: I could help on the theoretical side, but I'm not an
implementer...
Jelte: We also need people to review and edit drafts.
Liman: From the user side it would be a great benefit for us.

Mark Andrews: This has been a long time coming. This has been on the
wish list for a decade or more. There have been attempts to do this
over the last decade.
Jelte: The first mention I found was in 2007.
Michael Graff: Started with the DNS MIB.

Jelte: One draft was putting configuration data in zones. Someone
mentioned Paul Vixie's metazones.
Hankins: Have a precursor implemented, but ...

Jelte: Was your intention to have something to remotely control DNS,
or was inlining a good idea... what was the original motivation for
the draft?
Yao Jiankang (?): Lots of people have manual name servers so once one
of the name server configuration is modified managers have to modify
each name server themselves.

[ Discussion about sending zone configuration control ... consensus to
  expand scope to include this problem? ]

Ed Lewis: Problem has 2 halves. 1. What implementors can offer. 2.
- From the operators side we have requirements. We want to administer a
constellation of servers.
James: I got the impression that these 2 problem statements are
incompatible. I think these are 2 things that need to be done - they
don't have to be combined.
Jelte: You need one to use the other. Constellation control would be
much easier if you had a way to control servers.

Peter: Lets assume a BoF was the intermediate step. The requirements
document edited by Wes is one starting point. Having a solution
measured against the requirements in that document is one choice...
probably there are other requirements to add. For us as a TLD we don't
have the same requirements as a provider.
Ed: I'm in that position. We may want the interface to go to our
billing area to insure the customer pays more, for example.

Jelte: The plan... I didn't have a real plan. We should be able to do
a real BoF at the next IETF. We can make a mailing list to discuss
this, and I can send out a draft charter. So... there are a few people
here who were not on my list of people to mail... if you want to be on
the mailing list and I did not mail you, please drop me a mail.
Peter: Talking to an AD may help, about list...
Wes: Prefer you create the list at the IETF.
Stephen: Which area, applications or operations?
[ many: operations! ]
Peter: We can provide you with details...

[ Thanks and suchlike ]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyQlDMACgkQ4nZCKsdOncUwDgCgnK1czOgPyDUQ0b3dOJf12hKp
I8kAoNQf0emZT+jD1G/rapK3dOGeMopN
=NF0H
-----END PGP SIGNATURE-----
_______________________________________________
nscp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nscp