Re: [nscp] Notes from meeting at IETF 78
"Ning KONG" <nkong@cnnic.cn> Wed, 15 September 2010 09:54 UTC
Return-Path: <nkong@cnnic.cn>
X-Original-To: nscp@core3.amsl.com
Delivered-To: nscp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984503A6B82 for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 02:54:17 -0700 (PDT)
X-Quarantine-ID: <aY0EreTNEF7E>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level:
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY0EreTNEF7E for <nscp@core3.amsl.com>; Wed, 15 Sep 2010 02:54:16 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 6916D3A6842 for <nscp@ietf.org>; Wed, 15 Sep 2010 02:54:15 -0700 (PDT)
Received: (eyou send program); Wed, 15 Sep 2010 17:54:40 +0800
Message-ID: <484544480.23765@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: nkong@cnnic.cn
Received: from unknown (HELO naptrthink) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 15 Sep 2010 17:54:40 +0800
Message-ID: <E5167C3706A34DEF967C3004B0E4D494@NAPTRTHINK>
From: Ning KONG <nkong@cnnic.cn>
To: Jelte Jansen <jelte@isc.org>, nscp@ietf.org
References: <484543593.23054@cnnic.cn>
In-Reply-To: <484543593.23054@cnnic.cn>
Date: Wed, 15 Sep 2010 17:54:26 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3002.810
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3002.810
Subject: Re: [nscp] Notes from meeting at IETF 78
X-BeenThere: nscp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Nameserver control/configuration protocol discussion list <nscp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nscp>, <mailto:nscp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nscp>
List-Post: <mailto:nscp@ietf.org>
List-Help: <mailto:nscp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nscp>, <mailto:nscp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2010 09:54:17 -0000
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: nscp@ietf.org 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 nscp@ietf.org https://www.ietf.org/mailman/listinfo/nscp
- [nscp] Notes from meeting at IETF 78 Jelte Jansen
- Re: [nscp] Notes from meeting at IETF 78 Ning KONG