From mbj@tail-f.com Sat Jun 1 07:14:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B2521E804A for ; Sat, 1 Jun 2013 07:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+4HK3JyzfCq for ; Sat, 1 Jun 2013 07:14:40 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF1F21E8064 for ; Sat, 1 Jun 2013 07:14:39 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6A8E01200A32; Sat, 1 Jun 2013 16:14:37 +0200 (CEST) Date: Sat, 01 Jun 2013 16:14:36 +0200 (CEST) Message-Id: <20130601.161436.82686765.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130516160528.GB28482@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 14:14:46 -0000 Hi, Andy Bierman wrote: > Hi, > > Thanks for your review. Comments in-line. > Summary: > - all fixed except: > (c, l, s) left for Martin > (f, o, p, r, t) need WG to decide > > > Andy > > > > On Thu, May 16, 2013 at 9:05 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > Hi, > > > > here is a review of draft-ietf-netmod-system-mgmt-06. > > c) Update section 1.2 to the new format which supports * for lists and > > regenerate the tree figures. (Martin knows what I mean.) > > > > > left for Martin Fixed. > > f) Even though there are only a few config false data nodes, I would > > seriously consider to move them to separate them from the config > > true data nodes. > > > > > I think you are right. There should not have to be a couple NP containers > in the running config just to hold non-config sub-trees. If I have a > completely > default system configuration then the /system sub-tree does not need > to exist. I should still be able to read the time and platform info in any > case. > > I could move the 3 nodes if there is WG consensus to do so: > > /system-state/platform > /system-state/current-datetime > /system-state/boot-datetime I don't think this is necessary, but I won't object if this change is made. > IMO, we should even move these objects to a new module. > We want to make sure that every NETCONF server supports > the read-only /system-state objects (especially current-datetime). > Currently, a server has to implement 3 rpc statements > and a lot of config objects in order to provide this information > and advertise the YANG module. I don't think we need to move them to a new module though. IMO, our main focus is on configuration of system parameters. If the minimum compliance means only monitoring I don't think we have improved much over the current situation. > > l) The feature local-users is bound to password authentication. Can I > > not have a system with local user accounts that only permits SSH > > public key authentication? (This is actually how I run all my > > servers - we completely disable password authentication. I guess > > this is not uncommon.) Sure you can, but I think this is a deployment decision, rather than an implementation decision. I would think that all implementations that support local users also support password authentication. If this is not the case, we could make it a feature. > > m) Note that system/contact and system/location only map to SNMP if > > you are lucky due to the different character sets involved. With > > UTF8, also the size restriction does not mean the same. Perhaps > > remove the size restriction completely and add explicit text that > > implementations mapping this to SNMP objects may restrict the size > > and the allowed set of characters. (In fact DisplayString has even > > more details.) > > > > > fixed > > > > n) Should boot-datetime really be the time the NETCONF server last > > restarted? I would be more interested to know when the system last > > restarted. The NETCONF restart time (if ever needed) should really > > be part of the netconf-state data model (i.e. RFC 6022 bis). > > > > > > fixed > > > > o) The ntp objects allow to configure multiple IP addresses and each > > one can be disabled individually. Is this really needed? If so, why > > is this not needed for DNS resolvers? > > > > > > I think these extra settings were added to match how NTP is configured on > Linux. A disabled server would probably be commented out in ntp.conf, right? I agree w/ Juergen, I think we can remove the enable leaf for the individual servers. > > p) The ntp objects do not allow me to configure a port number. Should > > we not generally allow to configure complete transport layer > > endpoints? [...] > > r) The model does not allow me to configure a DNS server using a > > non-standard port number. Should we not generally allow to > > configure complete transport layer endpoints? I agree that we in general should allow complete transport config. Often a choice of the applicable transports, tcp, ssh, tls, ... since they need different parameters. However, for the DNS resolver and NTP, it would be difficult to implement; it is not possible to set in resolv.conf or ntp.conf (on linux). > > s) I think timeout and attempts are not clear enough defined. Consider > > a server that never responds. With N attempts and a timeout t, do I > > get N attempts with a timeout of t for each attempt or a timeout of > > t with N attempts? Looking at the bind header files (the man pages > > are also unclear), it seems bind does N attempts with a timeout of > > t for each attempt. > > > > The same applies to the timeout and attempts definitions for radius. How about this: leaf timeout { type uint8 { range "1..max"; } units "seconds"; default "5"; description "The amount of time the resolver will wait for a response from each remote name server before retrying the query via a different name server."; } leaf attempts { type uint8 { range "1..max"; } default "2"; description "The number of times the resolver will send a query to all its name servers before giving up and returning an error to the calling application."; } Maybe also add this to the description of the server (leaf-)list: When the resolver is invoked by a calling application, it sends the query to the first name server in this list. If no response has been received within 'timeout' seconds, the resolver continues with the next name server in the list. If no response is received from any name server in this list, the resolver continues with the first server again. When the resolver has traversed the list 'attempts' times without receiving any response, it gives up and returns an error to the calling application. It is easy to describe in pseudo-code: while (attempts-- > 0): foreach server: send request to server if got reply within timeout: return And similar for radius. > > t) The radius server list is keyed by an address. Now with Radius, > > there is the official default port number and there was a different > > port number widely used before the official got allocated. Hence, > > in practice, both are used. So I like to be able to configure > > things such that the system tries both. However, this won't work > > because the list is keyed by the address. I can't have this: > > > > > >
1.1.1.1
> > > > 1812 > > > > > > > >
1.1.1.1
> > > > 1645 > > > > > > > > Note that this also applies to the other lists keyed by simply an > > address. (We may have to introduce names to refer to the endpoints > > if we want a simple key and transport extensibility). > > > > > > I agree. Named entries are better IMO anyway. Agreed. > > I also find the separation of the udp port from the address > > strange. I can't have something like this either (if I want to add > > tcp support): > > > > > >
1.1.1.1
> > > > 1812 > > > > > > > >
1.1.1.1
> > > > 1645 > > > > > > > > For me, it would make more sense leave the address and port number > > together and to support something like this. > > > > > > > > > >
1.1.1.1
> > 1812 > > > > > >
1.1.1.1
> > 1645 > > > > > >
1.1.1.1
> > 1645 > > > > > > > > > > > I agree. Need WG to decide. I will leave for Martin to fix. Ok, I have introduced this change. I think it is correct since we try to model for different transports. /martin From andy@yumaworks.com Sat Jun 1 09:54:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C5A21F9B81 for ; Sat, 1 Jun 2013 09:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ2rexdlgNhs for ; Sat, 1 Jun 2013 09:54:30 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 32E1021F9B6F for ; Sat, 1 Jun 2013 09:54:28 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so3762738pbc.39 for ; Sat, 01 Jun 2013 09:54:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bM2TfJSauLwtl5cCK87Et6VizdHh2d7mfe4O9sa9fyM=; b=OFFgx3B46fjAh9CZ3tk9/2fG1YH7JyH6chjOxMJrMMkSQj4jYmZAcc1yjfK37arJ8C 5UWjgftGj3uxB37MhDU7Qefdc7NITtTWTEsBrAjya5S8fZn9J3YxtEFzLkf3guSbJP17 vCbGRDVEJ2pPIHVc/5vWcuTlDjGMx+3bEvximw2poDx3PU4WFN4ZKV4yU3mhIu3KXLE/ Opz2AYViQblhxID0pFuhwkIQwxi7xL0ooxkjaHV0oZclf2FeWDACCMtpalW93f2VCBlT fUp32UYrN2a4RKT5bJ0Iu7fsf3tZCx05/S7QIiyn0O5sUKTGKWgYNMo+jG/w9eszVIZf Xc1Q== MIME-Version: 1.0 X-Received: by 10.66.228.98 with SMTP id sh2mr1289070pac.80.1370105668605; Sat, 01 Jun 2013 09:54:28 -0700 (PDT) Received: by 10.70.87.103 with HTTP; Sat, 1 Jun 2013 09:54:28 -0700 (PDT) In-Reply-To: <20130601.161436.82686765.mbj@tail-f.com> References: <20130516160528.GB28482@elstar.local> <20130601.161436.82686765.mbj@tail-f.com> Date: Sat, 1 Jun 2013 09:54:28 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=047d7b15a8d1aeac0404de1a9550 X-Gm-Message-State: ALoCoQmkQCge0g7+eBeXX66VyGDoQgM/nTXgZXEwCYB7PmK3w1600qGrVapbmtE5jqTU6ONADUEp Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 16:54:31 -0000 --047d7b15a8d1aeac0404de1a9550 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 1, 2013 at 7:14 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > Hi, > > > > Thanks for your review. Comments in-line. > > Summary: > > - all fixed except: > > (c, l, s) left for Martin > > (f, o, p, r, t) need WG to decide > > > > > > Andy > > > > > > > > On Thu, May 16, 2013 at 9:05 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > Hi, > > > > > > here is a review of draft-ietf-netmod-system-mgmt-06. > > > > c) Update section 1.2 to the new format which supports * for lists and > > > regenerate the tree figures. (Martin knows what I mean.) > > > > > > > > left for Martin > > Fixed. > > > > f) Even though there are only a few config false data nodes, I would > > > seriously consider to move them to separate them from the config > > > true data nodes. > > > > > > > > > I think you are right. There should not have to be a couple NP > containers > > in the running config just to hold non-config sub-trees. If I have a > > completely > > default system configuration then the /system sub-tree does not need > > to exist. I should still be able to read the time and platform info in > any > > case. > > > > I could move the 3 nodes if there is WG consensus to do so: > > > > /system-state/platform > > /system-state/current-datetime > > /system-state/boot-datetime > > I don't think this is necessary, but I won't object if this change is > made. > > > IMO, we should even move these objects to a new module. > > We want to make sure that every NETCONF server supports > > the read-only /system-state objects (especially current-datetime). > > Currently, a server has to implement 3 rpc statements > > and a lot of config objects in order to provide this information > > and advertise the YANG module. > > I don't think we need to move them to a new module though. IMO, our > main focus is on configuration of system parameters. If the minimum > compliance means only monitoring I don't think we have improved much > over the current situation. > SNMP experience shows us that the system's notion of the current time is the most referenced object in the entire device. All timestamps and all time-deltas need to be derived from this common base object. Since YANG conformance in not granular enough to to express conformance to just the current-datetime object, it will cause problems later if a vendor has to implement the system config module in order to provide the current time. > > > l) The feature local-users is bound to password authentication. Can I > > > not have a system with local user accounts that only permits SSH > > > public key authentication? (This is actually how I run all my > > > servers - we completely disable password authentication. I guess > > > this is not uncommon.) > > Sure you can, but I think this is a deployment decision, rather than > an implementation decision. I would think that all implementations > that support local users also support password authentication. If > this is not the case, we could make it a feature. > > > > m) Note that system/contact and system/location only map to SNMP if > > > you are lucky due to the different character sets involved. With > > > UTF8, also the size restriction does not mean the same. Perhaps > > > remove the size restriction completely and add explicit text that > > > implementations mapping this to SNMP objects may restrict the size > > > and the allowed set of characters. (In fact DisplayString has even > > > more details.) > > > > > > > > fixed > > > > > > > n) Should boot-datetime really be the time the NETCONF server last > > > restarted? I would be more interested to know when the system last > > > restarted. The NETCONF restart time (if ever needed) should really > > > be part of the netconf-state data model (i.e. RFC 6022 bis). > > > > > > > > > > fixed > > > > > > > o) The ntp objects allow to configure multiple IP addresses and each > > > one can be disabled individually. Is this really needed? If so, why > > > is this not needed for DNS resolvers? > > > > > > > > > > I think these extra settings were added to match how NTP is configured on > > Linux. > > A disabled server would probably be commented out in ntp.conf, right? > > I agree w/ Juergen, I think we can remove the enable leaf for the > individual servers. > > OK with me > > > p) The ntp objects do not allow me to configure a port number. Should > > > we not generally allow to configure complete transport layer > > > endpoints? > > [...] > > > > r) The model does not allow me to configure a DNS server using a > > > non-standard port number. Should we not generally allow to > > > configure complete transport layer endpoints? > > I agree that we in general should allow complete transport config. > Often a choice of the applicable transports, tcp, ssh, tls, ... since > they need different parameters. > > However, for the DNS resolver and NTP, it would be difficult to > implement; it is not possible to set in resolv.conf or ntp.conf (on > linux). > > > > s) I think timeout and attempts are not clear enough defined. Consider > > > a server that never responds. With N attempts and a timeout t, do I > > > get N attempts with a timeout of t for each attempt or a timeout of > > > t with N attempts? Looking at the bind header files (the man pages > > > are also unclear), it seems bind does N attempts with a timeout of > > > t for each attempt. > > > > > > The same applies to the timeout and attempts definitions for radius. > > How about this: > > leaf timeout { > type uint8 { > range "1..max"; > } > units "seconds"; > default "5"; > description > "The amount of time the resolver will wait for a > response from each remote name server before > retrying the query via a different name server."; > } > > leaf attempts { > type uint8 { > range "1..max"; > } > default "2"; > description > "The number of times the resolver will send a query to > all its name servers before giving up and returning an > error to the calling application."; > } > > Maybe also add this to the description of the server (leaf-)list: > > When the resolver is invoked by a calling application, it > sends the query to the first name server in this list. > If no response has been received within 'timeout' seconds, > the resolver continues with the next name server in the > list. If no response is received from any name server > in this list, the resolver continues with the first server > again. When the resolver has traversed the list > 'attempts' times without receiving any response, it gives > up and returns an error to the calling application. > > > > It is easy to describe in pseudo-code: > > while (attempts-- > 0): > foreach server: > send request to server > if got reply within timeout: > return > > > And similar for radius. > > > > > t) The radius server list is keyed by an address. Now with Radius, > > > there is the official default port number and there was a different > > > port number widely used before the official got allocated. Hence, > > > in practice, both are used. So I like to be able to configure > > > things such that the system tries both. However, this won't work > > > because the list is keyed by the address. I can't have this: > > > > > > > > >
1.1.1.1
> > > > > > 1812 > > > > > > > > > > > >
1.1.1.1
> > > > > > 1645 > > > > > > > > > > > > Note that this also applies to the other lists keyed by simply an > > > address. (We may have to introduce names to refer to the endpoints > > > if we want a simple key and transport extensibility). > > > > > > > > > > I agree. Named entries are better IMO anyway. > > Agreed. > > > > I also find the separation of the udp port from the address > > > strange. I can't have something like this either (if I want to add > > > tcp support): > > > > > > > > >
1.1.1.1
> > > > > > 1812 > > > > > > > > > > > >
1.1.1.1
> > > > > > 1645 > > > > > > > > > > > > For me, it would make more sense leave the address and port number > > > together and to support something like this. > > > > > > > > > > > > > > >
1.1.1.1
> > > 1812 > > > > > > > > >
1.1.1.1
> > > 1645 > > > > > > > > >
1.1.1.1
> > > 1645 > > > > > > > > > > > > > > > > > I agree. Need WG to decide. I will leave for Martin to fix. > > Ok, I have introduced this change. I think it is correct since we > try to model for different transports. > > > > /martin > Andy --047d7b15a8d1aeac0404de1a9550 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 1, 2013 at 7:14 AM, Martin B= jorklund <mbj@tail-f.com> wrote:
Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> Thanks for your review. =A0Comments in-line.
> Summary:
> =A0 - all fixed except:
> =A0 =A0 =A0 =A0(c, l, s) left for Martin
> =A0 =A0 =A0 =A0(f, o, p, r, t) need WG to decide
>
>
> Andy
>
>
>
> On Thu, May 16, 2013 at 9:05 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > Hi,
> >
> > here is a review of draft-ietf-netmod-system-mgmt-06.

> > c) Update section 1.2 to the new format which supports * for list= s and
> > =A0 =A0regenerate the tree figures. (Martin knows what I mean.) > >
> >
> left for Martin

Fixed.

> > f) Even though there are only a few config false data nodes, I wo= uld
> > =A0 =A0seriously consider to move them to separate them from the = config
> > =A0 =A0true data nodes.
> >
>
>
> I think you are right. =A0There should not have to be a couple NP cont= ainers
> in the running config just to hold non-config sub-trees. =A0If I have = a
> completely
> default system configuration then the /system sub-tree does not need > to exist. =A0I should still be able to read the time and platform info= in any
> case.
>
> I could move the 3 nodes if there is WG consensus to do so:
>
> =A0 =A0/system-state/platform
> =A0 =A0/system-state/current-datetime
> =A0 =A0/system-state/boot-datetime

I don't think this is necessary, but I won't object if this change = is
made.

> IMO, we should even move these objects to a new module.
> We want to make sure that every NETCONF server supports
> the read-only /system-state objects (especially current-datetime).
> Currently, a server has to implement 3 rpc statements
> and a lot of config objects in order to provide this information
> and advertise the YANG module.

I don't think we need to move them to a new module though. =A0IMO, our<= br> main focus is on configuration of system parameters. =A0If the minimum
compliance means only monitoring I don't think we have improved much over the current situation.


<= div>SNMP experience shows us that the system's notion of the current ti= me
is the most referenced object in the entire device. =A0All tim= estamps
and all time-deltas need to be derived from this common base object.

Since YANG conformance in not granular enough to to= express
conformance to just the current-datetime object, it will= cause problems
later if a vendor has to implement the system config module in
order to provide the current time.



> > l) The feature local-users is bound to password authentication. C= an I
> > =A0 =A0not have a system with local user accounts that only permi= ts SSH
> > =A0 =A0public key authentication? (This is actually how I run all= my
> > =A0 =A0servers - we completely disable password authentication. I= guess
> > =A0 =A0this is not uncommon.)

Sure you can, but I think this is a deployment decision, rather than
an implementation decision. =A0I would think that all implementations
that support local users also support password authentication. =A0If
this is not the case, we could make it a feature.

> > m) Note that system/contact and system/location only map to SNMP = if
> > =A0 =A0you are lucky due to the different character sets involved= . With
> > =A0 =A0UTF8, also the size restriction does not mean the same. Pe= rhaps
> > =A0 =A0remove the size restriction completely and add explicit te= xt that
> > =A0 =A0implementations mapping this to SNMP objects may restrict = the size
> > =A0 =A0and the allowed set of characters. (In fact DisplayString = has even
> > =A0 =A0more details.)
> >
> >
> fixed
>
>
> > n) Should boot-datetime really be the time the NETCONF server las= t
> > =A0 =A0restarted? I would be more interested to know when the sys= tem last
> > =A0 =A0restarted. The NETCONF restart time (if ever needed) shoul= d really
> > =A0 =A0be part of the netconf-state data model (i.e. RFC 6022 bis= ).
> >
> >
>
> fixed
>
>
> > o) The ntp objects allow to configure multiple IP addresses and e= ach
> > =A0 =A0one can be disabled individually. Is this really needed? I= f so, why
> > =A0 =A0is this not needed for DNS resolvers?
> >
> >
>
> I think these extra settings were added to match how NTP is configured= on
> Linux.

A disabled server would probably be commented out in ntp.conf, right?

I agree w/ Juergen, I think we can remove the enable leaf for the
individual servers.


OK with me

= =A0
> > p) The ntp objects do not allow me to configure a port number. Sh= ould
> > =A0 =A0we not generally allow to configure complete transport lay= er
> > =A0 =A0endpoints?

[...]

> > r) The model does not allow me to configure a DNS server using a<= br> > > =A0 =A0non-standard port number. Should we not generally allow to=
> > =A0 =A0configure complete transport layer endpoints?

I agree that we in general should allow complete transport config.
Often a choice of the applicable transports, tcp, ssh, tls, ... since
they need different parameters.

However, for the DNS resolver and NTP, it would be difficult to
implement; it is not possible to set in resolv.conf or ntp.conf (on
linux).

> > s) I think timeout and attempts are not clear enough defined. Con= sider
> > =A0 =A0a server that never responds. With N attempts and a timeou= t t, do I
> > =A0 =A0get N attempts with a timeout of t for each attempt or a t= imeout of
> > =A0 =A0t with N attempts? Looking at the bind header files (the m= an pages
> > =A0 =A0are also unclear), it seems bind does N attempts with a ti= meout of
> > =A0 =A0t for each attempt.
> >
> > =A0 =A0The same applies to the timeout and attempts definitions f= or radius.

How about this:

=A0 =A0 =A0 =A0 leaf timeout {
=A0 =A0 =A0 =A0 =A0 type uint8 {
=A0 =A0 =A0 =A0 =A0 =A0 range "1..max";
=A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 units "seconds";
=A0 =A0 =A0 =A0 =A0 default "5";
=A0 =A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 "The amount of time the resolver will wait for= a
=A0 =A0 =A0 =A0 =A0 =A0 =A0response from each remote name server before
=A0 =A0 =A0 =A0 =A0 =A0 =A0retrying the query via a different name server.&= quot;;
=A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 leaf attempts {
=A0 =A0 =A0 =A0 =A0 type uint8 {
=A0 =A0 =A0 =A0 =A0 =A0 range "1..max";
=A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 default "2";
=A0 =A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 "The number of times the resolver will send a = query to
=A0 =A0 =A0 =A0 =A0 =A0 =A0all its name servers before giving up and return= ing an
=A0 =A0 =A0 =A0 =A0 =A0 =A0error to the calling application.";
=A0 =A0 =A0 =A0 }

Maybe also add this to the description of the server (leaf-)list:

=A0 =A0 =A0 =A0 =A0 =A0When the resolver is invoked by a calling applicatio= n, it
=A0 =A0 =A0 =A0 =A0 =A0sends the query to the first name server in this lis= t.
=A0 =A0 =A0 =A0 =A0 =A0If no response has been received within 'timeout= ' seconds,
=A0 =A0 =A0 =A0 =A0 =A0the resolver continues with the next name server in = the
=A0 =A0 =A0 =A0 =A0 =A0list. =A0If no response is received from any name se= rver
=A0 =A0 =A0 =A0 =A0 =A0in this list, the resolver continues with the first = server
=A0 =A0 =A0 =A0 =A0 =A0again. =A0When the resolver has traversed the list =A0 =A0 =A0 =A0 =A0 =A0'attempts' times without receiving any respo= nse, it gives
=A0 =A0 =A0 =A0 =A0 =A0up and returns an error to the calling application.<= br>


It is easy to describe in pseudo-code:

=A0 =A0while (attempts-- > 0):
=A0 =A0 =A0foreach server:
=A0 =A0 =A0 =A0send request to server
=A0 =A0 =A0 =A0if got reply within timeout:
=A0 =A0 =A0 =A0 =A0return


And similar for radius.


> > t) The radius server list is keyed by an address. Now with Radius= ,
> > =A0 =A0there is the official default port number and there was a = different
> > =A0 =A0port number widely used before the official got allocated.= Hence,
> > =A0 =A0in practice, both are used. So I like to be able to config= ure
> > =A0 =A0things such that the system tries both. However, this won&= #39;t work
> > =A0 =A0because the list is keyed by the address. I can't have= this:
> >
> > =A0 =A0<server>
> > =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0<udp>
> > =A0 =A0 =A0 =A0<authentication-port>1812</authentication= -port>
> > =A0 =A0 =A0</udp>
> > =A0 =A0</server>
> > =A0 =A0<server>
> > =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0<udp>
> > =A0 =A0 =A0 =A0<authentication-port>1645</authentication= -port>
> > =A0 =A0 =A0</udp>
> > =A0 =A0</server>
> >
> > =A0 =A0Note that this also applies to the other lists keyed by si= mply an
> > =A0 =A0address. (We may have to introduce names to refer to the e= ndpoints
> > =A0 =A0if we want a simple key and transport extensibility).
> >
> >
>
> I agree. =A0Named entries are better IMO anyway.

Agreed.

> > =A0 =A0I also find the separation of the udp port from the addres= s
> > =A0 =A0strange. =A0I can't have something like this either (i= f I want to add
> > =A0 =A0tcp support):
> >
> > =A0 =A0<server>
> > =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0<udp>
> > =A0 =A0 =A0 =A0<authentication-port>1812</authentication= -port>
> > =A0 =A0 =A0</udp>
> > =A0 =A0</server>
> > =A0 =A0<server>
> > =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0<tcp>
> > =A0 =A0 =A0 =A0<authentication-port>1645</authentication= -port>
> > =A0 =A0 =A0</tcp>
> > =A0 =A0</server>
> >
> > =A0 =A0For me, it would make more sense leave the address and por= t number
> > =A0 =A0together and to support something like this.
> >
> > =A0 =A0<server>
> > =A0 =A0 =A0<authentication>
> > =A0 =A0 =A0 =A0<udp>
> > =A0 =A0 =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0 =A0 =A0<port>1812</port>
> > =A0 =A0 =A0 =A0</udp>
> > =A0 =A0 =A0 =A0<udp>
> > =A0 =A0 =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0 =A0 =A0<port>1645</port>
> > =A0 =A0 =A0 =A0</udp>
> > =A0 =A0 =A0 =A0<tcp>
> > =A0 =A0 =A0 =A0 =A0<address>1.1.1.1</address>
> > =A0 =A0 =A0 =A0 =A0<port>1645</port>
> > =A0 =A0 =A0 =A0</tcp>
> > =A0 =A0 =A0<authentication>
> > =A0 =A0</server>
> >
> >
> I agree. Need WG to decide. I will leave for Martin to fix.

Ok, I have introduced this change. =A0I think it is correct since we
try to model for different transports.



/martin

Andy

--047d7b15a8d1aeac0404de1a9550-- From j.schoenwaelder@jacobs-university.de Sun Jun 2 00:40:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63C221F9F6B for ; Sun, 2 Jun 2013 00:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSa8EqeRGbwn for ; Sun, 2 Jun 2013 00:40:18 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0D77321F9EBB for ; Sun, 2 Jun 2013 00:40:16 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 219FF20C22; Sun, 2 Jun 2013 09:40:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OQd7TSflAI-H; Sun, 2 Jun 2013 09:40:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6EFC020C09; Sun, 2 Jun 2013 09:40:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2C687269E5CF; Sun, 2 Jun 2013 09:40:13 +0200 (CEST) Date: Sun, 2 Jun 2013 09:40:13 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130602074013.GB45699@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20130516160528.GB28482@elstar.local> <20130601.161436.82686765.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130601.161436.82686765.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 07:40:31 -0000 On Sat, Jun 01, 2013 at 04:14:36PM +0200, Martin Bjorklund wrote: > > > l) The feature local-users is bound to password authentication. Can I > > > not have a system with local user accounts that only permits SSH > > > public key authentication? (This is actually how I run all my > > > servers - we completely disable password authentication. I guess > > > this is not uncommon.) > > Sure you can, but I think this is a deployment decision, rather than > an implementation decision. I would think that all implementations > that support local users also support password authentication. If > this is not the case, we could make it a feature. OK. Lets consider l) closed - no change. > > > p) The ntp objects do not allow me to configure a port number. Should > > > we not generally allow to configure complete transport layer > > > endpoints? > > [...] > > > > r) The model does not allow me to configure a DNS server using a > > > non-standard port number. Should we not generally allow to > > > configure complete transport layer endpoints? > > I agree that we in general should allow complete transport config. > Often a choice of the applicable transports, tcp, ssh, tls, ... since > they need different parameters. > > However, for the DNS resolver and NTP, it would be difficult to > implement; it is not possible to set in resolv.conf or ntp.conf (on > linux). I think we should do be able to represent what is architecturally possible. Perhaps we need to add text or features to deal with widely deployed real-world implementations that may have restrictions. > > > s) I think timeout and attempts are not clear enough defined. Consider > > > a server that never responds. With N attempts and a timeout t, do I > > > get N attempts with a timeout of t for each attempt or a timeout of > > > t with N attempts? Looking at the bind header files (the man pages > > > are also unclear), it seems bind does N attempts with a timeout of > > > t for each attempt. > > > > > > The same applies to the timeout and attempts definitions for radius. > > How about this: > > leaf timeout { > type uint8 { > range "1..max"; > } > units "seconds"; > default "5"; > description > "The amount of time the resolver will wait for a > response from each remote name server before > retrying the query via a different name server."; > } > > leaf attempts { > type uint8 { > range "1..max"; > } > default "2"; > description > "The number of times the resolver will send a query to > all its name servers before giving up and returning an > error to the calling application."; > } > > Maybe also add this to the description of the server (leaf-)list: > > When the resolver is invoked by a calling application, it > sends the query to the first name server in this list. > If no response has been received within 'timeout' seconds, > the resolver continues with the next name server in the > list. If no response is received from any name server > in this list, the resolver continues with the first server > again. When the resolver has traversed the list > 'attempts' times without receiving any response, it gives > up and returns an error to the calling application. > > > > It is easy to describe in pseudo-code: > > while (attempts-- > 0): > foreach server: > send request to server > if got reply within timeout: > return > > > And similar for radius. Yes, this provides a clear interpretation. I am not sure, however, whether this is really what implementations generally do. Ideally, the protocols would specify this - if not, we would likely define something that the protocol specific RFCs maintained by other working groups should be defining. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Sun Jun 2 03:14:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C459521F963C for ; Sun, 2 Jun 2013 03:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0igrlNTTlcw for ; Sun, 2 Jun 2013 03:14:31 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B64E521F9C85 for ; Sun, 2 Jun 2013 03:14:29 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id DF9391200D10; Sun, 2 Jun 2013 12:14:26 +0200 (CEST) Date: Sun, 02 Jun 2013 12:14:26 +0200 (CEST) Message-Id: <20130602.121426.171184238.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130602074013.GB45699@elstar.local> References: <20130601.161436.82686765.mbj@tail-f.com> <20130602074013.GB45699@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 10:14:36 -0000 Juergen Schoenwaelder wrote: > On Sat, Jun 01, 2013 at 04:14:36PM +0200, Martin Bjorklund wrote: > > > > r) The model does not allow me to configure a DNS server using a > > > > non-standard port number. Should we not generally allow to > > > > configure complete transport layer endpoints? > > > > I agree that we in general should allow complete transport config. > > Often a choice of the applicable transports, tcp, ssh, tls, ... since > > they need different parameters. > > > > However, for the DNS resolver and NTP, it would be difficult to > > implement; it is not possible to set in resolv.conf or ntp.conf (on > > linux). > > I think we should do be able to represent what is architecturally > possible. Perhaps we need to add text or features to deal with widely > deployed real-world implementations that may have restrictions. Ok, this makes sense. We'd have something like this: +--rw ntp | +--rw enabled? boolean | +--rw server* [name] | +--rw name string | +--rw (transport) | | +--:(udp) | | +--rw udp | | +--rw address inet:host | | +--rw port? inet:port-number | +--rw association-type? enumeration | +--rw iburst? boolean | +--rw prefer? boolean +--rw dns-resolver | +--rw search* inet:domain-name | +--rw server* [name] | | +--rw name string | | +--rw (transport) | | +--:(udp) | | +--rw udp | | +--rw address inet:ip-address | | +--rw port? inet:port-number | +--rw options | +--rw timeout? uint8 | +--rw attempts? uint8 +--rw radius | +--rw server* [name] | | +--rw name string | | +--rw (transport) | | | +--:(udp) | | | +--rw udp | | | +--rw address inet:host | | | +--rw authentication-port? inet:port-number | | | +--rw shared-secret string | | +--rw authentication-type? identityref | +--rw options | +--rw timeout? uint8 | +--rw attempts? uint8 Should we have features on ntp/server/port and dns/server/port? leaf port { if-feature ntp-udp-port; > > > > > s) I think timeout and attempts are not clear enough defined. Consider > > > > a server that never responds. With N attempts and a timeout t, do I > > > > get N attempts with a timeout of t for each attempt or a timeout of > > > > t with N attempts? Looking at the bind header files (the man pages > > > > are also unclear), it seems bind does N attempts with a timeout of > > > > t for each attempt. > > > > > > > > The same applies to the timeout and attempts definitions for radius. > > > > How about this: > > > > leaf timeout { > > type uint8 { > > range "1..max"; > > } > > units "seconds"; > > default "5"; > > description > > "The amount of time the resolver will wait for a > > response from each remote name server before > > retrying the query via a different name server."; > > } > > > > leaf attempts { > > type uint8 { > > range "1..max"; > > } > > default "2"; > > description > > "The number of times the resolver will send a query to > > all its name servers before giving up and returning an > > error to the calling application."; > > } > > > > Maybe also add this to the description of the server (leaf-)list: > > > > When the resolver is invoked by a calling application, it > > sends the query to the first name server in this list. > > If no response has been received within 'timeout' seconds, > > the resolver continues with the next name server in the > > list. If no response is received from any name server > > in this list, the resolver continues with the first server > > again. When the resolver has traversed the list > > 'attempts' times without receiving any response, it gives > > up and returns an error to the calling application. > > > > > > > > It is easy to describe in pseudo-code: > > > > while (attempts-- > 0): > > foreach server: > > send request to server > > if got reply within timeout: > > return > > > > > > And similar for radius. > > Yes, this provides a clear interpretation. I am not sure, however, > whether this is really what implementations generally do. I checked glibc's resolver. > Ideally, the > protocols would specify this - if not, we would likely define > something that the protocol specific RFCs maintained by other working > groups should be defining. So ... are you suggesting we should remove even these options? /martin From j.schoenwaelder@jacobs-university.de Tue Jun 4 01:11:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1BE21F9811 for ; Tue, 4 Jun 2013 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ334JsWkADS for ; Tue, 4 Jun 2013 01:10:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07E21F9AD9 for ; Tue, 4 Jun 2013 00:12:11 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03F7D20D85; Tue, 4 Jun 2013 09:12:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fs5S1na3zY4Q; Tue, 4 Jun 2013 09:12:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47A9020D74; Tue, 4 Jun 2013 09:12:09 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 19EF626A915C; Tue, 4 Jun 2013 09:12:08 +0200 (CEST) Date: Tue, 4 Jun 2013 09:12:08 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130604071208.GA78573@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org References: <20130601.161436.82686765.mbj@tail-f.com> <20130602074013.GB45699@elstar.local> <20130602.121426.171184238.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130602.121426.171184238.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 08:11:06 -0000 On Sun, Jun 02, 2013 at 12:14:26PM +0200, Martin Bjorklund wrote: > > Should we have features on ntp/server/port and dns/server/port? > > leaf port { > if-feature ntp-udp-port; > Introducing these features probably makes sense for NTP and DNS. I checked a few sources and it is interesting that the port number sometimes not even has a #define and sits literally in a htons(). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Tue Jun 4 01:38:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443B721F9B0F for ; Tue, 4 Jun 2013 01:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V51jfBWZvhuq for ; Tue, 4 Jun 2013 01:38:20 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id E5AEC21F9B13 for ; Tue, 4 Jun 2013 00:34:10 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 19CE31200174; Tue, 4 Jun 2013 09:34:09 +0200 (CEST) Date: Tue, 04 Jun 2013 09:34:08 +0200 (CEST) Message-Id: <20130604.093408.466360705.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130604071208.GA78573@elstar.local> References: <20130602074013.GB45699@elstar.local> <20130602.121426.171184238.mbj@tail-f.com> <20130604071208.GA78573@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] comments on draft-ietf-netmod-system-mgmt-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 08:38:36 -0000 Juergen Schoenwaelder wrote: > On Sun, Jun 02, 2013 at 12:14:26PM +0200, Martin Bjorklund wrote: > > > > Should we have features on ntp/server/port and dns/server/port? > > > > leaf port { > > if-feature ntp-udp-port; > > > > Introducing these features probably makes sense for NTP and DNS. Ok. Yes, I think this results in a pretty good model. It supports multiple transports and configuration of ports, while at the same time accepting the fact that implementations have hard coded ports... Something like this: feature ntp-udp-port { description "Indicates that the device supports the configuration of the UDP port for NTP servers. This is a 'feature' since many implementations do not support any other port than the default port."; } feature dns-udp-port { description "Indicates that the device supports the configuration of the UDP port for DNS servers. This is a 'feature' since many implementations do not support any other port than the default port."; } /martin From iesg-secretary@ietf.org Thu Jun 6 08:47:31 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3321821F99C7; Thu, 6 Jun 2013 08:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbicredbsGFR; Thu, 6 Jun 2013 08:47:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1417821F99D5; Thu, 6 Jun 2013 08:47:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130606154729.23872.86903.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2013 08:47:29 -0700 Cc: netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'Common YANG Data Types' to Proposed Standard (draft-ietf-netmod-rfc6021-bis-02.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 15:47:31 -0000 The IESG has approved the following document: - 'Common YANG Data Types' (draft-ietf-netmod-rfc6021-bis-02.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis/ Technical Summary (set of documents) draft-ietf-netmod-rfc6021-bis-00 This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. draft-ietf-netmod-iana-if-type-04 This document defines the initial version of the iana-if-type and iana-afn-safi YANG modules, for interface type definitions, and Address Family Numbers (AFN) and Subsequent Address Family Identifiers (SAFI), respectively. draft-ietf-netmod-interfaces-cfg-09 This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. draft-ietf-netmod-ip-cfg-09 This document defines a YANG data model for management of IP implementations. Working Group Summary The normal WG process was followed and the documents reflect WG consensus with nothing special worth mentioning. Document Quality This set of documents received extensive review within the working group and ample time was spent to review and reconsider all design choices. The working group also reached out to the IP directorate and received additional review from Dave Thaler. From andy@yumaworks.com Fri Jun 7 09:45:28 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DFC21F95EF for ; Fri, 7 Jun 2013 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7h42CvMJ5buY for ; Fri, 7 Jun 2013 09:45:28 -0700 (PDT) Received: from mail-pb0-x22f.google.com (mail-pb0-x22f.google.com [IPv6:2607:f8b0:400e:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0F17621F848A for ; Fri, 7 Jun 2013 09:45:27 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rr13so2226730pbb.6 for ; Fri, 07 Jun 2013 09:45:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=q1LoNAWEmtpQp0kdv2OwfqExz/FPKo+PGISsC/W9eW4=; b=Ysx2ymgE8nSABy/vgGRwQw7EcAFz9DIzjFopG5Br0731P6csh4JJ6m3PkXdZpcFFd1 Mfv2tq1tplFgjsC570EFgHmoIY1O6WkVmTOiEMhl7g4MXmX9kT+Q2ZpkqBKCRw1A4XBQ nsN4aY7cPE7SetMo5cR14EGW4xcqJIhGxzyB98E5qCiILKsvdsG1GFoiNLahYssdNCY1 OsTc9Q/tFzu1GgxNGNf3Hf07/98bEsbPf703Y8/j+EMZ8HkUjObM+hFChqjCLit4Yg+e +MAZDqC05PQxpyYxlXm2AE1G4x6MFtGeye1p+ooMBHCpikl2FA+wjFAjZYBfLXtVfb9o 9pLA== MIME-Version: 1.0 X-Received: by 10.68.229.138 with SMTP id sq10mr44183574pbc.38.1370623527565; Fri, 07 Jun 2013 09:45:27 -0700 (PDT) Received: by 10.70.87.103 with HTTP; Fri, 7 Jun 2013 09:45:27 -0700 (PDT) Date: Fri, 7 Jun 2013 09:45:27 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=047d7b33985b7b521304de932810 X-Gm-Message-State: ALoCoQkPwtDRN1UoDplJb7TeEyorJZuH4lruWMlwevKq8IGcwQttdaG7xZkFPoD1I1RUarh+H5j9 Subject: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:45:28 -0000 --047d7b33985b7b521304de932810 Content-Type: text/plain; charset=ISO-8859-1 Hi, The state information within this module contains the system time of day. Since the scope of the RFC is common system management, no longer just system configuration, the RFC should be usable for monitoring. It is quite possible that small NETCONF devices will not have the ability to set the hostname or provide time-of-day management or system restart commands. Yet it will still need to report its notion of current time if an EMS is going to correlate its data and notifications wrt/ timestamps and other devices. There are limited conformance mechanisms in YANG to separate the system-state objects. The WG needs to choose between: 1) do nothing; leave draft as-is 2 add a YANG feature (e.b. system-config) that covers all operations and config objects 3) move the system-state objects to a new module in the same RFC I would like to resolve this issue. Am I the only one who is concerned that NETCONF devices will not support the current-datetime object because module conformance is too steep? Moving the objects around within the same module is a different issue. That is fine with me if the WG chooses (1). It may be easier on clients to retrieve just the non-config objects that way. Andy --047d7b33985b7b521304de932810 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

The state information within this module contains th= e system time of day.
Since the scope of the RFC is common system= management,
no longer just system configuration, the RFC should = be usable for
monitoring. =A0It is quite possible that small NETCONF devices
will not have the ability to set the hostname or provide time-of-day
management or system restart commands. =A0Yet it will still need
to report its notion of current time if an EMS is going to correlate
its data and notifications wrt/ timestamps and other devices.

There are limited conformance mechanisms in YANG to se= parate the system-state
objects. =A0The WG needs to choose between:

= =A0 1) do nothing; leave draft as-is
=A0 2 add a YANG feature (e.= b. system-config) that covers all operations
=A0 =A0 =A0 and conf= ig objects
=A0 3) move the system-state objects to a new module in the same RFC

I would like to resolve this issue.
Am I = the only one who is concerned that NETCONF devices
will not suppo= rt the current-datetime object because module
conformance is too steep?

Moving the objects = around within the same module is a different issue.
That is fine = with me if the WG chooses (1). =A0It may be easier on
clients to = retrieve just the non-config objects that way.


Andy


=

--047d7b33985b7b521304de932810-- From Internet-Drafts@ietf.org Fri Jun 7 13:46:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691E421F995E; Fri, 7 Jun 2013 13:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U42WrMY2PhIG; Fri, 7 Jun 2013 13:46:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 021B021F9923; Fri, 7 Jun 2013 13:46:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130607204604.1235.76413.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2013 13:46:04 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D ACTION:draft-ietf-netmod-rfc6021-bis-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:46:05 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Common YANG Data Types Author(s) : J. Schoenwaelder Filename : draft-ietf-netmod-rfc6021-bis Pages : 36 Date : June 7, 2013 This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netmod-rfc6021-bis-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-netmod-rfc6021-bis"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-06-07134604.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Fri Jun 7 13:48:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696AA21F93D2; Fri, 7 Jun 2013 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R1QygugGK4i; Fri, 7 Jun 2013 13:48:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 835A821F99A0; Fri, 7 Jun 2013 13:48:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130607204818.15053.33886.idtracker@ietfa.amsl.com> Date: Fri, 07 Jun 2013 13:48:18 -0700 Cc: netmod chair , netmod mailing list , RFC Editor Subject: [netmod] CORRECTED Protocol Action: 'Common YANG Data Types' to Proposed Standard (draft-ietf-netmod-rfc6021-bis-03.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 20:48:19 -0000 The IESG has approved the following document: - 'Common YANG Data Types' (draft-ietf-netmod-rfc6021-bis-03.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6021-bis/ Technical Summary (set of documents) draft-ietf-netmod-rfc6021-bis-00 This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. draft-ietf-netmod-iana-if-type-04 This document defines the initial version of the iana-if-type and iana-afn-safi YANG modules, for interface type definitions, and Address Family Numbers (AFN) and Subsequent Address Family Identifiers (SAFI), respectively. draft-ietf-netmod-interfaces-cfg-09 This document defines a YANG data model for the management of network interfaces. It is expected that interface type specific data models augment the generic interfaces data model defined in this document. draft-ietf-netmod-ip-cfg-09 This document defines a YANG data model for management of IP implementations. Working Group Summary The normal WG process was followed and the documents reflect WG consensus with nothing special worth mentioning. Document Quality This set of documents received extensive review within the working group and ample time was spent to review and reconsider all design choices. The working group also reached out to the IP directorate and received additional review from Dave Thaler. From j.schoenwaelder@jacobs-university.de Mon Jun 10 02:26:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F312E21F8B90 for ; Mon, 10 Jun 2013 02:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.76 X-Spam-Level: X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtquMJ5y+vRL for ; Mon, 10 Jun 2013 02:26:12 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9B021F84E7 for ; Mon, 10 Jun 2013 02:26:07 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6451C20BDA; Mon, 10 Jun 2013 11:26:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qNV9yg4RNTOL; Mon, 10 Jun 2013 11:26:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89F9F20BD5; Mon, 10 Jun 2013 11:26:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B8E2826C0484; Mon, 10 Jun 2013 11:26:01 +0200 (CEST) Date: Mon, 10 Jun 2013 11:26:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20130610092601.GA6515@elstar.local> Mail-Followup-To: Andy Bierman , netmod@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 09:26:27 -0000 On Fri, Jun 07, 2013 at 09:45:27AM -0700, Andy Bierman wrote: > Hi, > > The state information within this module contains the system time of day. > Since the scope of the RFC is common system management, > no longer just system configuration, the RFC should be usable for > monitoring. It is quite possible that small NETCONF devices > will not have the ability to set the hostname or provide time-of-day > management or system restart commands. Yet it will still need > to report its notion of current time if an EMS is going to correlate > its data and notifications wrt/ timestamps and other devices. > > There are limited conformance mechanisms in YANG to separate the > system-state > objects. The WG needs to choose between: > > 1) do nothing; leave draft as-is > 2 add a YANG feature (e.b. system-config) that covers all operations > and config objects > 3) move the system-state objects to a new module in the same RFC > > I would like to resolve this issue. > Am I the only one who is concerned that NETCONF devices > will not support the current-datetime object because module > conformance is too steep? > > Moving the objects around within the same module is a different issue. > That is fine with me if the WG chooses (1). It may be easier on > clients to retrieve just the non-config objects that way. > Can people please comment on this so that we can move forward? As technical contributor, I am fine with 1) - I think even the small Contiki devices we experimented with would be fine supporting a reboot operation etc. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Mon Jun 10 06:01:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7656721F8B07 for ; Mon, 10 Jun 2013 06:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8IsMKKLu3yh for ; Mon, 10 Jun 2013 06:01:46 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8284D21F867B for ; Mon, 10 Jun 2013 06:01:43 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 6BBAB1200D2F; Mon, 10 Jun 2013 15:01:38 +0200 (CEST) Date: Mon, 10 Jun 2013 15:01:38 +0200 (CEST) Message-Id: <20130610.150138.1146557832101720629.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130610092601.GA6515@elstar.local> References: <20130610092601.GA6515@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 13:01:52 -0000 Juergen Schoenwaelder wrote: > On Fri, Jun 07, 2013 at 09:45:27AM -0700, Andy Bierman wrote: > > Hi, > > > > The state information within this module contains the system time of day. > > Since the scope of the RFC is common system management, > > no longer just system configuration, the RFC should be usable for > > monitoring. It is quite possible that small NETCONF devices > > will not have the ability to set the hostname or provide time-of-day > > management or system restart commands. Yet it will still need > > to report its notion of current time if an EMS is going to correlate > > its data and notifications wrt/ timestamps and other devices. > > > > There are limited conformance mechanisms in YANG to separate the > > system-state > > objects. The WG needs to choose between: > > > > 1) do nothing; leave draft as-is > > 2 add a YANG feature (e.b. system-config) that covers all operations > > and config objects > > 3) move the system-state objects to a new module in the same RFC > > > > I would like to resolve this issue. > > Am I the only one who is concerned that NETCONF devices > > will not support the current-datetime object because module > > conformance is too steep? > > > > Moving the objects around within the same module is a different issue. > > That is fine with me if the WG chooses (1). It may be easier on > > clients to retrieve just the non-config objects that way. > > > > Can people please comment on this so that we can move forward? > > As technical contributor, I am fine with 1) So am I. > I think even the small > Contiki devices we experimented with would be fine supporting a reboot > operation etc. The mandatory-to-implement nodes are (all if-feature nodes removed): module: ietf-system +--rw system +--rw contact? string +--rw hostname? inet:domain-name +--rw location? string +--ro platform | +--ro os-name? string | +--ro os-release? string | +--ro os-version? string | +--ro machine? string +--rw clock | +--ro current-datetime? yang:date-and-time | +--ro boot-datetime? yang:date-and-time | +--rw (timezone)? | +--:(timezone-utc-offset) | +--rw timezone-utc-offset? int16 +--rw dns-resolver +--rw search* inet:domain-name +--rw server* [name] | +--rw name string | +--rw (transport) | +--:(udp) | +--rw udp | +--rw address inet:ip-address +--rw options +--rw timeout? uint8 +--rw attempts? uint8 rpcs: +---x set-current-datetime | +--ro input | +--ro current-datetime yang:date-and-time +---x system-restart +---x system-shutdown /martin From lhotka@nic.cz Mon Jun 10 07:38:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30F821F8F6E for ; Mon, 10 Jun 2013 07:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnakuy5hu-34 for ; Mon, 10 Jun 2013 07:38:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE7621F8F61 for ; Mon, 10 Jun 2013 07:38:00 -0700 (PDT) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 590F213FDF0; Mon, 10 Jun 2013 16:37:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1370875079; bh=pAH6gq1JQGJxLulmHLn3ojIEkuCHmyPIjr9XbpjE7ZY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZO3C6mYSSEQ+9RlWmuZYna1Y/0vqClsuKzoZOlCsHW9QPCqQKVhFG380atfcGWTvI prbqnLx3bddyEUe2hzVKrS3PU4g6OLP51lvCUE87wAiqL4cEg5K4F+LUXgdqn0/0jI vGHj5A75hG/FRqjGPpqgAaTA4OXVIn9NrH+rHGoU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Jun 2013 16:37:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 14:38:00 -0000 On Jun 7, 2013, at 6:45 PM, Andy Bierman wrote: > Hi, >=20 > The state information within this module contains the system time of = day. > Since the scope of the RFC is common system management, > no longer just system configuration, the RFC should be usable for > monitoring. It is quite possible that small NETCONF devices > will not have the ability to set the hostname or provide time-of-day > management or system restart commands. Yet it will still need > to report its notion of current time if an EMS is going to correlate > its data and notifications wrt/ timestamps and other devices. >=20 > There are limited conformance mechanisms in YANG to separate the = system-state > objects. The WG needs to choose between: >=20 > 1) do nothing; leave draft as-is > 2 add a YANG feature (e.b. system-config) that covers all operations > and config objects > 3) move the system-state objects to a new module in the same RFC Why cannot the "system-state" subtree be in the same module, as it is in = interfaces-11? I believe a few other nodes also deserve to be both in = configuration and state. For instance, the DNS resolver options can be = obtained from DHCP, so the client should be able to learn them form = operational state data. Lada >=20 > I would like to resolve this issue. > Am I the only one who is concerned that NETCONF devices > will not support the current-datetime object because module > conformance is too steep? >=20 > Moving the objects around within the same module is a different issue. > That is fine with me if the WG chooses (1). It may be easier on > clients to retrieve just the non-config objects that way. >=20 >=20 > Andy >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jun 10 09:33:42 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0288921F88AC for ; Mon, 10 Jun 2013 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Td-mnucFEn for ; Mon, 10 Jun 2013 09:33:41 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5176821F86D3 for ; Mon, 10 Jun 2013 09:33:41 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id kx10so2291354pab.41 for ; Mon, 10 Jun 2013 09:33:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=MlWIJemuLFvtQyBeHidTWr93b4GeX2+FolQU/R8GnQs=; b=mZI4pQVN+mcMjJXZn5D3zTWSl0zei3aubiibNQ9SBHkW4Ct6hR4j55ixt9pRHeY4PR yDm2OKPIYIKehak7eMcmsWYf+Fg5bqr23DHXyae+sLy3LKeEhQGLA0pRGtrBdLmrtN66 K1pmlt0wtl66mdtdlOBIr366v/t1rudx96IUQy+AK8QRymIqy9Qldb1yO1B7ooA83k5J DjQVhh3pPtiwLiyQfK901EkLUXH1zleHbbyvbNEsBa4VR4T+Xci1dKwB/h/hEzUPoTkE L/iqwa6BCC/rUHAVbBZpnjvDFyIPLR4ol5z3itTTTTB4F+nbh9AM5DXhqPSIs2hRf4q3 wDCQ== MIME-Version: 1.0 X-Received: by 10.68.170.37 with SMTP id aj5mr10654264pbc.77.1370882020866; Mon, 10 Jun 2013 09:33:40 -0700 (PDT) Received: by 10.70.87.103 with HTTP; Mon, 10 Jun 2013 09:33:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 10 Jun 2013 09:33:40 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7ba970a6e30f6d04decf5780 X-Gm-Message-State: ALoCoQknJo8uYPSyMvnS9KlNMm5eD/JoW2MycZqmImQoiQFu3TQtiMwM62Ha2yanacqajjuY+ad6 Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 16:33:42 -0000 --047d7ba970a6e30f6d04decf5780 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 7:37 AM, Ladislav Lhotka wrote: > > On Jun 7, 2013, at 6:45 PM, Andy Bierman wrote: > > > Hi, > > > > The state information within this module contains the system time of day. > > Since the scope of the RFC is common system management, > > no longer just system configuration, the RFC should be usable for > > monitoring. It is quite possible that small NETCONF devices > > will not have the ability to set the hostname or provide time-of-day > > management or system restart commands. Yet it will still need > > to report its notion of current time if an EMS is going to correlate > > its data and notifications wrt/ timestamps and other devices. > > > > There are limited conformance mechanisms in YANG to separate the > system-state > > objects. The WG needs to choose between: > > > > 1) do nothing; leave draft as-is > > 2 add a YANG feature (e.b. system-config) that covers all operations > > and config objects > > 3) move the system-state objects to a new module in the same RFC > > Why cannot the "system-state" subtree be in the same module, as it is in > interfaces-11? I believe a few other nodes also deserve to be both in > configuration and state. For instance, the DNS resolver options can be > obtained from DHCP, so the client should be able to learn them form > operational state data. > > I did not list that option because it has no impact on module conformance. I am OK with option (1). The subtree filter needed to retrieve just a few non-config nodes is not a burden on client developers, so moving them to a new subtree in the same module is not really needed. I think the read-only objects would get implemented by vendors more quickly if they were separate. There were various proposals to indicate the DHCP vs. config property, and they were are rejected. I don't like the solution of duplicating the config parameters in another tree to indicate they are in fact the values in use. IMO, this is meta-data and duplicating the data is the wrong solution. A new or operation is the right approach. Lada > Andy > > > > > I would like to resolve this issue. > > Am I the only one who is concerned that NETCONF devices > > will not support the current-datetime object because module > > conformance is too steep? > > > > Moving the objects around within the same module is a different issue. > > That is fine with me if the WG chooses (1). It may be easier on > > clients to retrieve just the non-config objects that way. > > > > > > Andy > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7ba970a6e30f6d04decf5780 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jun 10, 2013 at 7:37 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

> Hi,
>
> The state information within this module contains the system time of d= ay.
> Since the scope of the RFC is common system management,
> no longer just system configuration, the RFC should be usable for
> monitoring. =A0It is quite possible that small NETCONF devices
> will not have the ability to set the hostname or provide time-of-day > management or system restart commands. =A0Yet it will still need
> to report its notion of current time if an EMS is going to correlate > its data and notifications wrt/ timestamps and other devices.
>
> There are limited conformance mechanisms in YANG to separate the syste= m-state
> objects. =A0The WG needs to choose between:
>
> =A0 1) do nothing; leave draft as-is
> =A0 2 add a YANG feature (e.b. system-config) that covers all operatio= ns
> =A0 =A0 =A0 and config objects
> =A0 3) move the system-state objects to a new module in the same RFC
Why cannot the "system-state" subtree be in the same module, as i= t is in interfaces-11? I believe a few other nodes also deserve to be both = in configuration and state. For instance, the DNS resolver options can be o= btained from DHCP, so the client should be able to learn them form operatio= nal state data.



I did not list that opt= ion because it has no impact on module conformance.

I am OK with option (1). =A0The subtree filter needed to retrieve just a<= /div>
few non-config nodes is not a burden on client developers, so moving t= hem
to a new subtree in the same module is not really needed. =A0= I think
the read-only objects would get implemented by vendors mo= re quickly
if they were separate.

There were various pro= posals to indicate the DHCP vs. config property,
and they were ar= e rejected. =A0I don't like the solution of duplicating
the c= onfig parameters in another tree to indicate they are in fact
the values in use. =A0IMO, this is meta-data and duplicating the data<= /div>
is the wrong solution. A new <get2> or <get-operational&= gt; operation
is the right approach.

Lada

Andy
=A0

>
> I would like to resolve this issue.
> Am I the only one who is concerned that NETCONF devices
> will not support the current-datetime object because module
> conformance is too steep?
>
> Moving the objects around within the same module is a different issue.=
> That is fine with me if the WG chooses (1). =A0It may be easier on
> clients to retrieve just the non-config objects that way.
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--047d7ba970a6e30f6d04decf5780-- From lhotka@nic.cz Mon Jun 10 11:13:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E275911E80A3 for ; Mon, 10 Jun 2013 11:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZe4tZxTJ++A for ; Mon, 10 Jun 2013 11:13:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 00CA011E80A2 for ; Mon, 10 Jun 2013 11:13:13 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id AB50E13FDF0; Mon, 10 Jun 2013 20:13:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1370887992; bh=8DkRayEQVknT5xT4RCjLrUVBbEYBFIe8ivYUUkKzxU8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=IhKrTEa926v0EzdD6wrd1v7CJVs0cFTAK9cLeLEC5qXKFyLyQiD+/IerqL/XWcT1c Hn5oBcB98Nuno9hs4cHtrT1jCGYt5yxKvEiU1t37W5tz/Vr0w05jx7N/88vt2UAquh hmRzifDmblANNbXQsMOjQzCLAvAe08PMG0alZYN4= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 10 Jun 2013 20:13:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B4F387B-1AA9-4FB2-B996-72B0BA5E5F68@nic.cz> References: To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 18:13:15 -0000 On Jun 10, 2013, at 6:33 PM, Andy Bierman wrote: >=20 >=20 > On Mon, Jun 10, 2013 at 7:37 AM, Ladislav Lhotka = wrote: >=20 > On Jun 7, 2013, at 6:45 PM, Andy Bierman wrote: >=20 > > Hi, > > > > The state information within this module contains the system time of = day. > > Since the scope of the RFC is common system management, > > no longer just system configuration, the RFC should be usable for > > monitoring. It is quite possible that small NETCONF devices > > will not have the ability to set the hostname or provide time-of-day > > management or system restart commands. Yet it will still need > > to report its notion of current time if an EMS is going to correlate > > its data and notifications wrt/ timestamps and other devices. > > > > There are limited conformance mechanisms in YANG to separate the = system-state > > objects. The WG needs to choose between: > > > > 1) do nothing; leave draft as-is > > 2 add a YANG feature (e.b. system-config) that covers all = operations > > and config objects > > 3) move the system-state objects to a new module in the same RFC >=20 > Why cannot the "system-state" subtree be in the same module, as it is = in interfaces-11? I believe a few other nodes also deserve to be both in = configuration and state. For instance, the DNS resolver options can be = obtained from DHCP, so the client should be able to learn them form = operational state data. >=20 >=20 >=20 > I did not list that option because it has no impact on module = conformance. >=20 > I am OK with option (1). The subtree filter needed to retrieve just a > few non-config nodes is not a burden on client developers, so moving = them > to a new subtree in the same module is not really needed. I think > the read-only objects would get implemented by vendors more quickly > if they were separate. >=20 > There were various proposals to indicate the DHCP vs. config property, > and they were are rejected. I don't like the solution of duplicating > the config parameters in another tree to indicate they are in fact > the values in use. IMO, this is meta-data and duplicating the data Mechanisms external to NETCONF cannot be expected to update anything in = a NETCONF datastore, and the NETCONF server - if it is notified about a = change - may not be able to do it either, e.g. because of a lock on the = datastore.=20 > is the wrong solution. A new or operation > is the right approach. I don't think we've got anywhere close to a consensus wrt to = get-operational. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Mon Jun 17 05:50:18 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DBA21F9B77 for ; Mon, 17 Jun 2013 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSSkFiWHmXn6 for ; Mon, 17 Jun 2013 05:50:14 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id BAFCE21F9B81 for ; Mon, 17 Jun 2013 05:50:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 9014B540165 for ; Mon, 17 Jun 2013 14:50:05 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBjj+cfO36B1 for ; Mon, 17 Jun 2013 14:49:51 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 6485C54015B for ; Mon, 17 Jun 2013 14:49:46 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130529235204.GA58491@elstar.local> References: <20130522.075021.510632113.mbj@tail-f.com> <20130522.083817.336589153.mbj@tail-f.com> <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local> <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net> <5AB07445-A5EA-4105-B5CE-85B14D3BF397@nic.cz> <20130529235204.GA58491@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Mon, 17 Jun 2013 14:49:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 12:50:18 -0000 Hi, the discussion below doesn't seem to have reached any conclusion. But whatever the answer to Juergen's question might be, I think we should consider the "type" leaf again, because: 1. The "type" leaf is useful in YANG for restricting some configuration parameters for use only with a certain interface type. The existing values in the "iana-if-type" enumeration, such as "ethernetCsmacd" or "tunnel", don't seem very effective in this respect. What we need is the type information that's often encoded in (platform-specific) interface names, for example TenGigabitEthernet0/1, gr-0/0/0 or ppp0. 2. We actually need a *hierarchy* of interface types, whereas "iana-if-type" is flat. For instance, take the Ethernet example in Appendix A: The "when" condition when "if:type = 'ethernetCsmacd'"; causes the generic Ethernet parameters to apply only to this particular type, but not to any specialized Ethernet type, say "ieee-802.11bgn" (if this was ever registered by IANA). 3. The set of permitted types should be easily extensible, without the need to go to IANA first. In my opinion, YANG identity is a much better choice for the type of "type" because it satisfies all three requirements. No extra registry is needed for identities because they will be registered indirectly through the module where they are defined. It is possible that a simple hierarchy of interface types won't be enough for representing the variety of real-world interfaces with all their properties and features. But then additional (type-specific) parameters could be introduced and used along with "type" for conditional augments. Lada Juergen Schoenwaelder writes: > On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy Management) wrote: >> Martin asked that I provide my $0.02 on this draft as we've created >> an implementation against the -08 version. So here we go... >> >> In general I like having the interface-state separate from the >> interface configuration, it provides an easy way for a user to see >> what devices are currently in the system and are available for >> configuration. In our -08 implementation we created a >> /interfaces/physical-interfaces table that would be pre-populated by >> the factory with the interfaces that are available for that >> particular product. Note that our product is not customer >> expandable, so the interfaces that ship with the unit are the only >> ones that the customer can configure (ignoring logical interfaces). >> By having this config false list of interfaces we could achieve the >> same thing in a more standard way. > > This is _very_ welcome feedback. Implementation experience is always > very welcome - if others implement things as well, please consider to > share your experiences. This helps a lot. > >> We have many proprietary interface types (primarily different types >> of in-house radio interfaces) that do not fit into the categories >> defined by iana-if-type. Sure you could use the argument "well then >> get them added via iana". But that will never happen. > > I have to ask this so I do better understand. Why will this never > happen? > > - Is the procedure to register your interface type too complex? > > - Is the interface type kind of secret and hence you do not want to > have it registered somewhere? > > - Is it that developers simply would not know how to register a new > interface type and choose a random value anyway? > > - Something else? > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Mon Jun 17 07:41:41 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B649621F9B35 for ; Mon, 17 Jun 2013 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKhnB94i3xxs for ; Mon, 17 Jun 2013 07:41:37 -0700 (PDT) Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id BA63921F9AD9 for ; Mon, 17 Jun 2013 07:41:37 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so2872047pdj.28 for ; Mon, 17 Jun 2013 07:41:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=CWuR5IqbNNo4pKWcnV8xlKGugSZRyYsJKyWS/0FsTqQ=; b=BdsFCnFPFeVH1CUPMQ2W8Q29Ks9sYWFKszsxBgUiWW0TH3y9e9+kxwYC/lQiv4VRdT uGU5ylgEECub7D8jwAVyRpnsuyt9vjIz4S/g5197NYghdZ65cFTba/RBQSiodS5pkNez gMRvTtdg/FDYzCbulioKigkI7vwgJ/TxsJ2O8fbf1uBwd7+Pu3u8dAkzxwawQFb0KNt6 w69+lvawUHN39byBoR9oeIg5k/qpKq6CMfGQ+JYBeiyJzejfnt6EE1RIW/bOMUFV9j/s 66/43TylQe2GziXsN5JT77lyC8MYieEdF+EJqZp5zFG0WSbXwvqOnqFrLqZFKcLyD/Rp f0aQ== MIME-Version: 1.0 X-Received: by 10.66.248.228 with SMTP id yp4mr13153404pac.158.1371480097216; Mon, 17 Jun 2013 07:41:37 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Mon, 17 Jun 2013 07:41:37 -0700 (PDT) In-Reply-To: References: <20130522.075021.510632113.mbj@tail-f.com> <20130522.083817.336589153.mbj@tail-f.com> <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local> <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net> <5AB07445-A5EA-4105-B5CE-85B14D3BF397@nic.cz> <20130529235204.GA58491@elstar.local> Date: Mon, 17 Jun 2013 07:41:37 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=047d7b15b2bd02fae204df5a987d X-Gm-Message-State: ALoCoQkQq+jr69Gk2eV9dQiBAoxo0rE/HxjBFgar0+EEuIlJtVwMhAQamPVHZ4YaWeXzjABmDDma Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:41:41 -0000 --047d7b15b2bd02fae204df5a987d Content-Type: text/plain; charset=ISO-8859-1 Hi, I think we should publish what we have, which is more aligned with existing implementations and SNMP. The enhancements you describe could be added in the future with augments or a module update. An identity in addition to an IANA enum is OK. Andy On Mon, Jun 17, 2013 at 5:49 AM, Ladislav Lhotka wrote: > Hi, > > the discussion below doesn't seem to have reached any conclusion. But > whatever the answer to Juergen's question might be, I think we should > consider the "type" leaf again, because: > > 1. The "type" leaf is useful in YANG for restricting some configuration > parameters for use only with a certain interface type. The existing values > in the "iana-if-type" enumeration, such as "ethernetCsmacd" or "tunnel", > don't seem very effective in this respect. What we need is the type > information that's often encoded in (platform-specific) interface names, > for example TenGigabitEthernet0/1, gr-0/0/0 or ppp0. > > 2. We actually need a *hierarchy* of interface types, whereas > "iana-if-type" is flat. For instance, take the Ethernet example in Appendix > A: The "when" condition > > when "if:type = 'ethernetCsmacd'"; > > causes the generic Ethernet parameters to apply only to this particular > type, but not to any specialized Ethernet type, say "ieee-802.11bgn" (if > this was ever registered by IANA). > > 3. The set of permitted types should be easily extensible, without the > need to go to IANA first. > > In my opinion, YANG identity is a much better choice for the type of > "type" because it satisfies all three requirements. No extra registry is > needed for identities because they will be registered indirectly through > the module where they are defined. > > It is possible that a simple hierarchy of interface types won't be enough > for representing the variety of real-world interfaces with all their > properties and features. But then additional (type-specific) parameters > could be introduced and used along with "type" for conditional augments. > > Lada > > Juergen Schoenwaelder writes: > > > On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy > Management) wrote: > >> Martin asked that I provide my $0.02 on this draft as we've created > >> an implementation against the -08 version. So here we go... > >> > >> In general I like having the interface-state separate from the > >> interface configuration, it provides an easy way for a user to see > >> what devices are currently in the system and are available for > >> configuration. In our -08 implementation we created a > >> /interfaces/physical-interfaces table that would be pre-populated by > >> the factory with the interfaces that are available for that > >> particular product. Note that our product is not customer > >> expandable, so the interfaces that ship with the unit are the only > >> ones that the customer can configure (ignoring logical interfaces). > >> By having this config false list of interfaces we could achieve the > >> same thing in a more standard way. > > > > This is _very_ welcome feedback. Implementation experience is always > > very welcome - if others implement things as well, please consider to > > share your experiences. This helps a lot. > > > >> We have many proprietary interface types (primarily different types > >> of in-house radio interfaces) that do not fit into the categories > >> defined by iana-if-type. Sure you could use the argument "well then > >> get them added via iana". But that will never happen. > > > > I have to ask this so I do better understand. Why will this never > > happen? > > > > - Is the procedure to register your interface type too complex? > > > > - Is the interface type kind of secret and hence you do not want to > > have it registered somewhere? > > > > - Is it that developers simply would not know how to register a new > > interface type and choose a random value anyway? > > > > - Something else? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b15b2bd02fae204df5a987d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I think we should publish what we have, which is mor= e aligned with
existing implementations and SNMP. =A0The enhancem= ents you
describe could be added in the future with augments or a= module update.
An identity in addition to an IANA enum is OK.


Andy


On Mon, Jun 17, 2013 at 5:49 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
Hi,

the discussion below doesn't seem to have reached any conclusion. But w= hatever the answer to Juergen's question might be, I think we should co= nsider the "type" leaf again, because:

1. The "type" leaf is useful in YANG for restricting some configu= ration parameters for use only with a certain interface type. The existing = values in the "iana-if-type" enumeration, such as "ethernetC= smacd" or "tunnel", don't seem very effective in this re= spect. What we need is the type information that's often encoded in (pl= atform-specific) interface names, for example TenGigabitEthernet0/1, gr-0/0= /0 or ppp0.

2. We actually need a *hierarchy* of interface types, whereas "iana-if= -type" is flat. For instance, take the Ethernet example in Appendix A:= The "when" condition

=A0 =A0 =A0 =A0when "if:type =3D 'ethernetCsmacd'";

causes the generic Ethernet parameters to apply only to this particular typ= e, but not to any specialized Ethernet type, say "ieee-802.11bgn"= (if this was ever registered by IANA).

3. The set of permitted types should be easily extensible, without the need= to go to IANA first.

In my opinion, YANG identity is a much better choice for the type of "= type" because it satisfies all three requirements. No extra registry i= s needed for identities because they will be registered indirectly through = the module where they are defined.

It is possible that a simple hierarchy of interface types won't be enou= gh for representing the variety of real-world interfaces with all their pro= perties and features. But then additional (type-specific) parameters could = be introduced and used along with "type" for conditional augments= .

Lada

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:

> On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE Energy = Management) wrote:
>> Martin asked that I provide my $0.02 on this draft as we've cr= eated
>> an implementation against the -08 version. So here we go...
>>
>> In general I like having the interface-state separate from the
>> interface configuration, it provides an easy way for a user to see=
>> what devices are currently in the system and are available for
>> configuration. =A0In our -08 implementation we created a
>> /interfaces/physical-interfaces table that would be pre-populated = by
>> the factory with the interfaces that are available for that
>> particular product. =A0Note that our product is not customer
>> expandable, so the interfaces that ship with the unit are the only=
>> ones that the customer can configure (ignoring logical interfaces)= .
>> By having this config false list of interfaces we could achieve th= e
>> same thing in a more standard way.
>
> This is _very_ welcome feedback. Implementation experience is always > very welcome - if others implement things as well, please consider to<= br> > share your experiences. This helps a lot.
>
>> We have many proprietary interface types (primarily different type= s
>> of in-house radio interfaces) that do not fit into the categories<= br> >> defined by iana-if-type. =A0Sure you could use the argument "= well then
>> get them added via iana". =A0But that will never happen.
>
> I have to ask this so I do better understand. Why will this never
> happen?
>
> - Is the procedure to register your interface type too complex?
>
> - Is the interface type kind of secret and hence you do not want to > =A0 have it registered somewhere?
>
> - Is it that developers simply would not know how to register a new > =A0 interface type and choose a random value anyway?
>
> - Something else?
>
> /js
>
> --
> Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGm= bH
> Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, G= ermany
> Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/= >
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7b15b2bd02fae204df5a987d-- From lhotka@nic.cz Mon Jun 17 08:00:05 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FA121F9CEB for ; Mon, 17 Jun 2013 08:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.773 X-Spam-Level: X-Spam-Status: No, score=-1.773 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLxtRcmprfgs for ; Mon, 17 Jun 2013 08:00:03 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AD9B821F9CEA for ; Mon, 17 Jun 2013 08:00:02 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AC5ED13FCB8; Mon, 17 Jun 2013 17:00:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371481201; bh=9A9ZriK8LXR6Wn8mlD80X1MRxRpRkqiEdpDxexFC0tc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Q/hKn/N6PYRLZ9rFUpLqKzhBGG0tXFD8Q1EYrVV4SfJjbGx5b7n67e97GRqPw4Xqe Exz0U46mi7Gxgkahp/217eVQalNsdpdc+8l8tqd1K88+FX5kWs2zpTNzWya5ePhLVU RrFUkGD5HM35hurGDdVM5JeixkAVt0c+EtPU1vbM= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 17 Jun 2013 17:00:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <24A7D8DE-AE8C-407F-9C3D-BBA617A030B6@nic.cz> References: <20130522.075021.510632113.mbj@tail-f.com> <20130522.083817.336589153.mbj@tail-f.com> <00a101ce57ca$50c19fc0$4001a8c0@gateway.2wire.net> <20130523182554.GB34233@elstar.local> <019d01ce5b86$71d43140$4001a8c0@gateway.2wire.net> <5AB07445-A5EA-4105-B5CE-85B14D3BF397@nic.cz> <20130529235204.GA58491@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 15:00:05 -0000 On Jun 17, 2013, at 4:41 PM, Andy Bierman wrote: > Hi, >=20 > I think we should publish what we have, which is more aligned with > existing implementations and SNMP. The enhancements you > describe could be added in the future with augments or a module = update. > An identity in addition to an IANA enum is OK. The crucial thing is what will be used for restricting augments in = future modules (be it in "when" statements or just in descriptions). The = current document assumes and recommends the "type" leaf for this = purpose, but I am arguing it can hardly work in reality. The alignment with SNMP can be approached from the opposite end by = introducing an extra leaf, say "iana-type", that could be a part of the = "if-mib" feature. Lada >=20 >=20 > Andy >=20 >=20 > On Mon, Jun 17, 2013 at 5:49 AM, Ladislav Lhotka = wrote: > Hi, >=20 > the discussion below doesn't seem to have reached any conclusion. But = whatever the answer to Juergen's question might be, I think we should = consider the "type" leaf again, because: >=20 > 1. The "type" leaf is useful in YANG for restricting some = configuration parameters for use only with a certain interface type. The = existing values in the "iana-if-type" enumeration, such as = "ethernetCsmacd" or "tunnel", don't seem very effective in this respect. = What we need is the type information that's often encoded in = (platform-specific) interface names, for example TenGigabitEthernet0/1, = gr-0/0/0 or ppp0. >=20 > 2. We actually need a *hierarchy* of interface types, whereas = "iana-if-type" is flat. For instance, take the Ethernet example in = Appendix A: The "when" condition >=20 > when "if:type =3D 'ethernetCsmacd'"; >=20 > causes the generic Ethernet parameters to apply only to this = particular type, but not to any specialized Ethernet type, say = "ieee-802.11bgn" (if this was ever registered by IANA). >=20 > 3. The set of permitted types should be easily extensible, without the = need to go to IANA first. >=20 > In my opinion, YANG identity is a much better choice for the type of = "type" because it satisfies all three requirements. No extra registry is = needed for identities because they will be registered indirectly through = the module where they are defined. >=20 > It is possible that a simple hierarchy of interface types won't be = enough for representing the variety of real-world interfaces with all = their properties and features. But then additional (type-specific) = parameters could be introduced and used along with "type" for = conditional augments. >=20 > Lada >=20 > Juergen Schoenwaelder writes: >=20 > > On Wed, May 29, 2013 at 05:53:19PM +0000, Lange, Jeffrey K (GE = Energy Management) wrote: > >> Martin asked that I provide my $0.02 on this draft as we've created > >> an implementation against the -08 version. So here we go... > >> > >> In general I like having the interface-state separate from the > >> interface configuration, it provides an easy way for a user to see > >> what devices are currently in the system and are available for > >> configuration. In our -08 implementation we created a > >> /interfaces/physical-interfaces table that would be pre-populated = by > >> the factory with the interfaces that are available for that > >> particular product. Note that our product is not customer > >> expandable, so the interfaces that ship with the unit are the only > >> ones that the customer can configure (ignoring logical interfaces). > >> By having this config false list of interfaces we could achieve the > >> same thing in a more standard way. > > > > This is _very_ welcome feedback. Implementation experience is always > > very welcome - if others implement things as well, please consider = to > > share your experiences. This helps a lot. > > > >> We have many proprietary interface types (primarily different types > >> of in-house radio interfaces) that do not fit into the categories > >> defined by iana-if-type. Sure you could use the argument "well = then > >> get them added via iana". But that will never happen. > > > > I have to ask this so I do better understand. Why will this never > > happen? > > > > - Is the procedure to register your interface type too complex? > > > > - Is the interface type kind of secret and hence you do not want to > > have it registered somewhere? > > > > - Is it that developers simply would not know how to register a new > > interface type and choose a random value anyway? > > > > - Something else? > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From internet-drafts@ietf.org Mon Jun 17 13:41:47 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D73421F9E2A; Mon, 17 Jun 2013 13:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qBVfkd5yBGQ; Mon, 17 Jun 2013 13:41:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2421F9C9C; Mon, 17 Jun 2013 13:41:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 13:41:46 -0700 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 20:41:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : YANG Data Model for System Management Author(s) : Andy Bierman Martin Bjorklund Filename : draft-ietf-netmod-system-mgmt-07.txt Pages : 37 Date : 2013-06-17 Abstract: This document defines a YANG data model for the configuration and identification of some common system properties within a device containing a NETCONF server. This includes data node definitions for system identification, time-of-day management, user management, DNS resolver configuration, and some protocol operations for system management. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=8881027016=balazs.lengyel@ericsson.com Tue Jun 18 01:05:46 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0120B21F9A4A for ; Tue, 18 Jun 2013 01:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.52 X-Spam-Level: X-Spam-Status: No, score=-5.52 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APNUrr8YF7dC for ; Tue, 18 Jun 2013 01:05:39 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6462B21F9A03 for ; Tue, 18 Jun 2013 01:05:39 -0700 (PDT) X-AuditID: c1b4fb30-b7f9e6d000002643-a4-51c014d13a71 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CF.87.09795.1D410C15; Tue, 18 Jun 2013 10:05:38 +0200 (CEST) Received: from [159.107.197.23] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 18 Jun 2013 10:05:37 +0200 Message-ID: <51C014D0.2010500@ericsson.com> Date: Tue, 18 Jun 2013 10:05:36 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ladislav Lhotka References: <7B4F387B-1AA9-4FB2-B996-72B0BA5E5F68@nic.cz> In-Reply-To: <7B4F387B-1AA9-4FB2-B996-72B0BA5E5F68@nic.cz> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvre4lkQOBBhsu8lo8ODKL3eLCqrls FvMvNrI6MHssWfKTyWPT5TuMHi39F1kCmKO4bZISS8qCM9Pz9O0SuDN+/dnOWnCLrWLZ4ZfM DYw9rF2MnBwSAiYSb1Z/ZIawxSQu3FvP1sXIxSEkcIpR4uqqDmYIZw2jxLQl5xhBqngFtCVu rL8H1s0ioCqx6cZndhCbTcBIYmr/eRYQW1QgSmLOugdsEPWCEidnPgGLiwgoS1yc8BPMZhYw k/j6Zz/YTGEBT4kpm26wQiz7yCjRMmUvUIKDg1PASmL9jySIeluJC3OuQ/XKS2x/OwfsaiEB DYmHF/6yTmAUnIVk3SwkLbOQtCxgZF7FyJ6bmJmTXm6+iREYqge3/DbYwbjpvtghRmkOFiVx 3k+ndgUKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4AQRXFINjJuWPMxuX/np8J5dl+LqvrQtClzG 8r/89+xnr6I+G3Dd81plbNR9zExDm1c2odDA5ShDrc4tKynOYpcMh4XFdSYrizpseP7H1fL+ uFpnEc8+yX3iS50fKZ5PWK8eYVCx/1T98eEGlRM2qz34LzstfNl/d77m47vqaybur592VC35 zoNNyRY7jyqxFGckGmoxFxUnAgAYarAmKAIAAA== Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:05:47 -0000 On 2013-06-10 20:13, Ladislav Lhotka wrote: > Mechanisms external to NETCONF cannot be expected to update anything in a NETCONF datastore, and the NETCONF server - if it is notified about a change - may not be able to do it either, e.g. because of a lock on the datastore. I always thought that the configuration datastore (not a netconf datastore) can be updated by many interfaces: Netconf, CLI, GUI, SNMP, the node itself, SON, etc. AFAIK the Tailf implementation has a common datastore serving all interfaces. IMHO after Call-Home get2 would be my next interest in Netconf, which could include get-informational. Balazs -- Balazs Lengyel Ericsson Hungary Ltd. System Manager ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From lhotka@nic.cz Tue Jun 18 01:26:45 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9666D21F9C12 for ; Tue, 18 Jun 2013 01:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pjcw2Z9f+6Ju for ; Tue, 18 Jun 2013 01:26:45 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D069321F9C10 for ; Tue, 18 Jun 2013 01:26:44 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id A208413F68E; Tue, 18 Jun 2013 10:26:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371544002; bh=u90DWh1up8Ae8U5NKxEiZDmnV4/zUxGYU65CjZ30cf0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pHpLZ195ztDo+QID7kf0rQsvXPNA2jXPf1Z0e6dxmTVULcSMuhkfuRN2d21cI5DP9 KptbJcdNce6knksYR+lgx1JGjlJfmNkPwt5HkNwSPgLBU01wd8umHETwIB2yDuYcu0 rROYqOc3gpKkszP1VVvSMiLXAnj6hBEKE0CGdFnA= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <51C014D0.2010500@ericsson.com> Date: Tue, 18 Jun 2013 10:26:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B4F387B-1AA9-4FB2-B996-72B0BA5E5F68@nic.cz> <51C014D0.2010500@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:26:45 -0000 Hi Balazs, On Jun 18, 2013, at 10:05 AM, Balazs Lengyel = wrote: >=20 > On 2013-06-10 20:13, Ladislav Lhotka wrote: >> Mechanisms external to NETCONF cannot be expected to update anything = in a NETCONF datastore, and the NETCONF server - if it is notified about = a change - may not be able to do it either, e.g. because of a lock on = the datastore. > I always thought that the configuration datastore (not a netconf = datastore) can be updated by many interfaces: Netconf, CLI, GUI, SNMP, = the node itself, SON, etc. > AFAIK the Tailf implementation has a common datastore serving all = interfaces. If we talk about the NETCONF datastore(s), this could work only if all = these interfaces behave as fully compliant NETCONF clients, because = otherwise they may interfere with locks, commits, rollbacks etc. This is = IMO quite difficult. Of course, having another datastore as "writable operational state" is a = different story. We can enable this concept by separating operational = state data from (NETCONF) configuration, which has been recently done in = the interfaces module. Lada =20 >=20 > IMHO after Call-Home get2 would be my next interest in Netconf, which = could include get-informational. >=20 > Balazs >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > System Manager > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 18 01:53:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6D521F9AA7 for ; Tue, 18 Jun 2013 01:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE4Uo7izJ5S1 for ; Tue, 18 Jun 2013 01:53:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C124821F9B1B for ; Tue, 18 Jun 2013 01:53:15 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 1584B1200D06; Tue, 18 Jun 2013 10:53:14 +0200 (CEST) Date: Tue, 18 Jun 2013 10:53:13 +0200 (CEST) Message-Id: <20130618.105313.2092496369267434657.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <7B4F387B-1AA9-4FB2-B996-72B0BA5E5F68@nic.cz> <51C014D0.2010500@ericsson.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:53:21 -0000 Ladislav Lhotka wrote: > Hi Balazs, > > On Jun 18, 2013, at 10:05 AM, Balazs Lengyel > wrote: > > > > > On 2013-06-10 20:13, Ladislav Lhotka wrote: > >> Mechanisms external to NETCONF cannot be expected to update anything > >> in a NETCONF datastore, and the NETCONF server - if it is notified > >> about a change - may not be able to do it either, e.g. because of a > >> lock on the datastore. > > I always thought that the configuration datastore (not a netconf > > datastore) can be updated by many interfaces: Netconf, CLI, GUI, SNMP, > > the node itself, SON, etc. > > AFAIK the Tailf implementation has a common datastore serving all > > interfaces. > > If we talk about the NETCONF datastore(s), this could work only if all > these interfaces behave as fully compliant NETCONF clients, because > otherwise they may interfere with locks, commits, rollbacks etc. This > is IMO quite difficult. This is what implementations do. It would be extremely weird to have *different* running configs in NETCONF and the CLI for example. The fact that they are shared are hinted at in RFC 6241, section 7.5: The operation allows the client to lock the entire configuration datastore system of a device. Such locks are intended to be short-lived and allow a client to make a change without fear of interaction with other NETCONF clients, non- NETCONF clients (e.g., SNMP and command line interface (CLI) scripts), and human users. /martin From lhotka@nic.cz Tue Jun 18 01:58:36 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FBC21F9D98 for ; Tue, 18 Jun 2013 01:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6b-9d7BpIH5 for ; Tue, 18 Jun 2013 01:58:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0A03521F9C3E for ; Tue, 18 Jun 2013 01:58:36 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 3B84413F68E; Tue, 18 Jun 2013 10:58:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371545915; bh=sIVZ/xBbQcQo2/dvBme1532rJxvJgXvz6b8t3v6PIpc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=E7D5sWzHuiMLhQWVuYMfOjs7koBIhC/4pHt9mCARvdwuQNkJMY4uZMOWDxKTDdtjQ oLua0D2USLy/bxKoKDvOevTANKuWbu+F06HIcZmeGQBG81ZySym7TmAJVjhp/or5uK mMzdqT7zDt/7nHCNOU5lQxChy8Kap3Na0qfPi7EA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130618.105313.2092496369267434657.mbj@tail-f.com> Date: Tue, 18 Jun 2013 10:58:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D2155A6-0E46-402A-9F70-EF157FD92199@nic.cz> References: <7B4F387B-1AA9-4FB2-B996-72B0BA5E5F68@nic.cz> <51C014D0.2010500@ericsson.com> <20130618.105313.2092496369267434657.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:58:36 -0000 On Jun 18, 2013, at 10:53 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Hi Balazs, >>=20 >> On Jun 18, 2013, at 10:05 AM, Balazs Lengyel >> wrote: >>=20 >>>=20 >>> On 2013-06-10 20:13, Ladislav Lhotka wrote: >>>> Mechanisms external to NETCONF cannot be expected to update = anything >>>> in a NETCONF datastore, and the NETCONF server - if it is notified >>>> about a change - may not be able to do it either, e.g. because of a >>>> lock on the datastore. >>> I always thought that the configuration datastore (not a netconf >>> datastore) can be updated by many interfaces: Netconf, CLI, GUI, = SNMP, >>> the node itself, SON, etc. >>> AFAIK the Tailf implementation has a common datastore serving all >>> interfaces. >>=20 >> If we talk about the NETCONF datastore(s), this could work only if = all >> these interfaces behave as fully compliant NETCONF clients, because >> otherwise they may interfere with locks, commits, rollbacks etc. This >> is IMO quite difficult. >=20 > This is what implementations do. It would be extremely weird to have > *different* running configs in NETCONF and the CLI for example. The > fact that they are shared are hinted at in RFC 6241, section 7.5: >=20 > The operation allows the client to lock the > entire configuration datastore system of a device. Such locks = are > intended to be short-lived and allow a client to make a change > without fear of interaction with other NETCONF clients, non- > NETCONF clients (e.g., SNMP and command line interface (CLI) > scripts), and human users. So what if the NETCONF server has a candidate datastore and = non-writeable running? Are the alternative interfaces, such as SNMP, = supposed to go through candidate and perform commits? Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 18 01:59:39 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C85E21F9A6E for ; Tue, 18 Jun 2013 01:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdnYP879yo5T for ; Tue, 18 Jun 2013 01:59:33 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 82BF421F9D05 for ; Tue, 18 Jun 2013 01:59:33 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A1BC1200D06; Tue, 18 Jun 2013 10:59:32 +0200 (CEST) Date: Tue, 18 Jun 2013 10:59:32 +0200 (CEST) Message-Id: <20130618.105932.2031732986748508850.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <1D2155A6-0E46-402A-9F70-EF157FD92199@nic.cz> References: <20130618.105313.2092496369267434657.mbj@tail-f.com> <1D2155A6-0E46-402A-9F70-EF157FD92199@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 08:59:39 -0000 Ladislav Lhotka wrote: > > On Jun 18, 2013, at 10:53 AM, Martin Bjorklund wrote: > > > Ladislav Lhotka wrote: > >> Hi Balazs, > >> > >> On Jun 18, 2013, at 10:05 AM, Balazs Lengyel > >> wrote: > >> > >>> > >>> On 2013-06-10 20:13, Ladislav Lhotka wrote: > >>>> Mechanisms external to NETCONF cannot be expected to update anything > >>>> in a NETCONF datastore, and the NETCONF server - if it is notified > >>>> about a change - may not be able to do it either, e.g. because of a > >>>> lock on the datastore. > >>> I always thought that the configuration datastore (not a netconf > >>> datastore) can be updated by many interfaces: Netconf, CLI, GUI, SNMP, > >>> the node itself, SON, etc. > >>> AFAIK the Tailf implementation has a common datastore serving all > >>> interfaces. > >> > >> If we talk about the NETCONF datastore(s), this could work only if all > >> these interfaces behave as fully compliant NETCONF clients, because > >> otherwise they may interfere with locks, commits, rollbacks etc. This > >> is IMO quite difficult. > > > > This is what implementations do. It would be extremely weird to have > > *different* running configs in NETCONF and the CLI for example. The > > fact that they are shared are hinted at in RFC 6241, section 7.5: > > > > The operation allows the client to lock the > > entire configuration datastore system of a device. Such locks are > > intended to be short-lived and allow a client to make a change > > without fear of interaction with other NETCONF clients, non- > > NETCONF clients (e.g., SNMP and command line interface (CLI) > > scripts), and human users. > > So what if the NETCONF server has a candidate datastore and > non-writeable running? Are the alternative interfaces, such as SNMP, > supposed to go through candidate and perform commits? Some implementations do this, and some might now allow SNMP write access... /martin From lhotka@nic.cz Tue Jun 18 02:24:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCC5221F9DBC for ; Tue, 18 Jun 2013 02:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us+AVu9sIaMQ for ; Tue, 18 Jun 2013 02:24:21 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id EA0B521F9DB6 for ; Tue, 18 Jun 2013 02:24:20 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4164A13F68E for ; Tue, 18 Jun 2013 11:24:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371547458; bh=dS8lUXI2JTIBaU30/dVcyKouOOs3ye6kFiMlxX+HUzQ=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=uZ0r9Ur3Kp0+gscf5pI0erakEJmyQjyHD2Fd6WWg8vXKA/6qZ95ToXrTgYVcQwPtP zO5MhvrVjGsgxdqi1L7z26rwzyjwC9GaqCORzn+tr95unTNzom5y8ChnfDLsVror1m S69SPMu4IxO6r28CPT2tFwojgwC3kwHj8CZrSHN4= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jun 2013 11:24:17 +0200 References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> To: netmod@ietf.org Message-Id: <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:24:22 -0000 Hi, I have a question regarding DNS resolver configuration. If the resolver = receives a truncated response (TC flag set), it has to switch to TCP. So = I don't understand why the only case in the "transport" choice is "udp" = and how is the resolver supposed to behave. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [netmod] I-D Action: draft-ietf-netmod-system-mgmt-07.txt > Date: June 17, 2013 10:41:46 PM GMT+02:00 > To: i-d-announce@ietf.org > Cc: netmod@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the NETCONF Data Modeling Language = Working Group of the IETF. >=20 > Title : YANG Data Model for System Management > Author(s) : Andy Bierman > Martin Bjorklund > Filename : draft-ietf-netmod-system-mgmt-07.txt > Pages : 37 > Date : 2013-06-17 >=20 > Abstract: > This document defines a YANG data model for the configuration and > identification of some common system properties within a device > containing a NETCONF server. This includes data node definitions = for > system identification, time-of-day management, user management, DNS > resolver configuration, and some protocol operations for system > management. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-netmod-system-mgmt-07 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-system-mgmt-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Tue Jun 18 02:42:00 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D7321F9D83 for ; Tue, 18 Jun 2013 02:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id remicavAk9ha for ; Tue, 18 Jun 2013 02:42:00 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D50E821F9AB7 for ; Tue, 18 Jun 2013 02:41:58 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 9C22913FCD8; Tue, 18 Jun 2013 11:41:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371548517; bh=I4vnYuDFDqjezr+NWD4DWaLWU56hzU2Lqj9alaSageg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=vJtGxFCHn2zdyfsF2H8Ovqp/ntP3woMikkreEZZmo/b8sfJai9Lh9KzS4O4bb0S8s HUFlrZfcuwpgerr5ZEHLoGs8qdCVqwD/jdboX8sWEM7qdkNzsngH34G7RNIdoJKDlz WAVfYN3wjuhK7i7zQ8d+Zm64Smdm9j/cHHr/5skw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130618.105932.2031732986748508850.mbj@tail-f.com> Date: Tue, 18 Jun 2013 11:41:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130618.105313.2092496369267434657.mbj@tail-f.com> <1D2155A6-0E46-402A-9F70-EF157FD92199@nic.cz> <20130618.105932.2031732986748508850.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] ietf-system: separate config and state conformance? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 09:42:00 -0000 On Jun 18, 2013, at 10:59 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Jun 18, 2013, at 10:53 AM, Martin Bjorklund = wrote: >>=20 >>> Ladislav Lhotka wrote: >>>> Hi Balazs, >>>>=20 >>>> On Jun 18, 2013, at 10:05 AM, Balazs Lengyel >>>> wrote: >>>>=20 >>>>>=20 >>>>> On 2013-06-10 20:13, Ladislav Lhotka wrote: >>>>>> Mechanisms external to NETCONF cannot be expected to update = anything >>>>>> in a NETCONF datastore, and the NETCONF server - if it is = notified >>>>>> about a change - may not be able to do it either, e.g. because of = a >>>>>> lock on the datastore. >>>>> I always thought that the configuration datastore (not a netconf >>>>> datastore) can be updated by many interfaces: Netconf, CLI, GUI, = SNMP, >>>>> the node itself, SON, etc. >>>>> AFAIK the Tailf implementation has a common datastore serving all >>>>> interfaces. >>>>=20 >>>> If we talk about the NETCONF datastore(s), this could work only if = all >>>> these interfaces behave as fully compliant NETCONF clients, because >>>> otherwise they may interfere with locks, commits, rollbacks etc. = This >>>> is IMO quite difficult. >>>=20 >>> This is what implementations do. It would be extremely weird to = have >>> *different* running configs in NETCONF and the CLI for example. The >>> fact that they are shared are hinted at in RFC 6241, section 7.5: >>>=20 >>> The operation allows the client to lock the >>> entire configuration datastore system of a device. Such locks = are >>> intended to be short-lived and allow a client to make a change >>> without fear of interaction with other NETCONF clients, non- >>> NETCONF clients (e.g., SNMP and command line interface (CLI) >>> scripts), and human users. >>=20 >> So what if the NETCONF server has a candidate datastore and >> non-writeable running? Are the alternative interfaces, such as SNMP, >> supposed to go through candidate and perform commits? >=20 > Some implementations do this, and some might now allow SNMP write > access=85 Those that do it may easily run into well-known problems with shared = candidate. Lada =20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 18 03:57:22 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A4F21F9E03 for ; Tue, 18 Jun 2013 03:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHXecVCuyRQV for ; Tue, 18 Jun 2013 03:57:17 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0389F21F9C13 for ; Tue, 18 Jun 2013 03:57:16 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 188531200D06; Tue, 18 Jun 2013 12:57:16 +0200 (CEST) Date: Tue, 18 Jun 2013 12:57:15 +0200 (CEST) Message-Id: <20130618.125715.1936332468455983313.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:57:23 -0000 Hi, Ladislav Lhotka wrote: > Hi, > > I have a question regarding DNS resolver configuration. If the > resolver receives a truncated response (TC flag set), it has to switch > to TCP. So I don't understand why the only case in the "transport" > choice is "udp" and how is the resolver supposed to behave. Right. In the previous version the udp&tcp transport was implicit. So what do we do; consider udp&tcp as one transport (with a single port number)? Define udp and tcp as separate transports where both can be present at the same time? Or do we go back to the old model where additional transports could not be defined in the future? /martin From lhotka@nic.cz Tue Jun 18 05:42:25 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E0221F9EAD for ; Tue, 18 Jun 2013 05:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNWGnIdrsC7L for ; Tue, 18 Jun 2013 05:42:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 542CC21F9D83 for ; Tue, 18 Jun 2013 05:42:24 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id 9626713F68E; Tue, 18 Jun 2013 14:42:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371559343; bh=u9Bu65NU15fKy2mm5k1M3S0gTYfPgzcSlROlvy+Urgk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qWMwTq1AcIvXT9sGsm1yBP1tySszJa/wgk97OEhogxKVeDlQj3m1QeQsDqs8LDtpO OlecASe91zgpIZq4oslVU7/vZmIINalV9Mq4NRNbvBgtLsFqI6+St9IJhfSIZEWpJA rrAabGY21IDKK3RFo9py2hf5/WNNoaduq12TQ98Q= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130618.125715.1936332468455983313.mbj@tail-f.com> Date: Tue, 18 Jun 2013 14:42:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C78AA9B-44D0-4660-B7C3-73F039AFC3F4@nic.cz> References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> <20130618.125715.1936332468455983313.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 12:42:25 -0000 On Jun 18, 2013, at 12:57 PM, Martin Bjorklund wrote: > Hi, >=20 > Ladislav Lhotka wrote: >> Hi, >>=20 >> I have a question regarding DNS resolver configuration. If the >> resolver receives a truncated response (TC flag set), it has to = switch >> to TCP. So I don't understand why the only case in the "transport" >> choice is "udp" and how is the resolver supposed to behave. >=20 > Right. In the previous version the udp&tcp transport was implicit. >=20 > So what do we do; consider udp&tcp as one transport (with a single > port number)? Define udp and tcp as separate transports where both > can be present at the same time? Or do we go back to the old model > where additional transports could not be defined in the future? I'd suggest to return almost to the old version, but with the ability to = specify port number for each server, or perhaps also one common port for = all servers. I am not aware of any resolver implementations using anything else than = UDP/TCP. Was there anybody requesting the extensibility of transports? Lada=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 18 05:52:26 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC88B21F9A6E for ; Tue, 18 Jun 2013 05:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x8OqQoTQUwd for ; Tue, 18 Jun 2013 05:52:20 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C71C621F9B53 for ; Tue, 18 Jun 2013 05:52:11 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id EAD581200D06; Tue, 18 Jun 2013 14:52:09 +0200 (CEST) Date: Tue, 18 Jun 2013 14:52:09 +0200 (CEST) Message-Id: <20130618.145209.281926840603753705.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <3C78AA9B-44D0-4660-B7C3-73F039AFC3F4@nic.cz> References: <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> <20130618.125715.1936332468455983313.mbj@tail-f.com> <3C78AA9B-44D0-4660-B7C3-73F039AFC3F4@nic.cz> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 12:52:26 -0000 Ladislav Lhotka wrote: > > On Jun 18, 2013, at 12:57 PM, Martin Bjorklund wrote: > > > Hi, > > > > Ladislav Lhotka wrote: > >> Hi, > >> > >> I have a question regarding DNS resolver configuration. If the > >> resolver receives a truncated response (TC flag set), it has to switch > >> to TCP. So I don't understand why the only case in the "transport" > >> choice is "udp" and how is the resolver supposed to behave. > > > > Right. In the previous version the udp&tcp transport was implicit. > > > > So what do we do; consider udp&tcp as one transport (with a single > > port number)? Define udp and tcp as separate transports where both > > can be present at the same time? Or do we go back to the old model > > where additional transports could not be defined in the future? > > I'd suggest to return almost to the old version, but with the ability > to specify port number for each server, or perhaps also one common > port for all servers. > > I am not aware of any resolver implementations using anything else > than UDP/TCP. Was there anybody requesting the extensibility of > transports? Yes, but it was in the form of a question: r) The model does not allow me to configure a DNS server using a non-standard port number. Should we not generally allow to configure complete transport layer endpoints? And in general I agree. But maybe this is an exception. /martin From lhotka@nic.cz Tue Jun 18 06:22:08 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A6821F9CEB for ; Tue, 18 Jun 2013 06:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwiiIb3fAAuU for ; Tue, 18 Jun 2013 06:22:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1139021F9C3E for ; Tue, 18 Jun 2013 06:22:07 -0700 (PDT) Received: from [172.20.26.113] (fw.nic.cz [217.31.207.1]) by mail.nic.cz (Postfix) with ESMTPSA id CE9B813F68E; Tue, 18 Jun 2013 15:22:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1371561725; bh=mJdLWKcCIF+7YLjcPa+29UwdQXJN3thctcLjGFtlmvk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=iQ7mCuEeZxQ6oBRLpnERwLUK/frgaXotYYVuFB2XZOQrQt58GJe6FOj1/YysqB6eH +VMnJBs/9VMkPbhVsYwB0jnVg1ircBiyEdiLK4LSOX+BlaHFQhonDL8FnovhPh1X0Y SLqYHKgi/rw7247nw7lZJ+wDDEuV6uQcgaRI1g4I= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130618.145209.281926840603753705.mbj@tail-f.com> Date: Tue, 18 Jun 2013 15:22:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> <20130618.125715.1936332468455983313.mbj@tail-f.com> <3C78AA9B-44D0-4660-B7C3-73F039AFC3F4@nic.cz> <20130618.145209.281926840603753705.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:22:08 -0000 On Jun 18, 2013, at 2:52 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On Jun 18, 2013, at 12:57 PM, Martin Bjorklund = wrote: >>=20 >>> Hi, >>>=20 >>> Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> I have a question regarding DNS resolver configuration. If the >>>> resolver receives a truncated response (TC flag set), it has to = switch >>>> to TCP. So I don't understand why the only case in the "transport" >>>> choice is "udp" and how is the resolver supposed to behave. >>>=20 >>> Right. In the previous version the udp&tcp transport was implicit. >>>=20 >>> So what do we do; consider udp&tcp as one transport (with a single >>> port number)? Define udp and tcp as separate transports where both >>> can be present at the same time? Or do we go back to the old model >>> where additional transports could not be defined in the future? >>=20 >> I'd suggest to return almost to the old version, but with the ability >> to specify port number for each server, or perhaps also one common >> port for all servers. >>=20 >> I am not aware of any resolver implementations using anything else >> than UDP/TCP. Was there anybody requesting the extensibility of >> transports? >=20 > Yes, but it was in the form of a question: >=20 > r) The model does not allow me to configure a DNS server using a > non-standard port number. Should we not generally allow to > configure complete transport layer endpoints? >=20 > And in general I agree. But maybe this is an exception. I think the "server" list could be left for the standard UDP/TCP. If any = other transport was ever defined, which is IMO not very likely, it can = be added in a separate container under "dns-resolver". Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Jun 19 01:32:50 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03221F9997 for ; Wed, 19 Jun 2013 01:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.1 X-Spam-Level: X-Spam-Status: No, score=-103.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAv5HXjrrJUx for ; Wed, 19 Jun 2013 01:32:45 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 16B4E21F9C0E for ; Wed, 19 Jun 2013 01:32:45 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 735B520BEB; Wed, 19 Jun 2013 10:32:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kNKlN5j_GFdb; Wed, 19 Jun 2013 10:32:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 099FA20BE5; Wed, 19 Jun 2013 10:32:44 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EDAB726F5B85; Wed, 19 Jun 2013 10:32:43 +0200 (CEST) Date: Wed, 19 Jun 2013 10:32:43 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20130619083243.GA27701@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 08:32:50 -0000 On Tue, Jun 18, 2013 at 11:24:17AM +0200, Ladislav Lhotka wrote: > Hi, > > I have a question regarding DNS resolver configuration. If the resolver receives a truncated response (TC flag set), it has to switch to TCP. So I don't understand why the only case in the "transport" choice is "udp" and how is the resolver supposed to behave. > If a protocol internally switches the transport used, I think this is outside the scope of the _configuration_ of the protocol, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 19 02:00:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB0D21F8F87 for ; Wed, 19 Jun 2013 02:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.946 X-Spam-Level: X-Spam-Status: No, score=-1.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad3WuNjKqrvd for ; Wed, 19 Jun 2013 02:00:43 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 512F221F9FAD for ; Wed, 19 Jun 2013 02:00:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id A33051200DC2; Wed, 19 Jun 2013 11:00:41 +0200 (CEST) Date: Wed, 19 Jun 2013 11:00:41 +0200 (CEST) Message-Id: <20130619.110041.1306041189598339074.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130619083243.GA27701@elstar.local> References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> <20130619083243.GA27701@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:00:49 -0000 Juergen Schoenwaelder wrote: > On Tue, Jun 18, 2013 at 11:24:17AM +0200, Ladislav Lhotka wrote: > > Hi, > > > > I have a question regarding DNS resolver configuration. If the > > resolver receives a truncated response (TC flag set), it has to switch > > to TCP. So I don't understand why the only case in the "transport" > > choice is "udp" and how is the resolver supposed to behave. > > > > If a protocol internally switches the transport used, I think this is > outside the scope of the _configuration_ of the protocol, no? The point is that the standard mandates the use of both UDP and TCP to the server, so the current choice doesn't really work. You need to be able to configure both udp and tcp for the same server. /martin From j.schoenwaelder@jacobs-university.de Wed Jun 19 02:19:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23ED21F98AD for ; Wed, 19 Jun 2013 02:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.125 X-Spam-Level: X-Spam-Status: No, score=-103.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvo0REWT8a6s for ; Wed, 19 Jun 2013 02:19:15 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9E01521F9A11 for ; Wed, 19 Jun 2013 02:19:15 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A877B20BF3; Wed, 19 Jun 2013 11:19:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q4aMQij_iX1x; Wed, 19 Jun 2013 11:19:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3371420BDB; Wed, 19 Jun 2013 11:19:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1FCE026F5D2F; Wed, 19 Jun 2013 11:19:14 +0200 (CEST) Date: Wed, 19 Jun 2013 11:19:14 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130619091913.GA27823@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> <20130619083243.GA27701@elstar.local> <20130619.110041.1306041189598339074.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619.110041.1306041189598339074.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 09:19:21 -0000 On Wed, Jun 19, 2013 at 11:00:41AM +0200, Martin Bjorklund wrote: > > The point is that the standard mandates the use of both UDP and TCP to > the server, so the current choice doesn't really work. You need to be > able to configure both udp and tcp for the same server. > My understanding was the ietf-netmod-system applies to the DNS resolver client, not to a DNS server. By default, a resolver uses UDP today, unless I set RES_USEVC in my application as a resolver option, no? The resolver may switch to TCP if necessary but is this not a protocol internal mechanism? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 19 03:00:35 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A43B21F9F9C for ; Wed, 19 Jun 2013 03:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJaQe7hu6dn8 for ; Wed, 19 Jun 2013 03:00:29 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CEC4121F9FA0 for ; Wed, 19 Jun 2013 03:00:26 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 004981200DD1; Wed, 19 Jun 2013 12:00:23 +0200 (CEST) Date: Wed, 19 Jun 2013 12:00:23 +0200 (CEST) Message-Id: <20130619.120023.2027276356341059653.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130619091913.GA27823@elstar.local> References: <20130619083243.GA27701@elstar.local> <20130619.110041.1306041189598339074.mbj@tail-f.com> <20130619091913.GA27823@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 10:00:35 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 19, 2013 at 11:00:41AM +0200, Martin Bjorklund wrote: > > > > The point is that the standard mandates the use of both UDP and TCP to > > the server, so the current choice doesn't really work. You need to be > > able to configure both udp and tcp for the same server. > > > > My understanding was the ietf-netmod-system applies to the DNS > resolver client, not to a DNS server. Yes. > By default, a resolver uses UDP > today, unless I set RES_USEVC in my application as a resolver option, > no? The resolver may switch to TCP if necessary but is this not a > protocol internal mechanism? If we have configured the resolver with: foo
10.0.0.1
 how can we expect it to ever connect over TCP? Some alternatives are: foo
10.0.0.1
10.0.0.1
 or: foo
10.0.0.1
 or: foo
10.0.0.1
 /martin From j.schoenwaelder@jacobs-university.de Wed Jun 19 05:17:03 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA20321F9BF1 for ; Wed, 19 Jun 2013 05:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.143 X-Spam-Level: X-Spam-Status: No, score=-103.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTBGVZ-f7-H2 for ; Wed, 19 Jun 2013 05:16:57 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6A621F9BF2 for ; Wed, 19 Jun 2013 05:16:56 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7318720BE5; Wed, 19 Jun 2013 14:16:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Pz8OuL7BnV-6; Wed, 19 Jun 2013 14:16:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C92820BF0; Wed, 19 Jun 2013 14:16:54 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 866D426F61DF; Wed, 19 Jun 2013 14:16:54 +0200 (CEST) Date: Wed, 19 Jun 2013 14:16:54 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130619121654.GA28257@elstar.local> Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org References: <20130619083243.GA27701@elstar.local> <20130619.110041.1306041189598339074.mbj@tail-f.com> <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130619.120023.2027276356341059653.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:17:03 -0000 On Wed, Jun 19, 2013 at 12:00:23PM +0200, Martin Bjorklund wrote: > > By default, a resolver uses UDP > > today, unless I set RES_USEVC in my application as a resolver option, > > no? The resolver may switch to TCP if necessary but is this not a > > protocol internal mechanism? > > If we have configured the resolver with: > > > foo > >
10.0.0.1
> > > > how can we expect it to ever connect over TCP? It is a protocol internal upgrade - you have to understand the protocol to know about it. Trying an analogy: If I put a http: URL in a config and then the web server redirects it to a https: URL (or even something totally different like a ftp: URL) then this does not affect the validity of my config either. The config says what I start with. The rest is something determined at runtime. Does this make sense? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mbj@tail-f.com Wed Jun 19 05:35:20 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D362E21F9C19 for ; Wed, 19 Jun 2013 05:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+yIyh9ssSl7 for ; Wed, 19 Jun 2013 05:35:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id C23B621F9C20 for ; Wed, 19 Jun 2013 05:35:14 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 4850A1200D06; Wed, 19 Jun 2013 14:35:12 +0200 (CEST) Date: Wed, 19 Jun 2013 14:35:12 +0200 (CEST) Message-Id: <20130619.143512.1222014155040382761.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20130619121654.GA28257@elstar.local> References: <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> <20130619121654.GA28257@elstar.local> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:35:20 -0000 Juergen Schoenwaelder wrote: > On Wed, Jun 19, 2013 at 12:00:23PM +0200, Martin Bjorklund wrote: > > > > By default, a resolver uses UDP > > > today, unless I set RES_USEVC in my application as a resolver option, > > > no? The resolver may switch to TCP if necessary but is this not a > > > protocol internal mechanism? > > > > If we have configured the resolver with: > > > > > > foo > > > >
10.0.0.1
> > > > > > > > how can we expect it to ever connect over TCP? > > It is a protocol internal upgrade - you have to understand the > protocol to know about it. > > Trying an analogy: If I put a http: URL in a config and then the web > server redirects it to a https: URL (or even something totally > different like a ftp: URL) then this does not affect the validity of > my config either. > > The config says what I start with. The rest is something determined at > runtime. Does this make sense? Ok, yes I guess you can see it this way. It is a bit unclear to me how this "internal protocol upgrade" is specified. Does it say that the client tries TCP on the same port as it tried UDP, or to the TCP port found in the local config? -- Note how we allow a port to be configured, but the protocol spec (1123) only talks about port 53. Also, how would you handle the RES_USEVC flag? Note how RFC 5966 says: Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of RFC 1123 also says: ... a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first. That requirement is hereby relaxed. A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP (with or without EDNS0) or for other operational reasons, [...] /martin From lhotka@nic.cz Wed Jun 19 05:36:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94621F9AED for ; Wed, 19 Jun 2013 05:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-K4vcadowo3 for ; Wed, 19 Jun 2013 05:36:23 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id F3FDF21F854E for ; Wed, 19 Jun 2013 05:35:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C21175402F3 for ; Wed, 19 Jun 2013 14:35:43 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOav8m2uhJzj for ; Wed, 19 Jun 2013 14:35:24 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BF27954015B for ; Wed, 19 Jun 2013 14:35:19 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130619083243.GA27701@elstar.local> References: <20130617204146.28054.45657.idtracker@ietfa.amsl.com> <9A7080FB-10EF-4583-993E-D65D97600BC4@nic.cz> <20130619083243.GA27701@elstar.local> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 19 Jun 2013 14:35:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:36:27 -0000 Juergen Schoenwaelder writes: > On Tue, Jun 18, 2013 at 11:24:17AM +0200, Ladislav Lhotka wrote: >> Hi, >> >> I have a question regarding DNS resolver configuration. If the resolver receives a truncated response (TC flag set), it has to switch to TCP. So I don't understand why the only case in the "transport" choice is "udp" and how is the resolver supposed to behave. >> > > If a protocol internally switches the transport used, I think this is > outside the scope of the _configuration_ of the protocol, no? A resolver may start with TCP right away. RFC 5966: "A resolver SHOULD send a UDP query first, but MAY elect to send a TCP query instead if it has good reason to expect the response would be truncated if it were sent over UDP ...". If a different port is configured under "udp", it is not clear whether the resolver is supposed to use the same port for TCP as well, or stick to the default 53. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Jun 19 05:47:17 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9CB21F938E for ; Wed, 19 Jun 2013 05:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.411 X-Spam-Level: X-Spam-Status: No, score=-1.411 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxGjEiBbX9gV for ; Wed, 19 Jun 2013 05:47:04 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 965FE21F9B88 for ; Wed, 19 Jun 2013 05:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C63475402F3; Wed, 19 Jun 2013 14:46:37 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeoVVEoRTYF0; Wed, 19 Jun 2013 14:46:34 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 499DA54015B; Wed, 19 Jun 2013 14:46:34 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20130619.120023.2027276356341059653.mbj@tail-f.com> References: <20130619083243.GA27701@elstar.local> <20130619.110041.1306041189598339074.mbj@tail-f.com> <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de, netmod@ietf.org Date: Wed, 19 Jun 2013 14:46:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:47:17 -0000 Martin Bjorklund writes: > Juergen Schoenwaelder wrote: >> On Wed, Jun 19, 2013 at 11:00:41AM +0200, Martin Bjorklund wrote: >> > >> > The point is that the standard mandates the use of both UDP and TCP to >> > the server, so the current choice doesn't really work. You need to be >> > able to configure both udp and tcp for the same server. >> > >> >> My understanding was the ietf-netmod-system applies to the DNS >> resolver client, not to a DNS server. > > Yes. > >> By default, a resolver uses UDP >> today, unless I set RES_USEVC in my application as a resolver option, >> no? The resolver may switch to TCP if necessary but is this not a >> protocol internal mechanism? > > If we have configured the resolver with: > > > foo > >
10.0.0.1
> > > > how can we expect it to ever connect over TCP? > > Some alternatives are: > > > foo > >
10.0.0.1
> > >
10.0.0.1
> > > > or: > > > foo > >
10.0.0.1
> > > > or: > > > foo >
10.0.0.1
> or: foo
10.0.0.1
6378 <-- optional, with default 53. I would prefer this, and the description should state that the address and port is used for both UDP and TCP connections. Lada > > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Jun 25 00:56:49 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A77321F9798 for ; Tue, 25 Jun 2013 00:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkOraC3sjAzM for ; Tue, 25 Jun 2013 00:56:43 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61D21E805D for ; Tue, 25 Jun 2013 00:56:42 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 367E41200C82 for ; Tue, 25 Jun 2013 09:56:41 +0200 (CEST) Date: Tue, 25 Jun 2013 09:56:41 +0200 (CEST) Message-Id: <20130625.095641.461784957513008174.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 07:56:49 -0000 Hi, I would like to resolve the issue about DNS transport. I had a chat with Lars-Johan Liman about this, and he basically acknowledged what we have said: the protocol architecturally supports other transports; the default transport is a mix of UDP and TCP. Here are some alternatives, both data model and XML instance example: A. Explicit transport type -------------------------- list server { key name; ... choice transport { case udp-and-tcp { container udp-and-tcp { leaf address { ... } leaf port { ... default 53; } } } } } foo
10.0.0.1
 Q: What is a good name for the transport? "udp-and-tcp" is a bit awkward. B. Implicit transport type -------------------------- list server { key name; ... choice transport { case udp-and-tcp { leaf address { ... } leaf port { ... default 53; } } } } foo
10.0.0.1
 Pro: Straightforward, and still extensible Con: Does not follow the same patterns as NTP and RADIUS. C. Multiple transports ---------------------- list server { key name; ... container udp { leaf address { ... } leaf port { ... default 53; } } container tcp { leaf address { ... } leaf port { ... default 53; } } } foo
10.0.0.1
10.0.0.1
 Con: Allows you to configure different IP / Port for the same server for different protocols, might be confusing. Lars-Johan Liman recommended against this. My personal preference is A followed by B. Please comment! /martin From j.schoenwaelder@jacobs-university.de Tue Jun 25 02:24:21 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6930721FA000 for ; Tue, 25 Jun 2013 02:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00rxn9kQTQvz for ; Tue, 25 Jun 2013 02:24:16 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id EEAC821F9FF2 for ; Tue, 25 Jun 2013 02:24:15 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 245FA2090B; Tue, 25 Jun 2013 11:24:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QW-FUN76GN3C; Tue, 25 Jun 2013 11:24:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48D03208C6; Tue, 25 Jun 2013 11:24:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B2BAF27012C1; Tue, 25 Jun 2013 11:24:12 +0200 (CEST) Date: Tue, 25 Jun 2013 11:24:12 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20130625092411.GA2574@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> <20130625.095641.461784957513008174.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130625.095641.461784957513008174.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 09:24:21 -0000 On Tue, Jun 25, 2013 at 09:56:41AM +0200, Martin Bjorklund wrote: > Hi, > > I would like to resolve the issue about DNS transport. > > I had a chat with Lars-Johan Liman about this, and he basically > acknowledged what we have said: the protocol architecturally supports > other transports; the default transport is a mix of UDP and TCP. I think RFC 5966 is an interesting relevant read and we likely should point to it somewhere. > Here are some alternatives, both data model and XML instance example: > > A. Explicit transport type > -------------------------- > > list server { > key name; > ... > choice transport { > case udp-and-tcp { > container udp-and-tcp { > leaf address { ... } > leaf port { ... default 53; } > } > } > } > } > > > foo > >
10.0.0.1
> > > > > Q: What is a good name for the transport? "udp-and-tcp" is a bit > awkward. The name says what it is and RFC 5966 provides some explanation under which circumstances udp and tcp is used. I think this is essential since the name "udp-and-tcp" at first glance seems to leave it open which transport is actually used once configured. > B. Implicit transport type > -------------------------- > > list server { > key name; > ... > choice transport { > case udp-and-tcp { > leaf address { ... } > leaf port { ... default 53; } > } > } > } > > > foo >
10.0.0.1
> > > > Pro: Straightforward, and still extensible > Con: Does not follow the same patterns as NTP and RADIUS. This variation simply hides the issue well. ;-) > C. Multiple transports > ---------------------- > > list server { > key name; > ... > container udp { > leaf address { ... } > leaf port { ... default 53; } > } > container tcp { > leaf address { ... } > leaf port { ... default 53; } > } > } > > > foo > >
10.0.0.1
> > >
10.0.0.1
> > > > > Con: Allows you to configure different IP / Port for the same server > for different protocols, might be confusing. Lars-Johan Liman > recommended against this. Yes, this looks non-obvious or redundant or potentially confusing. My preference is also A over B. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Tue Jun 25 05:15:06 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8932B21F8FE5 for ; Tue, 25 Jun 2013 05:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKS6ifP1kxl2 for ; Tue, 25 Jun 2013 05:15:02 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2448511E80E2 for ; Tue, 25 Jun 2013 05:15:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 194A0540177 for ; Tue, 25 Jun 2013 14:14:55 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt7uuPeLaGUS for ; Tue, 25 Jun 2013 14:14:47 +0200 (CEST) Received: from localhost (unknown [172.29.2.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 855FA540126 for ; Tue, 25 Jun 2013 14:14:43 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20130625.095641.461784957513008174.mbj@tail-f.com> References: <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> <20130625.095641.461784957513008174.mbj@tail-f.com> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 25 Jun 2013 14:14:42 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 12:15:06 -0000 Martin Bjorklund writes: > Hi, > > I would like to resolve the issue about DNS transport. > > I had a chat with Lars-Johan Liman about this, and he basically > acknowledged what we have said: the protocol architecturally supports > other transports; the default transport is a mix of UDP and TCP. Well, the fact that an application protocol can in principle be used over another transport protocol doesn't necessarily mean that a choice of transports makes sense in reality. I asked several DNS experts in my company, including active developers of two DNS servers (BIND 10 and Knot), and none of them is aware of any plans or proposals for running DNS over anything else than the standard UDP/TCP. In a similar vein, whilst NTP could possibly be run over something else than UDP, it makes little sense in reality because anything else than UDP would most likely increase the transport protocol overhead and hence latency. So, given the three alternatives, my preference would be B, because it doesn't add an extra level of hierarchy. And I'd suggest to do the same for NTP client configuration. Lada > > Here are some alternatives, both data model and XML instance example: > > A. Explicit transport type > -------------------------- > > list server { > key name; > ... > choice transport { > case udp-and-tcp { > container udp-and-tcp { > leaf address { ... } > leaf port { ... default 53; } > } > } > } > } > > > foo > >
10.0.0.1
> > > > > Q: What is a good name for the transport? "udp-and-tcp" is a bit > awkward. > > > B. Implicit transport type > -------------------------- > > list server { > key name; > ... > choice transport { > case udp-and-tcp { > leaf address { ... } > leaf port { ... default 53; } > } > } > } > > > foo >
10.0.0.1
> > > > Pro: Straightforward, and still extensible > Con: Does not follow the same patterns as NTP and RADIUS. > > > C. Multiple transports > ---------------------- > > list server { > key name; > ... > container udp { > leaf address { ... } > leaf port { ... default 53; } > } > container tcp { > leaf address { ... } > leaf port { ... default 53; } > } > } > > > foo > >
10.0.0.1
> > >
10.0.0.1
> > > > > Con: Allows you to configure different IP / Port for the same server > for different protocols, might be confusing. Lars-Johan Liman > recommended against this. > > > My personal preference is A followed by B. > > Please comment! > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Jun 25 06:54:19 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BE611E8104 for ; Tue, 25 Jun 2013 06:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjG3OfIvHYLy for ; Tue, 25 Jun 2013 06:54:17 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3338F21F9D70 for ; Tue, 25 Jun 2013 06:54:17 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id xa12so12629212pbc.39 for ; Tue, 25 Jun 2013 06:54:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=CIsC7z4y+eOly9JC5vddzm7GukRtKSEUn7qkQKYbltA=; b=ELISiNL5naLnahg6GtFIoJmF1cYJSVNyMOLUZXczMJW+8vutxCDg/rjamf1SwhyoLk P62Gv00izejTdFEIKviXP1rhRsVuptPYZSprrFRG3JkyTwj2C4ihpjmKNIJvuyFGrt2r s7eneX+izDpp4BNpQCyxj5ZGend97FDVUY7qLGCD2CascuPIMPhbDB7WZaa3ALSZ31VR /Bw67ZFNYZ/mh4tZ2aFBcDIPa5xE+GhiabgBadPu+LlJ9uaIg/iE2Odx7lF4Q0SVkfhQ dXS2GeHgH2tgtf0cNTYauDGS7le+N2BTL0MqMS188FMnwTEczZdgUDGhSD6s6yf8IPAW O4Tw== MIME-Version: 1.0 X-Received: by 10.66.163.73 with SMTP id yg9mr31111018pab.77.1372168449622; Tue, 25 Jun 2013 06:54:09 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 25 Jun 2013 06:54:09 -0700 (PDT) In-Reply-To: References: <20130619091913.GA27823@elstar.local> <20130619.120023.2027276356341059653.mbj@tail-f.com> <20130625.095641.461784957513008174.mbj@tail-f.com> Date: Tue, 25 Jun 2013 06:54:09 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=047d7b86f75e031d6504dffadd89 X-Gm-Message-State: ALoCoQkWhfFndcXjNCGWDT+eshSraNZe7n0dvKb7nwA8ko5lJPXnn8ADdqLnZqPx0l2sN/etyQVX Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 13:54:19 -0000 --047d7b86f75e031d6504dffadd89 Content-Type: text/plain; charset=ISO-8859-1 I guess (B) is fine but I wonder why we are future-proofing against something nobody plans to change. If one followed this logic to the end, then every YANG object would need to be in a choice with 1 case, because somebody in the future might want an alternative to the current solution, but still wants to use the same module. Andy On Tue, Jun 25, 2013 at 5:14 AM, Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > I would like to resolve the issue about DNS transport. > > > > I had a chat with Lars-Johan Liman about this, and he basically > > acknowledged what we have said: the protocol architecturally supports > > other transports; the default transport is a mix of UDP and TCP. > > Well, the fact that an application protocol can in principle be used over > another transport protocol doesn't necessarily mean that a choice of > transports makes sense in reality. I asked several DNS experts in my > company, including active developers of two DNS servers (BIND 10 and Knot), > and none of them is aware of any plans or proposals for running DNS over > anything else than the standard UDP/TCP. > > In a similar vein, whilst NTP could possibly be run over something else > than UDP, it makes little sense in reality because anything else than UDP > would most likely increase the transport protocol overhead and hence > latency. > > So, given the three alternatives, my preference would be B, because it > doesn't add an extra level of hierarchy. And I'd suggest to do the same for > NTP client configuration. > > Lada > > > > > Here are some alternatives, both data model and XML instance example: > > > > A. Explicit transport type > > -------------------------- > > > > list server { > > key name; > > ... > > choice transport { > > case udp-and-tcp { > > container udp-and-tcp { > > leaf address { ... } > > leaf port { ... default 53; } > > } > > } > > } > > } > > > > > > foo > > > >
10.0.0.1
> > > > > > > > > > Q: What is a good name for the transport? "udp-and-tcp" is a bit > > awkward. > > > > > > B. Implicit transport type > > -------------------------- > > > > list server { > > key name; > > ... > > choice transport { > > case udp-and-tcp { > > leaf address { ... } > > leaf port { ... default 53; } > > } > > } > > } > > > > > > foo > >
10.0.0.1
> > > > > > > > Pro: Straightforward, and still extensible > > Con: Does not follow the same patterns as NTP and RADIUS. > > > > > > C. Multiple transports > > ---------------------- > > > > list server { > > key name; > > ... > > container udp { > > leaf address { ... } > > leaf port { ... default 53; } > > } > > container tcp { > > leaf address { ... } > > leaf port { ... default 53; } > > } > > } > > > > > > foo > > > >
10.0.0.1
> > > > > >
10.0.0.1
> > > > > > > > > > Con: Allows you to configure different IP / Port for the same server > > for different protocols, might be confusing. Lars-Johan Liman > > recommended against this. > > > > > > My personal preference is A followed by B. > > > > Please comment! > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b86f75e031d6504dffadd89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess (B) is fine but I wonder why we are future-proofing against
som= ething nobody plans to change. If one followed this logic to the end, then<= /div>
every YANG object would need to be in a choice with 1 case, becau= se somebody
in the future might want an alternative to the current solution, but s= till wants
to use the same module.

Andy<= /div>


On Tue, Jun 25, 201= 3 at 5:14 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Martin Bjorklund <mbj@tail-f.com> writes:

> Hi,
>
> I would like to resolve the issue about DNS transport.
>
> I had a chat with Lars-Johan Liman about this, and he basically
> acknowledged what we have said: the protocol architecturally supports<= br> > other transports; the default transport is a mix of UDP and TCP.

Well, the fact that an application protocol can in principle be used over a= nother transport protocol doesn't necessarily mean that a choice of tra= nsports makes sense in reality. I asked several DNS experts in my company, = including active developers of two DNS servers (BIND 10 and Knot), and none= of them is aware of any plans or proposals for running DNS over anything e= lse than the standard UDP/TCP.

In a similar vein, whilst NTP could possibly be run over something else tha= n UDP, it makes little sense in reality because anything else than UDP woul= d most likely increase the transport protocol overhead and hence latency.
So, given the three alternatives, my preference would be B, because it does= n't add an extra level of hierarchy. And I'd suggest to do the same= for NTP client configuration.

Lada

>
> Here are some alternatives, both data model and XML instance example:<= br> >
> =A0 A. Explicit transport type
> =A0 --------------------------
>
> =A0 list server {
> =A0 =A0 key name;
> =A0 =A0 ...
> =A0 =A0 choice transport {
> =A0 =A0 =A0 case udp-and-tcp {
> =A0 =A0 =A0 =A0 container udp-and-tcp {
> =A0 =A0 =A0 =A0 =A0 leaf address { ... }
> =A0 =A0 =A0 =A0 =A0 leaf port { ... default 53; }
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 }
> =A0 =A0 }
> =A0 }
>
> =A0 =A0<server>
> =A0 =A0 =A0<name>foo</name>
> =A0 =A0 =A0<udp-and-tcp>
> =A0 =A0 =A0 =A0<address>10.0.0.1</address>
> =A0 =A0 =A0</udp-and-tcp>
> =A0 =A0</server>
>
>
> =A0 Q: What is a good name for the transport? =A0"udp-and-tcp&quo= t; is a bit
> =A0 =A0 =A0awkward.
>
>
> =A0 B. Implicit transport type
> =A0 --------------------------
>
> =A0 list server {
> =A0 =A0 key name;
> =A0 =A0 ...
> =A0 =A0 choice transport {
> =A0 =A0 =A0 case udp-and-tcp {
> =A0 =A0 =A0 =A0 leaf address { ... }
> =A0 =A0 =A0 =A0 leaf port { ... default 53; }
> =A0 =A0 =A0 }
> =A0 =A0 }
> =A0 }
>
> =A0 =A0<server>
> =A0 =A0 =A0<name>foo</name>
> =A0 =A0 =A0<address>10.0.0.1</address>
> =A0 =A0</server>
>
>
> =A0 Pro: Straightforward, and still extensible
> =A0 Con: Does not follow the same patterns as NTP and RADIUS.
>
>
> =A0 C. Multiple transports
> =A0 ----------------------
>
> =A0 list server {
> =A0 =A0 key name;
> =A0 =A0 ...
> =A0 =A0 container udp {
> =A0 =A0 =A0 leaf address { ... }
> =A0 =A0 =A0 leaf port { ... default 53; }
> =A0 =A0 }
> =A0 =A0 container tcp {
> =A0 =A0 =A0 leaf address { ... }
> =A0 =A0 =A0 leaf port { ... default 53; }
> =A0 =A0 }
> =A0 }
>
> =A0 =A0<server>
> =A0 =A0 =A0<name>foo</name>
> =A0 =A0 =A0<udp>
> =A0 =A0 =A0 =A0<address>10.0.0.1</address>
> =A0 =A0 =A0</udp>
> =A0 =A0 =A0<tcp>
> =A0 =A0 =A0 =A0<address>10.0.0.1</address>
> =A0 =A0 =A0</tcp>
> =A0 =A0</server>
>
>
> =A0 Con: Allows you to configure different IP / Port for the same serv= er
> =A0 =A0 =A0 =A0for different protocols, might be confusing. =A0Lars-Jo= han Liman
> =A0 =A0 =A0 =A0recommended against this.
>
>
> My personal preference is A followed by B.
>
> Please comment!
>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7b86f75e031d6504dffadd89-- From mbj@tail-f.com Tue Jun 25 07:40:13 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D3721E80D2 for ; Tue, 25 Jun 2013 07:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e28kjGYxo8sV for ; Tue, 25 Jun 2013 07:40:07 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3D25721E80B8 for ; Tue, 25 Jun 2013 07:40:06 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 7D8231200D95; Tue, 25 Jun 2013 16:40:04 +0200 (CEST) Date: Tue, 25 Jun 2013 16:40:04 +0200 (CEST) Message-Id: <20130625.164004.62490750896636707.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20130625.095641.461784957513008174.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 14:40:13 -0000 Andy Bierman wrote: > I guess (B) is fine but I wonder why we are future-proofing against > something nobody plans to change. If one followed this logic to the end, > then > every YANG object would need to be in a choice with 1 case, because somebody > in the future might want an alternative to the current solution, but still > wants > to use the same module. I don't think this is the right conclusion from this logic. It was Juergen who pointed out that if the protocol architecturally supports multiple transports, we should allow this in the data model, even if there is only one transport currently in use. /martin From lhotka@nic.cz Tue Jun 25 08:17:02 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CE221F9B8C for ; Tue, 25 Jun 2013 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.811 X-Spam-Level: X-Spam-Status: No, score=-1.811 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoXVu+QfJfqM for ; Tue, 25 Jun 2013 08:17:02 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id E27EA21F9B4A for ; Tue, 25 Jun 2013 08:17:01 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 843F913F66A; Tue, 25 Jun 2013 17:16:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1372173419; bh=Jp4ene0OktDb+SMtiqG46yx9kv3EqlI2tyAtZPYhQYY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=NmGBgINaNSPXf8o4EB0Ejk8CBVzFHxm4Txwr1/4mDgGxep/jfm5MulSIke6nWho4d bgzoTxrOqqZoUg21cJrIIc6GdhFTPaaPlfYLKGUnVW6vAeVgtIn9DRGv+iB2qko+Xq FXMMRsiL6pQ9qeExmmO8/q/tv25j4O1NjUynKzAU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: <20130625.164004.62490750896636707.mbj@tail-f.com> Date: Tue, 25 Jun 2013 17:16:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4ADA5704-CD0F-46DB-8C23-3CB260EDBB81@nic.cz> References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:17:02 -0000 On Jun 25, 2013, at 4:40 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> I guess (B) is fine but I wonder why we are future-proofing against >> something nobody plans to change. If one followed this logic to the = end, >> then >> every YANG object would need to be in a choice with 1 case, because = somebody >> in the future might want an alternative to the current solution, but = still >> wants >> to use the same module. I agree with Andy. >=20 > I don't think this is the right conclusion from this logic. It was > Juergen who pointed out that if the protocol architecturally supports > multiple transports, we should allow this in the data model, even if > there is only one transport currently in use. If I remember correctly, the scope for the initial set of modules was to = take into account what the current standards, commonly used devices and = service implementations support. Future-proofing against generalisations = that are nowhere is sight leads to unnecessary complications that will = not make the modules more attractive - just the opposite. Lada >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Jun 25 08:46:56 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D765921F9983 for ; Tue, 25 Jun 2013 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S47pCGExcWYA for ; Tue, 25 Jun 2013 08:46:56 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDF421F9982 for ; Tue, 25 Jun 2013 08:46:52 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so12790555pbb.27 for ; Tue, 25 Jun 2013 08:46:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Egzpo9YA9V/QCd7l9TWTOd2c/cpg+nDg/1HPsAWqDzo=; b=Gy8gvNxFCcrnO6tbtE2sP2vQ8C37mUC40QeO6LTxoc+VXZd/Op7R/F+Av/6UN6WlbI vz1FZmk4liDdFvo2lx2H8XwG6C9zjoNtwUkyRJ3LQia43KRj9ZZ7v03EZSeQuTcDA9Oi MsEMZnQxtHyIU1mLaKULL8sk7l1hDs0oB6PT6zan6ZA4swv26msPj87VC9/7H0ZMZYXS T4KpG1F8RsHM6PwzcExcPrDZbzP7CWAlXZYSecdhO0J4aZ3bUdh7he4A90e78ip7XEJc Ex2d9HQXyEp1+aytC99464vwOS8T6JkJ87gjBdGUUhf97Me685RgPPjb224PIg1d8DMA qztg== MIME-Version: 1.0 X-Received: by 10.66.183.196 with SMTP id eo4mr356479pac.156.1372175212593; Tue, 25 Jun 2013 08:46:52 -0700 (PDT) Received: by 10.70.131.135 with HTTP; Tue, 25 Jun 2013 08:46:52 -0700 (PDT) In-Reply-To: <4ADA5704-CD0F-46DB-8C23-3CB260EDBB81@nic.cz> References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> <4ADA5704-CD0F-46DB-8C23-3CB260EDBB81@nic.cz> Date: Tue, 25 Jun 2013 08:46:52 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=047d7bdc17041dd79104dffc70b7 X-Gm-Message-State: ALoCoQkf6JlszUt2CbaMQ8bEaiZXjPHBkviRrHTuL6wxG4UWBtbKTqOnKjExRKO31HmnIQR/ZsmN Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 15:46:56 -0000 --047d7bdc17041dd79104dffc70b7 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 25, 2013 at 8:16 AM, Ladislav Lhotka wrote: > > On Jun 25, 2013, at 4:40 PM, Martin Bjorklund wrote: > > > Andy Bierman wrote: > >> I guess (B) is fine but I wonder why we are future-proofing against > >> something nobody plans to change. If one followed this logic to the end, > >> then > >> every YANG object would need to be in a choice with 1 case, because > somebody > >> in the future might want an alternative to the current solution, but > still > >> wants > >> to use the same module. > > I agree with Andy. > > > > > I don't think this is the right conclusion from this logic. It was > > Juergen who pointed out that if the protocol architecturally supports > > multiple transports, we should allow this in the data model, even if > > there is only one transport currently in use. > > If I remember correctly, the scope for the initial set of modules was to > take into account what the current standards, commonly used devices and > service implementations support. Future-proofing against generalisations > that are nowhere is sight leads to unnecessary complications that will not > make the modules more attractive - just the opposite. > > I don't might solution (B), but it does presume that we know any other transport added in the future will not use address and/or port (because they can't if it's in a choice). YANG also provides must-stmt and when-stmt, so new objects added in the future can enforce whatever usage of address/port they need. > Lada > Andy > > > > > > > /martin > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --047d7bdc17041dd79104dffc70b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 25, 2013 at 8:16 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.= com> wrote:
>> I guess (B) is fine but I wonder why we are future-proofing agains= t
>> something nobody plans to change. If one followed this logic to th= e end,
>> then
>> every YANG object would need to be in a choice with 1 case, becaus= e somebody
>> in the future might want an alternative to the current solution, b= ut still
>> wants
>> to use the same module.

I agree with Andy.

>
> I don't think this is the right conclusion from this logic. =A0It = was
> Juergen who pointed out that if the protocol architecturally supports<= br> > multiple transports, we should allow this in the data model, even if > there is only one transport currently in use.

If I remember correctly, the scope for the initial set of modules was to ta= ke into account what the current standards, commonly used devices and servi= ce implementations support. Future-proofing against generalisations that ar= e nowhere is sight leads to unnecessary complications that will not make th= e modules more attractive - just the opposite.


I don't might solution (B), but it= does presume that we know any other
transport added in the futur= e will not use address and/or port (because they
can't if it&= #39;s in a choice).


YANG also provides must-stmt and when-st= mt, so new objects added
in the future can enforce whatever usage= of address/port they need.

=A0
Lada

Andy

=A0<= /div>

>
>
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--047d7bdc17041dd79104dffc70b7-- From lhotka@nic.cz Tue Jun 25 09:03:14 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E6711E810F for ; Tue, 25 Jun 2013 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAuhJB4elEN5 for ; Tue, 25 Jun 2013 09:03:13 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95711E80F5 for ; Tue, 25 Jun 2013 09:03:13 -0700 (PDT) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 28DC913F66A for ; Tue, 25 Jun 2013 18:03:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1372176192; bh=oWqCVIfx3ImwxBXn9Ci59F5+fORFCNLIBD5IMIFJZX4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=uYGQjMrdOJs6MnF34wYh9eeeF/aw6rX9ZZenb0FCwU1zrRqvy6HpppByWZUKNsFEY Yl9LCbN+zrAlEHPRsPSWzz7/uCHGKt8AUjR0jl/LDoDprQfySwvEC1mI+PDsJrxsp5 +h5XqQP82SO0gBKpbt1hYaronorSoNqKYs9as0UQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ladislav Lhotka In-Reply-To: Date: Tue, 25 Jun 2013 18:03:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B6D9643-706F-4F54-8CF8-26F3E3259979@nic.cz> References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> <4ADA5704-CD0F-46DB-8C23-3CB260EDBB81@nic.cz> To: netmod@ietf.org X-Mailer: Apple Mail (2.1508) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:03:14 -0000 On Jun 25, 2013, at 5:46 PM, Andy Bierman wrote: >=20 >=20 > On Tue, Jun 25, 2013 at 8:16 AM, Ladislav Lhotka = wrote: >=20 > On Jun 25, 2013, at 4:40 PM, Martin Bjorklund wrote: >=20 >> Andy Bierman wrote: >>> I guess (B) is fine but I wonder why we are future-proofing against >>> something nobody plans to change. If one followed this logic to the = end, >>> then >>> every YANG object would need to be in a choice with 1 case, because = somebody >>> in the future might want an alternative to the current solution, but = still >>> wants >>> to use the same module. >=20 > I agree with Andy. >=20 >>=20 >> I don't think this is the right conclusion from this logic. It was >> Juergen who pointed out that if the protocol architecturally supports >> multiple transports, we should allow this in the data model, even if >> there is only one transport currently in use. >=20 > If I remember correctly, the scope for the initial set of modules was = to take into account what the current standards, commonly used devices = and service implementations support. Future-proofing against = generalisations that are nowhere is sight leads to unnecessary = complications that will not make the modules more attractive - just the = opposite. >=20 >=20 > I don't might solution (B), but it does presume that we know any other > transport added in the future will not use address and/or port = (because they > can't if it's in a choice). Why not, if they are defined in a different module/namespace? Lada >=20 >=20 > YANG also provides must-stmt and when-stmt, so new objects added > in the future can enforce whatever usage of address/port they need. >=20 >=20 > Lada >=20 > Andy >=20 >=20 >=20 >>=20 >>=20 >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Tue Jun 25 09:23:38 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB60B11E812A for ; Tue, 25 Jun 2013 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.222 X-Spam-Level: * X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpEuXi-E099f for ; Tue, 25 Jun 2013 09:23:10 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3A52611E8113 for ; Tue, 25 Jun 2013 09:21:53 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id kl14so12796162pab.6 for ; Tue, 25 Jun 2013 09:21:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=vaRbt3MmEgxll7YOLdPo95deoikqJuhVFI28QWG4NUI=; b=GieTurwDLNx8+YRxbxV1lm+MrvEyGLdetyldBQERnR3oTPIjrMWjx4F0zII8cfnQ2a sUQjFsRpHHJPD72K7RuNKH5cjTSHRJmlsiN1j3XjiXX/1LKZkBvKdLV1ZHuS4C3QdfhJ jwwVHv/kVUOR7j7F6cslzq3GqYCLg5v7GKX8NX3s/ycL6BExJwgI30uTo9iTY9a/3Kuc kNgUisF8QUmNndrRkoi8vi/E6f9jwMKj3NXHFpQG9kRazJJVQIkEx1N7VUTk/Y87EJvN 69XSpKb00FdQJH56ZqjZoLULlx6E91b6zQsANOuW3G6w4CUw1Qsj751qNNB/2OaT5xHv 3k1Q== MIME-Version: 1.0 X-Received: by 10.68.20.33 with SMTP id k1mr29582670pbe.168.1372177312924; Tue, 25 Jun 2013 09:21:52 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 25 Jun 2013 09:21:52 -0700 (PDT) In-Reply-To: <9B6D9643-706F-4F54-8CF8-26F3E3259979@nic.cz> References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> <4ADA5704-CD0F-46DB-8C23-3CB260EDBB81@nic.cz> <9B6D9643-706F-4F54-8CF8-26F3E3259979@nic.cz> Date: Tue, 25 Jun 2013 09:21:52 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=bcaec52162414e596604dffced57 X-Gm-Message-State: ALoCoQnQWe6Nuc6b78zKbDtoALxbwWUcxOyEWuySPBXT/CmOaNXsFTucNVTF7bHKo+z/iQqH+av4 Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:23:43 -0000 --bcaec52162414e596604dffced57 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 25, 2013 at 9:03 AM, Ladislav Lhotka wrote: > > On Jun 25, 2013, at 5:46 PM, Andy Bierman wrote: > > > > > > > On Tue, Jun 25, 2013 at 8:16 AM, Ladislav Lhotka wrote: > > > > On Jun 25, 2013, at 4:40 PM, Martin Bjorklund wrote: > > > >> Andy Bierman wrote: > >>> I guess (B) is fine but I wonder why we are future-proofing against > >>> something nobody plans to change. If one followed this logic to the > end, > >>> then > >>> every YANG object would need to be in a choice with 1 case, because > somebody > >>> in the future might want an alternative to the current solution, but > still > >>> wants > >>> to use the same module. > > > > I agree with Andy. > > > >> > >> I don't think this is the right conclusion from this logic. It was > >> Juergen who pointed out that if the protocol architecturally supports > >> multiple transports, we should allow this in the data model, even if > >> there is only one transport currently in use. > > > > If I remember correctly, the scope for the initial set of modules was to > take into account what the current standards, commonly used devices and > service implementations support. Future-proofing against generalisations > that are nowhere is sight leads to unnecessary complications that will not > make the modules more attractive - just the opposite. > > > > > > I don't might solution (B), but it does presume that we know any other > > transport added in the future will not use address and/or port (because > they > > can't if it's in a choice). > > Why not, if they are defined in a different module/namespace? > > You're right. I was assuming the reason we need a choice with 1 case is so more cases can be added directly to this module later, but it could be indirectly via augment-stmt as well. Lada > > Andy > > > > > > YANG also provides must-stmt and when-stmt, so new objects added > > in the future can enforce whatever usage of address/port they need. > > > > > > Lada > > > > Andy > > > > > > > >> > >> > >> /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > > > > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --bcaec52162414e596604dffced57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jun 25, 2013 at 9:03 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> wrote:

>
>
> On Tue, Jun 25, 2013 at 8:16 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On Jun 25, 2013, at 4:40 PM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Andy Bierman <andy@yumawo= rks.com> wrote:
>>> I guess (B) is fine but I wonder why we are future-proofing ag= ainst
>>> something nobody plans to change. If one followed this logic t= o the end,
>>> then
>>> every YANG object would need to be in a choice with 1 case, be= cause somebody
>>> in the future might want an alternative to the current solutio= n, but still
>>> wants
>>> to use the same module.
>
> I agree with Andy.
>
>>
>> I don't think this is the right conclusion from this logic. = =A0It was
>> Juergen who pointed out that if the protocol architecturally suppo= rts
>> multiple transports, we should allow this in the data model, even = if
>> there is only one transport currently in use.
>
> If I remember correctly, the scope for the initial set of modules was = to take into account what the current standards, commonly used devices and = service implementations support. Future-proofing against generalisations th= at are nowhere is sight leads to unnecessary complications that will not ma= ke the modules more attractive - just the opposite.
>
>
> I don't might solution (B), but it does presume that we know any o= ther
> transport added in the future will not use address and/or port (becaus= e they
> can't if it's in a choice).

Why not, if they are defined in a different module/namespace?


You're right.
I was assu= ming the reason we need a choice with 1 case is so
more cases can= be added directly to this module later, but it
could be indirect= ly via augment-stmt as well.


Lada


Andy
=A0
>
>
> YANG also provides must-stmt and when-stmt, so new objects added
> in the future can enforce whatever usage of address/port they need. >
>
> Lada
>
> Andy
>
>
>
>>
>>
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--bcaec52162414e596604dffced57-- From ietfdbh@comcast.net Tue Jun 25 13:01:52 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA1E21E804D for ; Tue, 25 Jun 2013 13:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exE3m22FPyIu for ; Tue, 25 Jun 2013 13:01:48 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1BB21E80D5 for ; Tue, 25 Jun 2013 13:01:42 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id sgyo1l0081ZXKqc5Ek1hVS; Tue, 25 Jun 2013 20:01:41 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta21.westchester.pa.mail.comcast.net with comcast id sk1g1l01d2yZEBF3hk1hDh; Tue, 25 Jun 2013 20:01:41 +0000 From: "ietfdbh" To: "'Martin Bjorklund'" , References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> In-Reply-To: <20130625.164004.62490750896636707.mbj@tail-f.com> Date: Tue, 25 Jun 2013 16:01:26 -0400 Message-ID: <01ff01ce71de$c6e55600$54b00200$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHSBfy26L+Mc0OKDpl+iNqJO6TSUAGiOmQqAnGohTQBrY0EtJkRpfMw Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372190501; bh=dRgkms/S9OM6yhtsI8o60tBx0tqRybZkMhiKOcj1Er4=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=O+JAZ5vxOLQNHLvSs794ctodb6ad9pkacHpz8Vakmx2C0pyIrrCleaJe7cJaKwoR6 wIx4d3Z4CSzq1/WCYa9W47Tj6WCDP6/QqRqwdrrHY9OAauHjRb2TYA2N7kMRam1vbn Z+UK7e37KRv8PA+fQ3dj++x64KXsu9HM0zLS/GwcOpl6223q/TAM3q9nGLFSMQD7qt NbPYKyp0srNpKINlsV2pZjDcfi2W4HiroCozqBVn4BKP6HM62V3vs8EADSjXPbGsyJ T0S7bbPkK5ZfzKsnp0Ixvi8VALFm6o0tR3u3qUdRRL2zfSDHqr9kTumcFmbGhtDFYg PZR+LOluJ/4nw== Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 20:01:52 -0000 +1 David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Tuesday, June 25, 2013 10:40 AM To: andy@yumaworks.com Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt Andy Bierman wrote: > I guess (B) is fine but I wonder why we are future-proofing against > something nobody plans to change. If one followed this logic to the > end, then every YANG object would need to be in a choice with 1 case, > because somebody in the future might want an alternative to the > current solution, but still wants to use the same module. I don't think this is the right conclusion from this logic. It was Juergen who pointed out that if the protocol architecturally supports multiple transports, we should allow this in the data model, even if there is only one transport currently in use. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From andy@yumaworks.com Tue Jun 25 14:06:30 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83D821F99D9 for ; Tue, 25 Jun 2013 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=1.599, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbvSaIAbWpJI for ; Tue, 25 Jun 2013 14:06:30 -0700 (PDT) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D1CD221F9C35 for ; Tue, 25 Jun 2013 14:06:29 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id jt11so13007178pbb.8 for ; Tue, 25 Jun 2013 14:06:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DqGBQaMMC4jUvoN4EDhzj1Fn6QT4mp3tYo1z4/LgVPA=; b=D8so0necTA8qu+PeaKyIto41CVcLekfTB+bNqUmf+mkTIZq00zSldy+UsoUqhTYoQv 3OgI4J6N6LXHJK4MgjNQVwKfvHZQmfJD2vkmtUEN8JyLbgCWqj+bqEEtRz2m35F3el6M G0Zk17M83JvEJzw7rBGyc41LyusdOsT9amQgLFc6c0lT6GKhksg2idMrtU5I+n+vVwFJ W+F7yNWxSV4KgcGqLf+bborSPvfYMIaj8bhq7pAlRY0ceCzems6fNHtxcmVY8qxQGWDC Dg9TFAvBQdgZCC2a+P/Xs2bY04wNqYoqTW0Zo7ld7APuVNIELtfP65gqSjlHD1d4ITls f8cw== MIME-Version: 1.0 X-Received: by 10.66.178.174 with SMTP id cz14mr1620969pac.136.1372194386656; Tue, 25 Jun 2013 14:06:26 -0700 (PDT) Received: by 10.70.12.161 with HTTP; Tue, 25 Jun 2013 14:06:26 -0700 (PDT) In-Reply-To: <01ff01ce71de$c6e55600$54b00200$@comcast.net> References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> <01ff01ce71de$c6e55600$54b00200$@comcast.net> Date: Tue, 25 Jun 2013 14:06:26 -0700 Message-ID: From: Andy Bierman To: ietfdbh Content-Type: multipart/alternative; boundary=047d7bea2e8afacfc404e000e690 X-Gm-Message-State: ALoCoQl9g8J8BHz4WNRXLbNSkLqPX99esy7pQjHNI7Iunvzh2HHKdopKN0ME3Mk+HRq+R1nnkF2X Cc: netmod@ietf.org Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 21:06:30 -0000 --047d7bea2e8afacfc404e000e690 Content-Type: text/plain; charset=ISO-8859-1 OK you convinced me this is a special case where choice-of-1 is a good idea. Andy On Tue, Jun 25, 2013 at 1:01 PM, ietfdbh wrote: > +1 > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf > Of > Martin Bjorklund > Sent: Tuesday, June 25, 2013 10:40 AM > To: andy@yumaworks.com > Cc: netmod@ietf.org > Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt > > Andy Bierman wrote: > > I guess (B) is fine but I wonder why we are future-proofing against > > something nobody plans to change. If one followed this logic to the > > end, then every YANG object would need to be in a choice with 1 case, > > because somebody in the future might want an alternative to the > > current solution, but still wants to use the same module. > > I don't think this is the right conclusion from this logic. It was Juergen > who pointed out that if the protocol architecturally supports multiple > transports, we should allow this in the data model, even if there is only > one transport currently in use. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --047d7bea2e8afacfc404e000e690 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK you convinced me this is a special case where choice-of-1 is a good idea= .


Andy


On Tue, Jun 25, 2013 at 1:01 PM, ietfdbh <<= a href=3D"mailto:ietfdbh@comcast.net" target=3D"_blank">ietfdbh@comcast.net= > wrote:
+1

David Harrington
ietfdbh@comcast.net
+1-603-828-1401

-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.or= g] On Behalf Of
Martin Bjorklund
Sent: Tuesday, June 25, 2013 10:40 AM
To: andy@yumaworks.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt=

Andy Bierman <andy@yumaworks.com> wrote:
> I guess (B) is fine but I wonder why we are future-proofing against > something nobody plans to change. If one followed this logic to the > end, then every YANG object would need to be in a choice with 1 case,<= br> > because somebody in the future might want an alternative to the
> current solution, but still wants to use the same module.

I don't think this is the right conclusion from this logic. =A0It was J= uergen
who pointed out that if the protocol architecturally supports multiple
transports, we should allow this in the data model, even if there is only one transport currently in use.


/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod


--047d7bea2e8afacfc404e000e690-- From lhotka@nic.cz Wed Jun 26 04:13:59 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6570821E8121 for ; Wed, 26 Jun 2013 04:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_CZ=0.904, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPcKW7JW5cFN for ; Wed, 26 Jun 2013 04:13:54 -0700 (PDT) Received: from trail.lhotka.name (nat-5.bravonet.cz [77.48.224.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF0721E8119 for ; Wed, 26 Jun 2013 04:13:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 03FD4540385 for ; Wed, 26 Jun 2013 13:13:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx9UIzlV6aDI for ; Wed, 26 Jun 2013 13:13:38 +0200 (CEST) Received: from localhost (fw.nic.cz [217.31.207.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E757A540010 for ; Wed, 26 Jun 2013 13:13:32 +0200 (CEST) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> <01ff01ce71de$c6e55600$54b00200$@comcast.net> User-Agent: Notmuch/0.15.2 (http://notmuchmail.org) Emacs/23.4.1 (x86_64-apple-darwin12.3.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 26 Jun 2013 13:13:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 11:13:59 -0000 Andy Bierman writes: > OK you convinced me this is a special case where choice-of-1 is a good idea. This was not my intention, I only expressed my preference among the three choices that Martin offerred. I think we should carefully judge where the choice of transport protocol makes sense, and I am not convinced it is the case of DNS resolver and NTP client configuration. Option (B) is a compromise in that it doesn't introduce any extra data nodes, but it is still detrimental to the module readability. Lada > > > Andy > > > On Tue, Jun 25, 2013 at 1:01 PM, ietfdbh wrote: > >> +1 >> >> David Harrington >> ietfdbh@comcast.net >> +1-603-828-1401 >> >> -----Original Message----- >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf >> Of >> Martin Bjorklund >> Sent: Tuesday, June 25, 2013 10:40 AM >> To: andy@yumaworks.com >> Cc: netmod@ietf.org >> Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt >> >> Andy Bierman wrote: >> > I guess (B) is fine but I wonder why we are future-proofing against >> > something nobody plans to change. If one followed this logic to the >> > end, then every YANG object would need to be in a choice with 1 case, >> > because somebody in the future might want an alternative to the >> > current solution, but still wants to use the same module. >> >> I don't think this is the right conclusion from this logic. It was Juergen >> who pointed out that if the protocol architecturally supports multiple >> transports, we should allow this in the data model, even if there is only >> one transport currently in use. >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Jun 26 05:58:57 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E48F11E81C1 for ; Wed, 26 Jun 2013 05:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.611 X-Spam-Level: X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJK4LBc6Y1-Y for ; Wed, 26 Jun 2013 05:58:57 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id E652711E81BF for ; Wed, 26 Jun 2013 05:58:56 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so14097834pad.9 for ; Wed, 26 Jun 2013 05:58:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=fWo7vMuPoejMQthHdtlx4QkDGXcCOWTCQ4cy0ziW8Ro=; b=KhQ2wEJR+aLb6LRi8ak3cgr4/GaMCiesile/L6FMHwJAoxrQVCIYiaFAFY1NUtiwzB VCgcVTxpInS5O6X2YcoBBWvK7I+z6YH6e8l6VtptMYW8fs1m73t6yz0mSpRm+XlrqrKE qdR2xg2lTRCcXy/cjUfml58v7aUihrCEHw7Jc6BBZIDAyhszHYJWz4ElgEfbwepHP7bU zvdgzlsThvfkCHZIBxU3NDZCfOFeWuHl81SkUYhP0Il8dxrERjUq9iLCXkjJrsKbYM+D uyMyHOrOwU6eBMVqkzFev3V9MWXHJhh1QimPxf7Ka+WOpSYlGyyJVVopkNpWZVmIluEF dSdg== MIME-Version: 1.0 X-Received: by 10.68.240.72 with SMTP id vy8mr540380pbc.161.1372251536570; Wed, 26 Jun 2013 05:58:56 -0700 (PDT) Received: by 10.70.48.233 with HTTP; Wed, 26 Jun 2013 05:58:56 -0700 (PDT) In-Reply-To: References: <20130625.095641.461784957513008174.mbj@tail-f.com> <20130625.164004.62490750896636707.mbj@tail-f.com> <01ff01ce71de$c6e55600$54b00200$@comcast.net> Date: Wed, 26 Jun 2013 05:58:56 -0700 Message-ID: From: Andy Bierman To: netmod@ietf.org Content-Type: multipart/alternative; boundary=047d7b339d1f61503b04e00e35ec X-Gm-Message-State: ALoCoQmZw3aSe6BqVysfLi9C98WQfPg+j1QaI1IlCbhXysjaNqQdmjNxqP6YhZvgzVTNMOnmAZlH Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mgmt-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 12:58:57 -0000 --047d7b339d1f61503b04e00e35ec Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 26, 2013 at 4:13 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > OK you convinced me this is a special case where choice-of-1 is a good > idea. > > This was not my intention, I only expressed my preference among the three > choices that Martin offerred. I think we should carefully judge where the > choice of transport protocol makes sense, and I am not convinced it is the > case of DNS resolver and NTP client configuration. Option (B) is a > compromise in that it doesn't introduce any extra data nodes, but it is > still detrimental to the module readability. > > Maybe 'good' is over-stating it -- it is acceptable because the transport is allowed to change in the future. This is the sort of thing you have to do with YANG in the absence of a robust conformance model. Lada > Andy > > > > > > > Andy > > > > > > On Tue, Jun 25, 2013 at 1:01 PM, ietfdbh wrote: > > > >> +1 > >> > >> David Harrington > >> ietfdbh@comcast.net > >> +1-603-828-1401 > >> > >> -----Original Message----- > >> From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On > Behalf > >> Of > >> Martin Bjorklund > >> Sent: Tuesday, June 25, 2013 10:40 AM > >> To: andy@yumaworks.com > >> Cc: netmod@ietf.org > >> Subject: Re: [netmod] Fwd: I-D Action: > draft-ietf-netmod-system-mgmt-07.txt > >> > >> Andy Bierman wrote: > >> > I guess (B) is fine but I wonder why we are future-proofing against > >> > something nobody plans to change. If one followed this logic to the > >> > end, then every YANG object would need to be in a choice with 1 case, > >> > because somebody in the future might want an alternative to the > >> > current solution, but still wants to use the same module. > >> > >> I don't think this is the right conclusion from this logic. It was > Juergen > >> who pointed out that if the protocol architecturally supports multiple > >> transports, we should allow this in the data model, even if there is > only > >> one transport currently in use. > >> > >> > >> /martin > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > >> > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --047d7b339d1f61503b04e00e35ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 26, 2013 at 4:13 AM, Ladisla= v Lhotka <lhotka@nic.cz> wrote:
andy@yumaworks.com> writes:

> OK you convinced me this is a special case where choice-of-1 is a good= idea.

This was not my intention, I only expressed my preference among the three c= hoices that Martin offerred. I think we should carefully judge where the ch= oice of transport protocol makes sense, and I am not convinced it is the ca= se of DNS resolver and NTP client configuration. Option (B) is a compromise= in that it doesn't introduce any extra data nodes, but it is still det= rimental to the module readability.


Maybe 'good' is over-stating i= t -- it is acceptable because the transport is allowed to change
= in the future. =A0This is the sort of thing you have to do with YANG in the=
absence of a robust conformance model.


Lada

Andy

=A0<= /div>

>
>
> Andy
>
>
> On Tue, Jun 25, 2013 at 1:01 PM, ietfdbh <ietfdbh@comcast.net> wrote:
>
>> +1
>>
>> David Harrington
>> ietfdbh@comcast.net
>> +1-603-828-1401
>>
>> -----Original Message-----
>> From: netmod-bounces@ie= tf.org [mailto:netmod-bounce= s@ietf.org] On Behalf
>> Of
>> Martin Bjorklund
>> Sent: Tuesday, June 25, 2013 10:40 AM
>> To: andy@yumaworks.com >> Cc: netmod@ietf.org
>> Subject: Re: [netmod] Fwd: I-D Action: draft-ietf-netmod-system-mg= mt-07.txt
>>
>> Andy Bierman <andy@yumawo= rks.com> wrote:
>> > I guess (B) is fine but I wonder why we are future-proofing a= gainst
>> > something nobody plans to change. If one followed this logic = to the
>> > end, then every YANG object would need to be in a choice with= 1 case,
>> > because somebody in the future might want an alternative to t= he
>> > current solution, but still wants to use the same module.
>>
>> I don't think this is the right conclusion from this logic. = =A0It was Juergen
>> who pointed out that if the protocol architecturally supports mult= iple
>> transports, we should allow this in the data model, even if there = is only
>> one transport currently in use.
>>
>>
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
= https://www.ietf.org/mailman/listinfo/netmod

--047d7b339d1f61503b04e00e35ec-- From j.schoenwaelder@jacobs-university.de Fri Jun 28 00:54:51 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF63921F9ED1 for ; Fri, 28 Jun 2013 00:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.65 X-Spam-Level: X-Spam-Status: No, score=-100.65 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2QiJp3TNQQoy for ; Fri, 28 Jun 2013 00:54:42 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id F080D21F9DB7 for ; Fri, 28 Jun 2013 00:54:41 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12A99209D7; Fri, 28 Jun 2013 09:54:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m9zCZ-8m4K-K; Fri, 28 Jun 2013 09:54:40 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B15A20BC1; Fri, 28 Jun 2013 09:54:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 20ECA2707BCE; Fri, 28 Jun 2013 09:54:37 +0200 (CEST) Date: Fri, 28 Jun 2013 09:54:37 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20130628075437.GA2600@elstar.local> Mail-Followup-To: netmod@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] draft agenda for the berlin ietf meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:54:51 -0000 Hi, the NETMOD session is currently scheduled like this: netmod Session 1 (1:30:00) Thursday, Afternoon Session III 1700-1830 Room Name: Tiergarten 1/2 The NETCONF session is currently scheduled like this: netconf Session 1 (1:00:00) Wednesday, Afternoon Session II 1510-1610 Room Name: Charlottenburg 1 https://datatracker.ietf.org/meeting/87/agenda.html /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From mehmet.ersue@nsn.com Fri Jun 28 09:16:27 2013 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDD321F9BC8 for ; Fri, 28 Jun 2013 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.062 X-Spam-Level: X-Spam-Status: No, score=-106.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z58oXeu0U8VC for ; Fri, 28 Jun 2013 09:16:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1B21F9B94 for ; Fri, 28 Jun 2013 09:16:08 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5SGG7D7029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jun 2013 18:16:07 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5SGG6a0003305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 18:16:06 +0200 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 28 Jun 2013 18:16:06 +0200 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.45]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Fri, 28 Jun 2013 18:16:06 +0200 From: "Ersue, Mehmet (NSN - DE/Munich)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] draft agenda for the berlin ietf meeting Thread-Index: AQHOc9THCOr/lpwvvUyHXm34u3XmuplLTQSw Date: Fri, 28 Jun 2013 16:16:05 +0000 Message-ID: References: <20130628075437.GA2600@elstar.local> In-Reply-To: <20130628075437.GA2600@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1336 X-purgate-ID: 151667::1372436167-000017BA-CA559432/0-0/0-0 Subject: Re: [netmod] draft agenda for the berlin ietf meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:16:27 -0000 There are actually two Netconf sessions on the agenda: Wednesday, Afternoon Session II 1510-1610 Room Name: Charlottenburg 1 and Wednesday, Afternoon Session III 1620-1720 Room Name: Charlottenburg 1 Cheers,=20 Mehmet=20 > -----Original Message----- > From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf = Of ext > Juergen Schoenwaelder > Sent: Friday, June 28, 2013 9:55 AM > To: netmod@ietf.org > Subject: [netmod] draft agenda for the berlin ietf meeting >=20 > Hi, >=20 > the NETMOD session is currently scheduled like this: >=20 > netmod Session 1 (1:30:00) > Thursday, Afternoon Session III 1700-1830 > Room Name: Tiergarten 1/2 >=20 > The NETCONF session is currently scheduled like this: >=20 > netconf Session 1 (1:00:00) > Wednesday, Afternoon Session II 1510-1610 > Room Name: Charlottenburg 1 >=20 > https://datatracker.ietf.org/meeting/87/agenda.html >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod