Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
Andy Bierman <andy@yumaworks.com> Thu, 12 December 2013 18:31 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 DBF691AE3C7 for <netmod@ietfa.amsl.com>; Thu, 12 Dec 2013 10:31:20 -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 e8Sx1jaRk6Vr for <netmod@ietfa.amsl.com>; Thu, 12 Dec 2013 10:31:16 -0800 (PST)
Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1171AE0BE for <netmod@ietf.org>; Thu, 12 Dec 2013 10:31:16 -0800 (PST)
Received: by mail-qe0-f44.google.com with SMTP id nd7so675580qeb.17 for <netmod@ietf.org>; Thu, 12 Dec 2013 10:31:10 -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:cc:content-type; bh=Dg+f90qQK4MTo8SmlU9fQVsPvc2r1pyqYE3Fxq0Hvwo=; b=ll2Xg2dF2/E655762YuZ3/6cK0+ucCxkxNo+RIHY3mC1GYz2e8uvlUg+pp21oY9gbl uhu2AsOuQPwu39eav8GJhaPTzmnmeVut0YWekbXk+ups7sw3zS/AJn2Peg6x/WNWJ6Mf xf9/NeRi3lA94SJ8TnUull/C/kiElHTWxGBinVWvcOavxcNB4uQ6w11KGDfD83FknZNU jJhL4eeFrpG8b/yVUQs27FuIECEAC59unXh2eJBQOJAsSTHEW/4MuG0EBGkjGtP+Nnsg rdlJPl39UFwy4sOhUG/R1UHyZda3pr+muotPn/z1pyRwB2MMALNk/+o9674K/Yx3sle9 YKIw==
X-Gm-Message-State: ALoCoQlv9f6nkUU2bSCl0vd7Nf2L02gymWR5iNrDfMQNtNHosKPpob1WJnRfCUI2AF1zvHicuon5
MIME-Version: 1.0
X-Received: by 10.49.25.109 with SMTP id b13mr16057484qeg.3.1386873070136; Thu, 12 Dec 2013 10:31:10 -0800 (PST)
Received: by 10.140.48.75 with HTTP; Thu, 12 Dec 2013 10:31:10 -0800 (PST)
In-Reply-To: <006201cef765$a461e640$ed25b2c0$@comcast.net>
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> <CABCOCHS+SBn8DqV5ZJCvxv5AY5sSQ1Lsh5wTHhROpoigm4ydwA@mail.gmail.com> <006201cef765$a461e640$ed25b2c0$@comcast.net>
Date: Thu, 12 Dec 2013 10:31:10 -0800
Message-ID: <CABCOCHRo+ai5A6Q2JUSZG7FWDQUv-S_UgEpUrPpRvCZ3K5Ua5Q@mail.gmail.com>
From: Andy Bierman <andy@yumaworks.com>
To: ietfdbh <ietfdbh@comcast.net>
Content-Type: multipart/alternative; boundary="047d7b677f1eb1beba04ed5a8c4c"
Cc: Randy Presuhn <randy_presuhn@mindspring.com>, "netmod@ietf.org" <netmod@ietf.org>
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 18:31:21 -0000
Hi, Here is Martin's suggestion: > I don't think it makes much sense to have two such similar objects in > this data model. > > One option would be to simply remove the connection between > sysLocation and this new location leaf (and same for contact), > essentially making the snmp object the "legacy" object. I like this idea. The client can decide if it wants the location leaf and sysLocation SNMP object to have the same value. There are many languages that cannot use 7-bit ASCII. We should be using UTF-8 for all administrative strings. Andy On Thu, Dec 12, 2013 at 10:11 AM, ietfdbh <ietfdbh@comcast.net> wrote: > Hi, > > > > Comments inline > > > > David Harrington > > ietfdbh@comcast.net > > +1-603-828-1401 > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, December 12, 2013 12:19 PM > *To:* ietfdbh > *Cc:* Randy Presuhn; Martin Bjorklund; netmod@ietf.org > *Subject:* Re: [netmod] AD review of draft-ietf-netmod-system-mgmt > > > > Hi, > > > > What if these objects do not have corresponding SNMP values on the device? > > What if the device does not implement SNMP? > > > > I don’t really care whether SNMP is implemented on the device or not. > > I care about standardizing consistent syntax for the YANG object. > > > > Are you suggesting we need duplicate versions for devices that do support > SNMP, > > with an "if-feature snmp" statement to make it conditional? > > > > *Absolutely not. I am saying the syntax should not be conditional. Period. > No if-feature needed.* > > > > Either make the syntax of the YANG object the same as DisplayString (which > would force old syntax on new implementations, sometimes unnecessarily from > a device perspective, but would allow mapping) or make it two separate > objects with different syntax (to support internationalization in the newer > standard, while the old object supports the old syntax, and it doesn’t > support mapping by the implementation). > > > > Making it optional is a problem for the NMS side which has to support > multiple devices that are allowed to make different implementation choices > for the same object. > > Making it optional is a problem for the device side which has to deal with > translations between values of different syntax. > > Allowing the objects to be separate OR mapped, and allowing side-effects > to change the values seems especially problematic from a synchronization > standpoint for the NMS (and the operators) who have to consider the results > of queries by two different protocols of the MAYBE-MAYBENOT-mapped objects. > > > > *Get rid of the optionality. Standardize the syntax of the YANG object one > way or the other.* > > > > What does it mean > > if the 2 variants have different values? > > > > If they are separate variables, they can have different values and > different syntax. No big deal. > > If the **operator** wants them to be the same value, they limit themselves > to DisplayString syntax when setting the YANG object, and it is their > responsibility to keep the two variables in sync, not the implementer’s > responsibility. > > If the **operator** wants internationalized YANG names, they can with YANG > strings. > > If the **operator** wants internationalized MIB names, too bad; the MIB > standard doesn’t permit that. > > > > I think the new proposed text forces a device to limit the object to 7-bit > ASCII > > if the SNMP version of the object is supported. > > > > It seems old syntax is being forced on devices, not new syntax. > > > If you don’t want the new object to be constrained by old syntax, then > make it a separate object, unconstrained by any mapping to the standard MIB > object. > > From the perspective of this NMS developer, I would MUCH prefer separate > objects, each with a consistently standardized syntax, over separate > objects for whom the syntax may or may not be the same. > > > > The operators who spoke up around the time of rfc3535 said they don’t > trust applications to necessarily get things right, so asking the > implementations to do some type of automated lossless translation between > objects of different syntax and size sounds like you’re asking for trouble. > > > Andy > > > > On Thu, Dec 12, 2013 at 9:08 AM, ietfdbh <ietfdbh@comcast.net> 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- > <j.schoenwaelder@jacobs-%0b>> 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 > > >
- 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