Re: [netmod] AD review of draft-ietf-netmod-system-mgmt
"ietfdbh" <ietfdbh@comcast.net> Thu, 12 December 2013 18:12 UTC
Return-Path: <ietfdbh@comcast.net>
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 713F81AE00E for <netmod@ietfa.amsl.com>; Thu, 12 Dec 2013 10:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 tYkkGr0N0-VV for <netmod@ietfa.amsl.com>; Thu, 12 Dec 2013 10:12:06 -0800 (PST)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id E06D31ADDCA for <netmod@ietf.org>; Thu, 12 Dec 2013 10:12:05 -0800 (PST)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id 0eCK1n0061uE5Es54iBzV9; Thu, 12 Dec 2013 18:11:59 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta16.westchester.pa.mail.comcast.net with comcast id 0iBz1n0092yZEBF3ciBzin; Thu, 12 Dec 2013 18:11:59 +0000
From: ietfdbh <ietfdbh@comcast.net>
To: 'Andy Bierman' <andy@yumaworks.com>
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>
In-Reply-To: <CABCOCHS+SBn8DqV5ZJCvxv5AY5sSQ1Lsh5wTHhROpoigm4ydwA@mail.gmail.com>
Date: Thu, 12 Dec 2013 13:11:55 -0500
Message-ID: <006201cef765$a461e640$ed25b2c0$@comcast.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01CEF73B.BB910E60"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHRWvhskhnOaPbMPUajuprGlXhfOwJKF7QAAdpcncgBqti1+wGEM/uhmhFraeA=
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1386871919; bh=yQM7u40mlTuRNOGZT4E3aRUPY2H3usA1OPVz0SBuDTU=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=NagG7EP7gPLphSwGRC58w+ZuJHsP57otDxt2emmbKLdZwBFUAv4n2COtsJMQkdGAd j/ohe3o1XcHqLyYGGj0lVwn5GDFb3pDArSwcX7AGQVQ+pYj3dV/FvbTdhxYg3T8dNA haArUiukjQLrqtW5nLLxD8hL8ydlWiFCNpdlavY14KMucPlOSn9L/cEs+RgC9+8JGC OSA1G/JzNrgC+TflQnjOpmmXX6HFcd1JYd322PC7rZPJ7cskdrHA6pN8ZrmE5gZlrE Da/M4Cl9rZRxWDyJ6V2UVrTf362R8SiGydWPRSWNaj5u0sEFQUyqcBkXsbt7Zt6l+C 2/g4GWb6JmLkg==
Cc: 'Randy Presuhn' <randy_presuhn@mindspring.com>, 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:12:13 -0000
Hi, Comments inline David Harrington <mailto:ietfdbh@comcast.net> 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- <mailto: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