Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
Andy Bierman <andy@yumaworks.com> Thu, 12 December 2013 20:52 UTC
Return-Path: <andy@yumaworks.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1D1AE4B8 for <netmod@ietfa.amsl.com>; Thu, 12 Dec 2013 12:52:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUtrMpiGFH5i for <netmod@ietfa.amsl.com>; Thu, 12 Dec 2013 12:52:51 -0800 (PST)
Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id C37581AE4B6 for <netmod@ietf.org>; Thu, 12 Dec 2013 12:52:50 -0800 (PST)
Received: by mail-qa0-f47.google.com with SMTP id w5so121214qac.13 for <netmod@ietf.org>; Thu, 12 Dec 2013 12:52:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=hCvx076VFg3KYnO5RfqQPun5Hd9jpeGhJZItod0bTWY=; b=H9ZzC4TwrT3cZVoF5p3wVwf1Oy9Rz+v2k9yCT4OZ6nmmLzKkYpaQjAXjl+I7OUgGSF cT6VZ9bmfpTy4XQ9IUu4RwQzIw0j7rQnFal3tTOSNbw3SAMBa5E7KhiGX9Li2STr3zSa ovJCOpKY6EfAoyyg9JJZOj+BOcM034uxehG+0uMjIDXKB/P1TXEvlXRzDxuYB2JieurO wY+v95XgcXOYy3w4sAiAJBrMiXQGz9FIKe8oL712Ix5dj9ggb7issZcnAGO264AEXUYK yeKYZAAiboDhk6HP86tGJzGM6sVdkhwIVsnN2xwdGho+5epRcWInQ2pLjnsF+yMeeAP4 7h0g==
X-Gm-Message-State: ALoCoQl/JoHnNVcyWs6jgX8dbhq3FMuDqp8WvOJjX2nmrBCP8ZZVrbuaqmnazCcsYk5CKrqF62Uv
MIME-Version: 1.0
X-Received: by 10.49.35.52 with SMTP id e20mr17046430qej.63.1386881564325; Thu, 12 Dec 2013 12:52:44 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 12:52:44 -0800 (PST)
In-Reply-To: <20131212203709.GF81732@elstar.local>
References: <32246622.1386784076436.JavaMail.root@elwamui-karabash.atl.sa.earthlink.net> <20131212.085209.387856404.mbj@tail-f.com> <001b01cef716$295e2520$6b01a8c0@oemcomputer> <004a01cef75c$b8610120$29230360$@comcast.net> <20131212203709.GF81732@elstar.local>
Date: Thu, 12 Dec 2013 12:52:44 -0800
Message-ID: <CABCOCHQUM6YWoPwDawwFyR7hWsNHkQLfGYr79aTWsfdnsPtuJw@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, ietfdbh <ietfdbh@comcast.net>, Randy Presuhn <randy_presuhn@mindspring.com>, Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="047d7b6d9b1cfcd41204ed5c863d"
Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 20:52:54 -0000
Hi, If the proposal is to move beyond DisplayString, then +1 from me. It's easy for people in the US to say "no problem" to using US-ASCII. This thread started over the use of MAY vs. MUST wrt/ DisplayString compatibility. Now it has jumped to MUST use DisplayString even if the device is capable of using UTF-8. Perhaps the original text was good enough. The server MAY reject values it does not support. Andy On Thu, Dec 12, 2013 at 12:37 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > Hi, > > I believe we need a reality check here. Unfortunately, I do not have > access to many recent devices. I would like to know what todays devices > do if you configure properties via the CLI that are export via SNMP > agents. > > - Do boxes reject anything at the CLI that does not conform to > DisplayStrings? > - Or do CLIs accept stuff and the agents provide strings not > conforming to DisplayStrings? > - Or do CLIs accept stuff and there is implementation specific > translation happening? > > For me, US 7-bit ASCII forever can't really be the answer. > > /js > > PS: At least on common *nix systems, the SNMP agent is a completely > separate process - one out of many. If I change the name of my > interface (and I can change it pretty arbitrarily), the SNMP agent > is not being asked and it has to deal with the name it finds the > kernel using. Some of the popular SNMP code bases out there not > even manage to properly truncate strings to DisplayString size. I > know it is a weak argument but in the real world, I am sure > management systems already have to deal with these issues. > > On Thu, Dec 12, 2013 at 12:08:03PM -0500, ietfdbh wrote: > > Hi, > > > > Personally, I think it would be simpler to just have the YANG objects be > > constrained by DisplayString syntax, but then, I come from a country > where > > 7-bit ASCII covers my language of choice. It would be nice to have a > > consistent underlying instrumentation without duplication of effort and > > resources, but that would require choosing the least common denominator > > (DisplayString). > > > > My second choice would be to treat them as separate instances, one of > > DisplayString syntax, one of YANG string syntax. That way, we don't have > to > > worry about side effects of changing the YANG object via the MIB, or > > changing the MIB object via YANG. If we want to internationalize the > syntax, > > you cannot do that to the MIB within SMI limits. Mapping between them if > > they support different syntax raises a whole lot of issues for the > database > > handling and UI of an NMS, stands the chance of breaking existing > > implementations if implementers handle the translations wrong or in a > > non-interoperable manner, and stands the chance of misleading operators > (and > > applications) if the value of the MIB object is changed dynamically > because > > the value is changed (in any way) via translation from the YANG object. > > > > I think it would be better for standardization and interoperability if > we do > > not try to force-feed new syntax into the existing MIB object(s). If you > > were trying to do this by updating the MIB, you would most certainly > need to > > define a new object (much like we had to do with Counter64s to replace > > Counter32s). If the YANG object is treated as a separate object from the > MIB > > object, then if and when the MIB is updated, the MIB can add an object to > > map to the YANG object, and deprecate the DisplayString syntax object. > > > > If the YANG object says it can be mapped, then I think the YANG object > must > > REQUIRE that it be implemented with DisplayString constraints, whether a > > server implementation maps to the MIB or not. Assuming an NMS supports > both > > MIB and YANG queries, and an implementer MAY treat them as separate, then > > the NMS must treat them as separate. If the implementer MAY treat them as > > mapped, the NMS still needs to implement them as separate because they > MAY > > be separate, but the NMS probably must treat the NMS-side variables as > > mapped to ensure they are in sync; otherwise reading the value via the > MIB > > without simultaneously reading the value via YANG would lead to the NMS > > potentially displaying different values even though on the device the > values > > are the same. This optionality greatly increases the complexity of > > implementing these objects on the NMS side. An NMS would need to > determine > > whether the agent/server implemented these as mapped or separate, > presumably > > by changing one and seeing if it affected the other, so it knew whether > to > > try to perform synchronization between the two. Lots of work for limited > > benefit to the operator. And if NMS implementations handled > synchronization > > differently, the operator is stuck trying to manage with conflicting > > information from different NMSs. > > > > It would be much better to standardize the expectation - either these > > objects MUST be mapped and constrained by DisplayString syntax per the > IETF, > > or MUST be defined as separate objects of different syntax per the IETF > > standard. Then an NMS implementer knows what to expect. > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > > -----Original Message----- > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Randy > > > Presuhn > > > Sent: Thursday, December 12, 2013 3:43 AM > > > To: Martin Bjorklund > > > Cc: netmod@ietf.org > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt > > > > > > Hi - > > > > > > > From: "Martin Bjorklund" <mbj@tail-f.com> > > > > To: <randy_presuhn@mindspring.com> > > > > Cc: <j.schoenwaelder@jacobs-university.de>; <netmod@ietf.org> > > > > Sent: Wednesday, December 11, 2013 11:52 PM > > > > Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt > > > > > > > > Randy Presuhn <randy_presuhn@mindspring.com> wrote: > > > > > Hi - > > > > > > > > > > >From: Juergen Schoenwaelder <j.schoenwaelder@jacobs- > > > university.de> > > > > > >Sent: Dec 11, 2013 12:38 AM > > > > > >To: Randy Presuhn <randy_presuhn@mindspring.com> > > > > > >Cc: netmod@ietf.org > > > > > >Subject: Re: [netmod] AD review of draft-ietf-netmod-system-mgmt > > > > > > > > > > > >On Tue, Dec 10, 2013 at 01:18:10PM -0800, Randy Presuhn wrote: > > > > > > > > > > > >> > Anyway, for a standardized approach, someone would have to > write > > > a > > > > > >> > document that defines how unicode code points are represented > as > > > > > >> > escaped charater sequences in DisplayStrings. I do not think > that > > this > > > > > >> > document is in charge of doing this. Hence, until such a > standard > > is > > > > > >> > written, I think things need to be implementation specific. > > > > > >> > > > > > >> Perhaps, though that is the route to being stuck with ASCII > until > > the > > > > > >> successor to Netconf rolls along. > > > > > > > > > > > >Not necessarily. If you configure via NETCONF (or most CLIs these > > > > > >days), you can use unicode characters. The code that maps names to > > > > > >legacy non-unicode interfaces then needs to do suitable > translations > > > > > >to fit whatever constraint there is. > > > > > > > > > > Not if the data definition restricts the values to an ASCII > > > > > subset, as has been proposed. What's in the draft at the > > > > > moment will bring its own interoperability problems, but > > > > > at least it's a baby step forward. > > > > > > > > So it seems we have a chance to fix this now. But I need to > > > > understand what exactly you and/or Juergen propose. Preferrably > > > > concrete text. I *think* that the proposal is something like this: > > > > > > > > o An implementation MUST allow any legal "string" (YANG string). > > > > > > There are good reasons to restrict formatting and control characters - > > > I'll assume YANG strings do this already. If not, that's another long > > > discussion. > > > > > > > o An implementation that maps this value to the corresponding MIB > > > > object, which has size and character set limitations, MUST use > > > > some mechanism out of the scope for this document to ensure > that > > > > the MIB object syntax is still valid. > > > > > > Yes this seems reasonable. > > > > > > But it doesn't cover a "round trip". If the value is modified via the > MIB > > > interface to include what looks like the implementation-specific > encoding > > > into ASCII of a non-ASCII Unicode code point, does retrieving that > value > > > via the Netconf interface get the Unicode code point or the > > implementation- > > > specific ASCII encoding of it? If it does (and I think it should) then > > there > > > needs to be some though put into what happens when the code point > > > encoded using ASCII would, if converted to Unicode, be illegal (for > > > whatever reason) in the YANG string. It's probably best to keep the > > > SNMP instrumentation ignorant of all this, so code in the Netconf side > > > would need determine whether any of the ASCII "escape sequences" > > > would produce forbidden code points, and, in such cases, *not* evaluate > > > those sequences and just pass them through unevaluated. > > > > > > > > > > Also, just to make sure, we are talking about: > > > > > > > > system/location -- sysLocation > > > > system/contact -- sysContact > > > > interface/description -- ifAlias > > > > > > Perhaps also sysDescr (even though read-only, my comment above seems > > > applicable, > > > particularly since on at least some systems this comes from a static > > > configuration > > > file, and would be useful to support local language in some minimal > way.) > > > > > > sysName (think IDN) might also be worth thinking about. There was a > long > > > debate > > > about this a while back; I don't know what current thinking is. > > > > > > Randy > > > > > > _______________________________________________ > > > 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 > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- Re: [netmod] AD review of draft-ietf-netmod-syste… Benoit Claise
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- [netmod] AD review of draft-ietf-netmod-system-mg… Benoit Claise
- Re: [netmod] AD review of draft-ietf-netmod-syste… Benoit Claise
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Benoit Claise
- Re: [netmod] AD review of draft-ietf-netmod-syste… Benoit Claise
- Re: [netmod] AD review of draft-ietf-netmod-syste… Benoit Claise
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… ietfdbh
- Re: [netmod] AD review of draft-ietf-netmod-syste… Andy Bierman
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… Andy Bierman
- Re: [netmod] AD review of draft-ietf-netmod-syste… ietfdbh
- Re: [netmod] AD review of draft-ietf-netmod-syste… Andy Bierman
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder
- Re: [netmod] AD review of draft-ietf-netmod-syste… Andy Bierman
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… ietfdbh
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… Randy Presuhn
- Re: [netmod] AD review of draft-ietf-netmod-syste… Ladislav Lhotka
- Re: [netmod] AD review of draft-ietf-netmod-syste… Martin Bjorklund
- Re: [netmod] AD review of draft-ietf-netmod-syste… Juergen Schoenwaelder