From j.schoenwaelder@jacobs-university.de Thu Nov 1 06:22:25 2012 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 3125421F8BC8 for ; Thu, 1 Nov 2012 06:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr1ORs+ohhvJ for ; Thu, 1 Nov 2012 06:22:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FB21F8BE3 for ; Thu, 1 Nov 2012 06:22:24 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6A6420E49; Thu, 1 Nov 2012 14:22:22 +0100 (CET) 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 RFT1zlHajwNW; Thu, 1 Nov 2012 14:22:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79E5720DF9; Thu, 1 Nov 2012 14:22:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 957482295AFF; Thu, 1 Nov 2012 14:22:23 +0100 (CET) Date: Thu, 1 Nov 2012 14:22:23 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20121101132223.GB2842@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] NomCom 2012: Feedback and Office Hours 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: Thu, 01 Nov 2012 13:22:25 -0000 Hi, please help the NomCom with the selection of our future leadership. For details, see the message below. /js --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From jeffrey.K.lange@ge.com Fri Nov 2 12:34:58 2012 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 9B84011E80E9 for ; Fri, 2 Nov 2012 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw0gw5vvCalh for ; Fri, 2 Nov 2012 12:34:56 -0700 (PDT) Received: from exprod5og109.obsmtp.com (exprod5og109.obsmtp.com [64.18.0.188]) by ietfa.amsl.com (Postfix) with ESMTP id 045DE11E80D1 for ; Fri, 2 Nov 2012 12:34:55 -0700 (PDT) Received: from cinmlip10.e2k.ad.ge.com ([165.156.4.1]) (using TLSv1) by exprod5ob109.postini.com ([64.18.4.12]) with SMTP ID DSNKUJQgX3rSiDdAYPYfKbBZMDIx3pbILD+V@postini.com; Fri, 02 Nov 2012 12:34:56 PDT Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by cinmlip10.e2k.ad.ge.com with ESMTP; 02 Nov 2012 15:34:54 -0400 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Nov 2012 15:34:54 -0400 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Nov 2012 15:34:53 -0400 Received: from CINMBCNA03.e2k.ad.ge.com (3.159.212.57) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.309.2; Fri, 2 Nov 2012 15:34:52 -0400 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.108]) by CINMBCNA03.e2k.ad.ge.com ([169.254.3.136]) with mapi id 14.02.0309.002; Fri, 2 Nov 2012 15:34:52 -0400 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: RADIUS enhancement to ietf-system Thread-Index: Ac25Lv847iFqHZGDQ7e71YdLlqfDUQ== Date: Fri, 2 Nov 2012 19:34:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A5E2CINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Nov 2012 19:34:53.0156 (UTC) FILETIME=[2194FA40:01CDB931] Subject: [netmod] RADIUS enhancement to ietf-system 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, 02 Nov 2012 19:34:58 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A5E2CINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've realized that there is a rather critical configuration component missi= ng from the RADIUS configuration section of the ietf-system model. There i= s no way to specify the authentication type to use for a server (PAP/CHAP/E= AP etc...) I have added the following to the model, and I'm passing it along in hopes = that it can make it into the official model. I have included the types PAP,CHAP, and EAP-MD5. There are a plethora othe= r types, as well, but I think these are probably the most common. This is = why I created it as an identity as opposed to an enumeration. I guess there are a few general questions 1) Should this be included in the standard model (I clearly think yes) 2) Should more types be defined (MS-CHAP / MS-CHAPv2 / SIP Digest / LE= AP / Cisco LEAP / etc...), this gets tricky for things like EAP-TLS where y= ou also need to configure keying material. 3) Should each identity be wrapped in a feature that determines whethe= r or not the device supports that particular Auth type? Or should the serve= r validate the settings at runtime? Thanks -Jeff Lange diff --git a/data_model/ietf-system@2012-09-07.yang b/data_model/ietf-syste= m@2012-09-07.yang index a0b69f6..f37eb2e 100644 --- a/data_model/ietf-system@2012-09-07.yang +++ b/data_model/ietf-system@2012-09-07.yang @@ -237,6 +237,49 @@ module ietf-system { configured users."; } + identity radius-authentication-type { + description + "Base identity for RADIUS authentiation types."; + } + + identity radius-PAP { + base radius-authentication-type; + description + "RADIUS messages will use the PAP authentication mechanism."; + reference + "RFC 2865: Remote Authentication Dial In User Service (RADIUS) + RFC 2869: RADIUS Extensions + RFC 5607: Remote Authentication Dial-In User Service (RADIUS) + Authorization for Network Access Server (NAS) + Management"; + } + + identity radius-CHAP { + base radius-authentication-type; + description + "RADIUS messages will use the CHAP authentication mechanism."; + reference + "RFC 2865: Remote Authentication Dial In User Service (RADIUS) + RFC 2869: RADIUS Extensions + RFC 5607: Remote Authentication Dial-In User Service (RADIUS) + Authorization for Network Access Server (NAS) + Management"; + } + + identity radius-EAP-MD5 { + base radius-authentication-type; + description + "RADIUS messages will use the EAP-MD5 authentication mechanism."; + reference + "RFC 2284: Extensible Authentication Protocol (EAP) + RFC 2865: Remote Authentication Dial In User Service (RADIUS) + RFC 2869: RADIUS Extensions + RFC 3579: RADIUS Support For Extensible Authentication Protocol (EA= P) + RFC 5607: Remote Authentication Dial-In User Service (RADIUS) + Authorization for Network Access Server (NAS) + Management"; + } + /* * Top-level container */ @@ -549,6 +592,14 @@ module ietf-system { reference "RFC 2865: Remote Authentication Dial In User Service"; } + leaf authentication-type { + type identityref { + base radius-authentication-type; + } + default radius-PAP; + description + "The authentication type used by the RADIUS server."; + } } container options { description --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A5E2CINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve realized that there is a rather critical = configuration component missing from the RADIUS configuration section of th= e ietf-system model.  There is no way to specify the authentication ty= pe to use for a server (PAP/CHAP/EAP etc…)

 

I have added the following to the model, and I’= ;m passing it along in hopes that it can make it into the official model.

 

I have included the types PAP,CHAP, and EAP-MD5.&nbs= p; There are a plethora other types, as well, but I think these are probabl= y the most common.  This is why I created it as an identity as opposed= to an enumeration.

 

I guess there are a few general questions=

1)      Should this be included in the standard model (I cl= early think yes)

2)      Should more types be defined (MS-CHAP / MS-CHAPv2 /= SIP Digest / LEAP / Cisco LEAP / etc…), this gets tricky for things = like EAP-TLS where you also need to configure keying material.

3)      Should each identity be wrapped in a feature that d= etermines whether or not the device supports that particular Auth type? Or = should the server validate the settings at runtime?

 

Thanks

-Jeff Lange

 

 

diff --git a/data_model/ietf-system@2012-09-07.yang = b/data_model/ietf-system@2012-09-07.yang

index a0b69f6..f37eb2e 100644

--- a/data_model/ietf-system@2012-09-07.yang

+++ b/data_model/ietf-system@2012-09-07.= yang

@@ -237,6 +237,49 @@ module ietf-system {

       configured= users.";

   }

+  identity radius-authentication-type {

+    description

+      "Base ident= ity for RADIUS authentiation types.";

+  }

+

+  identity radius-PAP {

+    base radius-authentication-t= ype;

+    description

+      "RADIUS mes= sages will use the PAP authentication mechanism.";

+    reference

+      "RFC 2865: = Remote Authentication Dial In User Service (RADIUS)

+       RFC 2869: = RADIUS Extensions

+       RFC 5607: = Remote Authentication Dial-In User Service (RADIUS)

+        = ;         Authorization for Network= Access Server (NAS)

+        = ;         Management";

+  }

+

+  identity radius-CHAP {

+    base radius-authentication-t= ype;

+    description

+      "RADIUS mes= sages will use the CHAP authentication mechanism.";

+    reference

+      "RFC 2865: = Remote Authentication Dial In User Service (RADIUS)

+       RFC 2869: = RADIUS Extensions

+       RFC 5607: = Remote Authentication Dial-In User Service (RADIUS)

+        = ;         Authorization for Network= Access Server (NAS)

+        = ;         Management";

+  }

+

+  identity radius-EAP-MD5 {

+    base radius-authentication-t= ype;

+    description

+      "RADIUS mes= sages will use the EAP-MD5 authentication mechanism.";

+    reference

+      "RFC 2284: = Extensible Authentication Protocol (EAP)

+       RFC 2865: = Remote Authentication Dial In User Service (RADIUS)

+       RFC 2869: = RADIUS Extensions

+       RFC 3579: = RADIUS Support For Extensible Authentication Protocol (EAP)

+       RFC 5607: = Remote Authentication Dial-In User Service (RADIUS)

+        &nbs= p;        Authorization for Network= Access Server (NAS)

+        = ;         Management";

+  }

+

   /*

    * Top-level container<= /p>

    */

@@ -549,6 +592,14 @@ module ietf-system {

        &nbs= p;  reference

        &nbs= p;    "RFC 2865: Remote Authentication Dial In User Ser= vice";

         }

+        leaf= authentication-type {

+        = ;  type identityref {

+        = ;    base radius-authentication-type;

+        = ;  }

+        = ;  default radius-PAP;

+        = ;  description

+        = ;    "The authentication type used by the RADIUS server= .";

+        }

       }

       container optio= ns {

         des= cription

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A5E2CINMBCNA02e2kad_-- From bclaise@cisco.com Fri Nov 2 17:03:09 2012 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 6695311E80E3; Fri, 2 Nov 2012 17:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.02 X-Spam-Level: X-Spam-Status: No, score=-10.02 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XH+YVceFtjn; Fri, 2 Nov 2012 17:03:08 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 90BAC21F878E; Fri, 2 Nov 2012 17:03:07 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA30360m024884; Fri, 2 Nov 2012 20:03:06 -0400 (EDT) Received: from [10.86.246.101] ([10.86.246.101]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA3034t5005838; Fri, 2 Nov 2012 20:03:05 -0400 (EDT) Message-ID: <50945F38.5090003@cisco.com> Date: Fri, 02 Nov 2012 20:03:04 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <508FF9CF.2050902@cisco.com> <000001cdb708$ef460fe0$cdd22fa0$@olddog.co.uk> In-Reply-To: <000001cdb708$ef460fe0$cdd22fa0$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------050401040609050004080209" Cc: 'NETCONF' , 'NETMOD Working Group' Subject: Re: [netmod] Please attend the IRS BoF 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, 03 Nov 2012 00:03:09 -0000 This is a multi-part message in MIME format. --------------050401040609050004080209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Ok, "This BoF will/should be speaking about YANG for data modeling." is a poor choice of words. Actually my shortcut. To me, this entire SDN story is about a config management issue, which in turn is a data modeling issue. And I see IRS as one part of SDN story. So let me rephrase OLD: This BoF will/should be speaking about YANG for data modeling. NEW: _ IMHO_, YANG SHOULD be a key piece of the IRS data modeling, and NETCONF MAY be. So NETCONF/YANG experts, keep an eye on this initiative. When I saw the first IRS draft from Tom Nadeau (in a flight right now, can't check the exact draft name), basically telling the NETCONF was not good enough ... I was a little bit worried Now, I'm happier with the text in the current charter: 5. An analysis of existing IETF and other protocols and encoding languages against the requirements. ... This BoF is to determine focus and support for work within the IETF to specify abstract data information models, specific data models, and protocols to operate the IRS. The BoF does not assume that new data modeling languages or protocols will be required - that decision is expected to form part of the analysis carried out by a working group if one is formed. That takes care of my concerns. And, as an OPS AD, I will be carefully double-check that if NETCONF and/or YANG are not the right choices, this is for a very good reason, which doesn't solve the problem statement. And from there, I want to see if we could improve NETCONF/YANG Another reason why I'm pushing the NETMOD participation in IRS is that we have this draft draft-ietf-netmod-routing-cfg-05 (A YANG Data Model for Routing Configuration), on which we need to get the IRS people feedback. However, I agree with the approach (used cases, problem statement, architecture/framework), but we want anyway to get some feedback from the routing and IRS experts on this YANG module. I hope it clarifies. Regards, Benoit > > I shall be disappointed if this BoF talks about YANG for data modelling. > > The first draft of the charter posted on the IRS mailing list says: > > > The IRS working group works to develop a framework and > > > architecture that will enable specific use cases, and lead to > > > an understanding of the informational models and > > > requirements for encodings and protocols. > > ...and > > > The working group is chartered to work on the following items: > > > > > > 1. Architecture and framework for IRS including considerations of > > >policy and security > > > > > > 2. Tightly scoped key use cases for operational use of IRS. These > > >use cases will include at least: > > > - Interactions with the RIB > > > - Association of routing policies with routing state > > > - The ability to extract information about topology from the network. > > >Injection and creation of topology will not be considered as an initial > > >work item. > > > Other use cases may be adopted by the working group only after > > > milestones have been added to the charter page. > > > > > > 3. Abstract information models consistent with the use cases > > > > > > 4. Requirements for IRS protocols and encoding languages > > > > > > 5. An analysis of existing IETF and other protocols and encoding languages against the > requirements. > > ...and > > > The working group is not currently chartered to develop protocols, > > > encoding languages, or data models. > > What is more, the BoF description posted on the wiki and forming part > of the grant of the BoF says: > > >This BoF is to determine focus and support for work within the IETF > > >to specify abstract data information models, specific data models, > > >and protocols to operate the IRS. The BoF does not assume that new > > >data modeling languages or protocols will be required - that decision > > >is expected to form part of the analysis carried out by a working > > >group if one is formed. > > My disappointment if YANG is mentioned during the BoF will be because > it will demonstrate that people have not understood the need to > develop use cases and requirements *before* discussing whether > existing protocols and encoding languages are suitable for the task at > hand. It would be frankly as absurd to rule out Netconf as one of the > protocols used in IRS as it would be to demand that it is used because > we have currently no idea what function we are trying to provide. > Similarly, it would be wrong to rule YANG in or out at this stage. > > So, I hope the BoF will talk about use cases and WG charter, and not > about solution protocols and encoding languages. > > Nevertheless, I hope that we get lots of Ops clue in this meeting and > encourage you to come along. > > Thanks, > > Adrian > > *From:*Benoit Claise [mailto:bclaise@cisco.com] > *Sent:* 30 October 2012 16:01 > *To:* NETMOD Working Group; NETCONF > *Cc:* Adrian Farrel > *Subject:* Please attend the IRS BoF > > Dear all, > > I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session > III > > > > > Salon D > > > > RTG > > > > irs > > > > Description: cid:part2.02000006.09090603@cisco.comInterface to the > Routing System BOF > > > This BoF will!should be speaking about YANG for data modeling. > Unfortunately, no agenda yet at > https://datatracker.ietf.org/meeting/85/agenda.html > The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss > > Regards, Benoit. > > --------------050401040609050004080209 Content-Type: multipart/related; boundary="------------060805080805000004020607" --------------060805080805000004020607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

Ok, "This BoF will/should be speaking about YANG for data modeling." is a poor choice of words.
Actually my shortcut. To me, this entire SDN story is about a config management issue, which in turn is a data modeling issue. And I see IRS as one part of SDN story.

So let me rephrase
OLD:
    This BoF will/should be speaking about YANG for data modeling.
NEW:
    IMHO, YANG SHOULD be a key piece of the IRS data modeling, and NETCONF MAY be.  So
    NETCONF/YANG experts, keep an eye on this initiative.

When I saw the first IRS draft from Tom Nadeau (in a flight right now, can't check the exact draft name), basically telling the NETCONF was not good enough ... I was a little bit worried

Now, I'm happier with the text in the current charter:
5. An analysis of existing IETF and other protocols and encoding languages against the requirements.

 ...

This BoF is to determine focus and support for work within the IETF

to specify abstract data information models, specific data models,

and protocols to operate the IRS. The BoF does not assume that new
data modeling languages or protocols will be required - that decision

 is expected to form part of the analysis carried out by a working

group if one is formed.

That takes care of my concerns. And, as an OPS AD, I will be carefully double-check that if NETCONF and/or YANG are not the right choices, this is for a very good reason, which doesn't solve the problem statement. And from there, I want to see if we could improve NETCONF/YANG

Another reason why I'm pushing the NETMOD participation in IRS is that we have this draft
draft-ietf-netmod-routing-cfg-05 (A YANG Data Model for Routing Configuration), on which we need to get the IRS people feedback.
However, I agree with the approach (used cases, problem statement, architecture/framework), but we want anyway to get some feedback from the routing and IRS experts on this YANG module.

I hope it clarifies.

Regards, Benoit

I shall be disappointed if this BoF talks about YANG for data modelling.

 

The first draft of the charter posted on the IRS mailing list says:

 

> The IRS working group works to develop a framework and

> architecture that will enable specific use cases, and lead to

> an understanding of the informational models and

> requirements for encodings and protocols.

 

...and

 

> The working group is chartered to work on the following items:

> 

> 1. Architecture and framework for IRS including considerations of

>    policy and security

> 

> 2. Tightly scoped key use cases for operational use of IRS. These

>  use cases will include at least:

> - Interactions with the RIB

> - Association of routing policies with routing state

> - The ability to extract information about topology from the network.

>    Injection and creation of topology will not be considered as an initial

>    work item.

> Other use cases may be adopted by the working group only after

> milestones have been added to the charter page.

> 

> 3. Abstract information models consistent with the use cases

> 

> 4. Requirements for IRS protocols and encoding languages

>

> 5. An analysis of existing IETF and other protocols and encoding languages against the requirements.

 

...and

 

> The working group is not currently chartered to develop protocols,

> encoding languages, or data models.

 

What is more, the BoF description posted on the wiki and forming part of the grant of the BoF says:

 

>   This BoF is to determine focus and support for work within the IETF

>   to specify abstract data information models, specific data models,

>   and protocols to operate the IRS. The BoF does not assume that new

>   data modeling languages or protocols will be required - that decision

>   is expected to form part of the analysis carried out by a working

>   group if one is formed.

 

My disappointment if YANG is mentioned during the BoF will be because it will demonstrate that people have not understood the need to develop use cases and requirements *before* discussing whether existing protocols and encoding languages are suitable for the task at hand. It would be frankly as absurd to rule out Netconf as one of the protocols used in IRS as it would be to demand that it is used because we have currently no idea what function we are trying to provide. Similarly, it would be wrong to rule YANG in or out at this stage.

 

So, I hope the BoF will talk about use cases and WG charter, and not about solution protocols and encoding languages.

 

Nevertheless, I hope that we get lots of Ops clue in this meeting and encourage you to come along.

 

Thanks,

Adrian

 

 

From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: 30 October 2012 16:01
To: NETMOD Working Group; NETCONF
Cc: Adrian Farrel
Subject: Please attend the IRS BoF

 

Dear all,

I encourage you all to attend the IRS BoF, 1740-1940 Afternoon Session III


Salon D

RTG

irs

Description: cid:part2.02000006.09090603@cisco.comInterface to the Routing System BOF


This BoF will!should be speaking about YANG for data modeling.
Unfortunately, no agenda yet at https://datatracker.ietf.org/meeting/85/agenda.html
The mailer is https://www.ietf.org/mailman/listinfo/irs-discuss

Regards, Benoit.



--------------060805080805000004020607 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAA AAMreLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --------------060805080805000004020607-- --------------050401040609050004080209-- From wjhns1@hardakers.net Fri Nov 2 20:39:07 2012 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 2A26111E8106 for ; Fri, 2 Nov 2012 20:39:07 -0700 (PDT) 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=-2.599, J_CHICKENPOX_46=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JML4yDT6wkDy for ; Fri, 2 Nov 2012 20:39:06 -0700 (PDT) Received: from mail.hardakers.net (dawn.hardakers.net [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E7011E80DF for ; Fri, 2 Nov 2012 20:39:06 -0700 (PDT) Received: from localhost (wjhw.hardakers.net [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id D8C693CB for ; Fri, 2 Nov 2012 20:39:04 -0700 (PDT) From: Wes Hardaker To: netmod@ietf.org Date: Fri, 02 Nov 2012 20:39:04 -0700 Message-ID: <0l8vaj73tz.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Subject: [netmod] review of netmod-snmp-cfg 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, 03 Nov 2012 03:39:07 -0000 I reviewed, as promised at the last IETF, the netmod-snmp-cfg-00 document; in particular with respect to the TLS parts of it but I also reviewed the USM configuration too. Here's the notes I wrote up about it (in no particular order): 1) Should, at least, the key objects be marked as nacm:default-deny-all? It's extremely sensitive data. I'm not a yang expert and didn't look up the rules, so I'm not sure if it needs to go into the 'grouping' statement or in the 'uses' places. 2) the usm container has two user groupings: local and remote. The local user set doesn't have an engineID associated with it, but local userIDs certainly do have an engineID (the local one). Most importantly, the user in an SNMP agent would still be there and valid if the SNMP agent's engineID is changed (administratively) and would be attached to the *old* engineID. But with the netconf setup, the user table would move right along to the new one and the (localized) key actually wouldn't be usable if the manager was deriving the key from a master key or password. In short: I think the local users need to be associated with the engineID too, since that's how every SNMPv3 engine out there fundamentally thinks. And if the engineID changes within an SNMPv3 engine, the user table needs to still exist *as it was before the change*. A netconf dump, followed by an engineID change (inside or outside the yang data), followed by a restore will not let this happen properly. 3) the various references to "type security-level" need to be changed to "type snmp:security-level" (I think). And probably for "admin-string" too. 4) The snmp:target augmentation for the usm I don't think is fully flexible enough. The augmentation is only done with USM, but I'm not positive that's a good idea. USM happens to be the first and only security model to use an engineID, but much of the v3 architecture seems to believe that other security models would likely have them too. But I'm not 100% sure about this. 5) I know this was discussed heavily before, but I don't remember the results... The yang model(s) imposes a number of constraints to the data that don't exist in any current implementations. Things like references that "must" exist, etc. I certainly understand the fact that in many cases the model as implemented in SNMP had to be done that way since SNMP doesn't have the power of netconf and sending lots of data at once and piece-by-piece uploading needed to be supported. And thus, when we get to wrapping yang around past models "it's our chance to fix the model and impose proper constraints". But the reality of the situation is that the underlying thing that yang is wrapping around, the SNMP engine and it's data, will both need to offer and accept data that doesn't conform to those constraints. Thus, as an implementer I'm not sure what I'd do. Either way "I'd need to break something". And it's unlikely, seeing as it's in an SNMP implementation, that I'd choose breaking the SNMP model vs the yang one. There are times where the feature set is actually designed around "the disconnect" so they could be added later (like the radius based VACM modifications that added the group to the user at authentication time; the group would be empty before a user got assigned and it's possible the radius server would assigned a group to a user where the group hadn't been configured yet). Again: as an implementer, what would you do when you tried to wrap netconf/yang around this problem? You'd more than likely choose to ignore the yang constraints, not the other way around, because they didn't match the real implementation. Most importantly, they didn't match *any* current implementation (it'd be somewhat different if only one implementation had a quirk; but in this case they *all* have that quirk because they're *all* conforming to an existing standard). 6) the tls-fingerprint typedef allows for 6-64 repeats of hex characters (and obviously :s inbetween). But the SNMP definition is 0-255 (with a 1 octet prefix if non-zero). I'm not sure why {4,31} was chosen, but it doesn't seem to match the flexibility in the MIB nor in the IANA registry. 7) There is no commonname mapping identity 8) there are multiple "FIXME" things that, um, probably need to be fixed :-) 9) The cert-specified-tm-security-name "FIXME" wonders if it should be a generic text in order to be as flexible as the MIB, or whether it to remove the identities and use augmentation. My take is that the MIB was done generically because augmentation of tables is a pain in SNMP and that's one of the benefits of netconf, so I'd do it the netconf way and say that cert-specified-tm-security-name needs to exist if map-type == specified. Future mappings, if ever actually created, can create new augmentations where the data field in the SNMP mib may mean something different but can be contained in a different netconf variable. It makes the netconf data cleaner and clearer, while still allowing the netconf agent to magically map the two together. But, you do need to say something like "if multiple data fields are defined in the netconf data, then only the current mapping type data will be saved to the corresponding MIB object and the other will be lost" or something. 10) the server-identification choice will be losing mib data if netconf pulls it out and then puts it back because only one set of MIB data will be kept (specifically, the snmpTlstmAddrServerFingerprint must take priority and be kept while the other is dropped, though you'd have to read the MIB to understand that. [I realize this losing of data is a fairly common one with netconf to snmp configuration mappings when "choice" or other restrictive data components are used; this is actually likely to be a common problem among many data models where we decide that netconf is going to be more restrictive than an implementation; eg, consider transferring DNS data where there is a choice of CNAME or anything-else; unfortunately real world people put both CNAMEs and MX records at the same location in the DNS even though the protocol specifies this shouldn't be done; nothing enforces it though] 11) the snmp params vs address separation in the target mib was done that way to reduce the data sent when zillions of addresses are targets and they all use the same client authentication components (eg, one TLS client-side certificate). The netconf implementation of the target mib and the tls related components seem to require that all that client data be duplicated for every remote address. That means if a netconf manager needs to change out the client side certificate it'll need to probably pull and replace the whole table since it can't simply "edit" a single row to replace the client fingerprint with a simple edit operation. I assume this is by design on the netconf side, but it is discarding some of the point of the original designed of the SNMP target mib: to separate the client side authentication from the address lists that you might talk to in order to simplify updating the client data components? 11b) note that it also makes it difficult to switch simply between tls and dtls, as you need to pull and add entirely new rows to make it happen rather than just switch the transport type. -- Wes Hardaker SPARTA, Inc. From jernej.tuljak@mg-soft.si Tue Nov 6 06:45:07 2012 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 8F46221F898B for ; Tue, 6 Nov 2012 06:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb4TOnn6XDWm for ; Tue, 6 Nov 2012 06:45:07 -0800 (PST) Received: from gate.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9764221F8848 for ; Tue, 6 Nov 2012 06:45:05 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by gate.mg-soft.si (8.13.8/8.13.8) with ESMTP id qA6Ej37M012035 for ; Tue, 6 Nov 2012 15:45:03 +0100 Message-ID: <5099226D.3090400@mg-soft.com> Date: Tue, 06 Nov 2012 15:45:01 +0100 From: Jernej Tuljak User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [netmod] Top-level grouping with nested typedefs and groupings bug (RFC6110) 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, 06 Nov 2012 14:45:07 -0000 Hi, RFC6110 says the following: -------------------------------------------------- 8.2. Modularity Named pattern definitions that are mapped from non-top-level YANG groupings MUST be placed inside the embedded grammar corresponding to the YANG module where the grouping is defined. 10.20. The 'grouping' Statement As explained in Section 8.2, a named pattern definition MUST be placed: o as a child of the root element if the corresponding grouping is defined at the top level of an input YANG module; o otherwise as a child of the embedded element corresponding to the module in which the grouping is defined. 10.54. The 'typedef' Statement This statement is mapped to a RELAX NG named pattern definition, but only if the type defined by this statement is used without restrictions in at least one of the input modules. In this case, the named pattern definition becomes a child of either the root or an embedded element, depending on whether or not the 'typedef' statement appears at the top level of a YANG module. The name of this named pattern definition is set to ARGUMENT mangled according to the rules specified in Section 9.2. -------------------------------------------------- If this text is strictly followed a syntactically incorrect hybrid RNG schema will get generated by an implementation in case a grouping or a typedef is defined within the subtree of a used top-level grouping. One will end up with a global definition which references named patterns from local (embedded) grammars. This cannot be done in RNG. After global definitions get separated into a separate include file it breaks completely. A standalone RNG grammar needs all referenced definitions in the same grammar (through local definitions or included ones). I fixed this in our implementation by treating any typedef or a grouping located within a used top-level grouping as a global definition but Ladislav suggested, that this may lead to name clashes (I agree). However I believe this could be solved with another name-mangling rule in section 9.2 which handles this special corner case. Example (module "test"): typedef g1 { ... } grouping g1 { container foo { grouping inner { ... } typedef inner { ... } ... } } container g1 { container foo { grouping inner { ... } typedef inner { ... } ... } } When "g1" grouping gets used and module "test" is also an input module: test__g1 (global rng:define for the top-level typedef) _test__g1 (global rng:define for the top-level grouping) _test__special_prefix__g1__foo__inner (global rng:define for first inner grouping) test__special_prefix__g1__foo__inner (global rng:define for first inner typedef) _test__g1__foo__inner (local rng:define for second inner grouping) test__g1__foo__inner (local rng:define for second inner typedef) There is no way to define another top-level schema node, grouping or typedef named "g1" in this module, so it should be okay. I could be missing something though. This also exposes internal definitions which may not be what a YANG modeler would want. This is how our implementation currently does it. Jernej From lhotka@nic.cz Tue Nov 6 07:45:38 2012 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 BB3A621F8495 for ; Tue, 6 Nov 2012 07:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4bZzgPMZjM4 for ; Tue, 6 Nov 2012 07:45:37 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCB121F8427 for ; Tue, 6 Nov 2012 07:45:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id DC2225403CB for ; Tue, 6 Nov 2012 16:45:33 +0100 (CET) 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 x+iXVqneF-AD for ; Tue, 6 Nov 2012 16:45:23 +0100 (CET) Received: from localhost (dhcp-113f.meeting.ietf.org [130.129.17.63]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9D4825400CF for ; Tue, 6 Nov 2012 16:45:18 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <5099226D.3090400@mg-soft.com> References: <5099226D.3090400@mg-soft.com> User-Agent: Notmuch/0.14+37~gf227d63 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Tue, 06 Nov 2012 10:45:17 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] Top-level grouping with nested typedefs and groupings bug (RFC6110) 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, 06 Nov 2012 15:45:38 -0000 Hi Jernej, good catch, it is indeed a bug. I think your proposed solution with additional name mangling might work but we have to consider and test the various corner cases. Anyhow, this bug cannot be dealt with through errata because the required change to the mapping procedure is significant. So this needs to be fixed in a future revision of RFC 6110. Thanks, Lada Jernej Tuljak writes: > Hi, > > RFC6110 says the following: > -------------------------------------------------- > 8.2. Modularity > > Named pattern definitions that are mapped from non-top-level YANG > groupings MUST be placed inside the embedded grammar corresponding to > the YANG module where the grouping is defined. > > > 10.20. The 'grouping' Statement > > As explained in Section 8.2, a named pattern definition MUST be > placed: > > o as a child of the root element if the corresponding > grouping is defined at the top level of an input YANG module; > > o otherwise as a child of the embedded element > corresponding to the module in which the grouping is defined. > > > 10.54. The 'typedef' Statement > > This statement is mapped to a RELAX NG named pattern definition define>, but only if the type defined by this statement is used > without restrictions in at least one of the input modules. In this > case, the named pattern definition becomes a child of either the root > or an embedded element, depending on whether or not the > 'typedef' statement appears at the top level of a YANG module. The > name of this named pattern definition is set to ARGUMENT mangled > according to the rules specified in Section 9.2. > -------------------------------------------------- > > If this text is strictly followed a syntactically incorrect hybrid RNG > schema will get generated by an implementation in case a grouping or a > typedef is defined within the subtree of a used top-level grouping. One > will end up with a global definition which references named patterns > from local (embedded) grammars. This cannot be done in RNG. > > After global definitions get separated into a separate include file it > breaks completely. A standalone RNG grammar needs all referenced > definitions in the same grammar (through local definitions or included > ones). > > I fixed this in our implementation by treating any typedef or a grouping > located within a used top-level grouping as a global definition but > Ladislav suggested, that this may lead to name clashes (I agree). > However I believe this could be solved with another name-mangling rule > in section 9.2 which handles this special corner case. Example (module > "test"): > > typedef g1 { ... } > > grouping g1 { > container foo { > grouping inner { > ... > } > typedef inner { ... } > ... > } > } > > container g1 { > container foo { > grouping inner { > ... > } > typedef inner { ... } > ... > } > } > > When "g1" grouping gets used and module "test" is also an input module: > > test__g1 (global rng:define for the top-level typedef) > _test__g1 (global rng:define for the top-level grouping) > _test__special_prefix__g1__foo__inner (global rng:define for first inner > grouping) > test__special_prefix__g1__foo__inner (global rng:define for first inner > typedef) > _test__g1__foo__inner (local rng:define for second inner grouping) > test__g1__foo__inner (local rng:define for second inner typedef) > > There is no way to define another top-level schema node, grouping or > typedef named "g1" in this module, so it should be okay. I could be > missing something though. This also exposes internal definitions which > may not be what a YANG modeler would want. > > This is how our implementation currently does it. > > Jernej > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Tue Nov 6 10:35:54 2012 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 03FA421F8A6C for ; Tue, 6 Nov 2012 10:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu9dNMuBY3Sp for ; Tue, 6 Nov 2012 10:35:51 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id CBFBE21F8A6B for ; Tue, 6 Nov 2012 10:35:50 -0800 (PST) Received: from localhost (dhcp-17d4.meeting.ietf.org [130.129.23.212]) by mail.tail-f.com (Postfix) with ESMTPSA id 18C931200A6E; Tue, 6 Nov 2012 19:35:47 +0100 (CET) Date: Tue, 06 Nov 2012 13:35:47 -0500 (EST) Message-Id: <20121106.133547.512035974.mbj@tail-f.com> To: wjhns1@hardakers.net From: Martin Bjorklund In-Reply-To: <0l8vaj73tz.fsf@wjh.hardakers.net> References: <0l8vaj73tz.fsf@wjh.hardakers.net> 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] review of netmod-snmp-cfg 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, 06 Nov 2012 18:35:54 -0000 Hi Wes, Thank you for this review, comments inline! Wes Hardaker wrote: > > I reviewed, as promised at the last IETF, the netmod-snmp-cfg-00 > document; in particular with respect to the TLS parts of it but I also > reviewed the USM configuration too. Here's the notes I wrote up about > it (in no particular order): > > 1) Should, at least, the key objects be marked as nacm:default-deny-all? > It's extremely sensitive data. I'm not a yang expert and didn't look > up the rules, so I'm not sure if it needs to go into the 'grouping' > statement or in the 'uses' places. Yes. We didn't have NACM when we started this, but now that we have we should use it. > 2) the usm container has two user groupings: local and remote. The > local user set doesn't have an engineID associated with it, but local > userIDs certainly do have an engineID (the local one). Most > importantly, the user in an SNMP agent would still be there and valid > if the SNMP agent's engineID is changed (administratively) and would > be attached to the *old* engineID. But with the netconf setup, the > user table would move right along to the new one and the (localized) > key actually wouldn't be usable if the manager was deriving the key > from a master key or password. > > In short: I think the local users need to be associated with the > engineID too, since that's how every SNMPv3 engine out there > fundamentally thinks. Well, as you say, local users *does* have an engine id, but it is implicit. It is always the local one. So if the local engine id changes (which should be rare), the keys have to be updated. So one change in the YANG view (engine-id), implies many changes in the SNMP tables (all local users are changed). I don't think this is inconsistent with the MIB model. > And if the engineID changes within an SNMPv3 > engine, the user table needs to still exist *as it was before the > change*. A netconf dump, followed by an engineID change (inside or > outside the yang data), followed by a restore will not let this > happen properly. > > 3) the various references to "type security-level" need to be changed to > "type snmp:security-level" (I think). And probably for > "admin-string" too. They don't have to, but we should be consistent, and snmp: is more clear, I agree. > 4) The snmp:target augmentation for the usm I don't think is fully > flexible enough. The augmentation is only done with USM, but I'm not > positive that's a good idea. USM happens to be the first and only > security model to use an engineID, but much of the v3 architecture > seems to believe that other security models would likely have them > too. But I'm not 100% sure about this. One option could be to remove this leaf, and do what RFC 3412 says - determine the engine id in an implementation-specific manner. Another option could be to rename the leaf to engine-id-for-usm or something. > 5) I know this was discussed heavily before, but I don't remember the > results... The yang model(s) imposes a number of constraints to the > data that don't exist in any current implementations. Things like > references that "must" exist, etc. I certainly understand the fact > that in many cases the model as implemented in SNMP had to be done > that way since SNMP doesn't have the power of netconf and sending > lots of data at once and piece-by-piece uploading needed to be > supported. And thus, when we get to wrapping yang around past models > "it's our chance to fix the model and impose proper constraints". Actually, I think we removed all of these restrictions, based on your previous comments. What did we miss? (ok, the choice in 10 below is one) > 6) the tls-fingerprint typedef allows for 6-64 repeats of hex characters > (and obviously :s inbetween). But the SNMP definition is 0-255 (with > a 1 octet prefix if non-zero). I'm not sure why {4,31} was chosen, > but it doesn't seem to match the flexibility in the MIB nor in the > IANA registry. Copy & paste bug. > 7) There is no commonname mapping identity Bug. > 8) there are multiple "FIXME" things that, um, probably need to be fixed :-) I guess so... > 9) The cert-specified-tm-security-name "FIXME" wonders if it should be a > generic text in order to be as flexible as the MIB, or whether it > to remove the identities and use augmentation. My take is that the > MIB was done generically because augmentation of tables is a pain in > SNMP and that's one of the benefits of netconf, so I'd do it the > netconf way and say that cert-specified-tm-security-name needs to > exist if map-type == specified. Future mappings, if ever actually > created, can create new augmentations where the data field in the > SNMP mib may mean something different but can be contained in a > different netconf variable. It makes the netconf data cleaner and > clearer, while still allowing the netconf agent to magically map the > two together. But, you do need to say something like "if multiple > data fields are defined in the netconf data, then only the current > mapping type data will be saved to the corresponding MIB object and > the other will be lost" or something. Ok. > 10) the server-identification choice will be losing mib data if netconf > pulls it out and then puts it back because only one set of MIB data > will be kept (specifically, the snmpTlstmAddrServerFingerprint must > take priority and be kept while the other is dropped, though you'd > have to read the MIB to understand that. Ok, so you suggest we remove the choice? > [I realize this losing of data is a fairly common one with netconf to > snmp configuration mappings when "choice" or other restrictive data > components are used; this is actually likely to be a common problem > among many data models where we decide that netconf is going to be > more restrictive than an implementation; eg, consider transferring > DNS data where there is a choice of CNAME or anything-else; > unfortunately real world people put both CNAMEs and MX records at > the same location in the DNS even though the protocol specifies this > shouldn't be done; nothing enforces it though] > > 11) the snmp params vs address separation in the target mib was done > that way to reduce the data sent when zillions of addresses are > targets and they all use the same client authentication components > (eg, one TLS client-side certificate). The netconf implementation > of the target mib and the tls related components seem to require > that all that client data be duplicated for every remote > address. Yes. "all client data" is in this case one leaf, the fingerprint. But see below... > That means if a netconf manager needs to change out the client side > certificate it'll need to probably pull and replace the whole table > since it can't simply "edit" a single row to replace the client > fingerprint with a simple edit operation. I assume this is by > design on the netconf side, but it is discarding some of the point > of the original designed of the SNMP target mib: to separate the > client side authentication from the address lists that you might > talk to in order to simplify updating the client data components? There is always a tradeoff when you decide if you should you an inderection or inline the data. Inlining is easier, but indirection is more flexible. If we believe that there will be zillions (or at least "many") of targets and the client certificate is changed often enough, then we should keep the indirection. /martin From randy_presuhn@mindspring.com Tue Nov 6 11:00:17 2012 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 92EC021F8A97 for ; Tue, 6 Nov 2012 11:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.81 X-Spam-Level: X-Spam-Status: No, score=-97.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KUJnnwv-iBH for ; Tue, 6 Nov 2012 11:00:16 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 395D121F8A96 for ; Tue, 6 Nov 2012 11:00:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=eq/HLQISabrkHkyrOMI5MK/Pw351sU7lf5ATYF5zQegtKkCaIwOnTBzJcL8y6Ygk; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.227.225] (helo=oemcomputer) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TVoNe-0007pp-2S for netmod@ietf.org; Tue, 06 Nov 2012 14:00:10 -0500 Message-ID: <006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <0l8vaj73tz.fsf@wjh.hardakers.net> <20121106.133547.512035974.mbj@tail-f.com> Date: Wed, 7 Nov 2012 11:00:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e26eac4f6630fd7bdfe4c446531b9b7b6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.227.225 Subject: Re: [netmod] review of netmod-snmp-cfg 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, 06 Nov 2012 19:00:18 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, November 06, 2012 10:35 AM > Subject: Re: [netmod] review of netmod-snmp-cfg ... > > 2) the usm container has two user groupings: local and remote. The > > local user set doesn't have an engineID associated with it, but local > > userIDs certainly do have an engineID (the local one). Most > > importantly, the user in an SNMP agent would still be there and valid > > if the SNMP agent's engineID is changed (administratively) and would > > be attached to the *old* engineID. But with the netconf setup, the > > user table would move right along to the new one and the (localized) > > key actually wouldn't be usable if the manager was deriving the key > > from a master key or password. > > > > In short: I think the local users need to be associated with the > > engineID too, since that's how every SNMPv3 engine out there > > fundamentally thinks. > > Well, as you say, local users *does* have an engine id, but it is > implicit. It is always the local one. So if the local engine id > changes (which should be rare), the keys have to be updated. > > So one change in the YANG view (engine-id), implies many changes in > the SNMP tables (all local users are changed). I don't think this is > inconsistent with the MIB model. Just to be absolutely clear: if the only information on hand is the "old" engine id, the "new" engine id, and a set of localized keys, computing the new set of localized keys is computationally infeasible by design. > > And if the engineID changes within an SNMPv3 > > engine, the user table needs to still exist *as it was before the > > change*. A netconf dump, followed by an engineID change (inside or > > outside the yang data), followed by a restore will not let this > > happen properly. Particularly in the case where the keys in use were *not* generated by a localization algorithm! Randy From mbj@tail-f.com Tue Nov 6 11:12:45 2012 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 D74BC21F8AF9 for ; Tue, 6 Nov 2012 11:12:45 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heEA8SFZ2fIU for ; Tue, 6 Nov 2012 11:12:45 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 40B8D21F84E0 for ; Tue, 6 Nov 2012 11:12:45 -0800 (PST) Received: from localhost (dhcp-17d4.meeting.ietf.org [130.129.23.212]) by mail.tail-f.com (Postfix) with ESMTPSA id A3AEC1200A6E; Tue, 6 Nov 2012 20:12:43 +0100 (CET) Date: Tue, 06 Nov 2012 14:12:41 -0500 (EST) Message-Id: <20121106.141241.530999387.mbj@tail-f.com> To: randy_presuhn@mindspring.com From: Martin Bjorklund In-Reply-To: <006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> References: <0l8vaj73tz.fsf@wjh.hardakers.net> <20121106.133547.512035974.mbj@tail-f.com> <006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> 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] review of netmod-snmp-cfg 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, 06 Nov 2012 19:12:46 -0000 "Randy Presuhn" wrote: > Hi - > > > From: "Martin Bjorklund" > > To: > > Cc: > > Sent: Tuesday, November 06, 2012 10:35 AM > > Subject: Re: [netmod] review of netmod-snmp-cfg > > > ... > > > 2) the usm container has two user groupings: local and remote. The > > > local user set doesn't have an engineID associated with it, but local > > > userIDs certainly do have an engineID (the local one). Most > > > importantly, the user in an SNMP agent would still be there and valid > > > if the SNMP agent's engineID is changed (administratively) and would > > > be attached to the *old* engineID. But with the netconf setup, the > > > user table would move right along to the new one and the (localized) > > > key actually wouldn't be usable if the manager was deriving the key > > > from a master key or password. > > > > > > In short: I think the local users need to be associated with the > > > engineID too, since that's how every SNMPv3 engine out there > > > fundamentally thinks. > > > > Well, as you say, local users *does* have an engine id, but it is > > implicit. It is always the local one. So if the local engine id > > changes (which should be rare), the keys have to be updated. > > > > So one change in the YANG view (engine-id), implies many changes in > > the SNMP tables (all local users are changed). I don't think this is > > inconsistent with the MIB model. > > Just to be absolutely clear: if the only information on hand is > the "old" engine id, the "new" engine id, and a set of localized > keys, computing the new set of localized keys is computationally > infeasible by design. Sure. So the keys needs to be re-calculated. This is of course not different from what you have to do with normal usm if the engine id is changed. > > > And if the engineID changes within an SNMPv3 > > > engine, the user table needs to still exist *as it was before the > > > change*. A netconf dump, followed by an engineID change (inside or > > > outside the yang data), followed by a restore will not let this > > > happen properly. > > Particularly in the case where the keys in use were *not* generated by > a localization algorithm! Can the keys be non-localized? It seems 3414 just talks about the key being localized. But if the key is not localized, it doesn't matter if the engine id is modified, right? /martin From randy_presuhn@mindspring.com Tue Nov 6 11:42:16 2012 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 192E421F8A4D for ; Tue, 6 Nov 2012 11:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.81 X-Spam-Level: X-Spam-Status: No, score=-97.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUwwAlVnF6HU for ; Tue, 6 Nov 2012 11:42:15 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 60C7621F8A2B for ; Tue, 6 Nov 2012 11:42:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=ZbYJejqaQo2eosjzh9H9hSq56qmS8VlzVUrAZF1r4HvjYdRsviqL9kdHDF0MrfIZ; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.227.225] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TVp2M-0000zX-HF for netmod@ietf.org; Tue, 06 Nov 2012 14:42:14 -0500 Message-ID: <000e01cdbd1f$fc479d40$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <0l8vaj73tz.fsf@wjh.hardakers.net><20121106.133547.512035974.mbj@tail-f.com><006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> <20121106.141241.530999387.mbj@tail-f.com> Date: Wed, 7 Nov 2012 11:42:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97ee7841c7767964677c39d0cdc1b3a5b62350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.227.225 Subject: Re: [netmod] review of netmod-snmp-cfg 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, 06 Nov 2012 19:42:16 -0000 Hi - > From: "Martin Bjorklund" > To: > Cc: > Sent: Tuesday, November 06, 2012 11:12 AM > Subject: Re: [netmod] review of netmod-snmp-cfg > > "Randy Presuhn" wrote: > > Hi - > > > > > From: "Martin Bjorklund" > > > To: > > > Cc: > > > Sent: Tuesday, November 06, 2012 10:35 AM > > > Subject: Re: [netmod] review of netmod-snmp-cfg > > > > > > ... > > > > 2) the usm container has two user groupings: local and remote. The > > > > local user set doesn't have an engineID associated with it, but local > > > > userIDs certainly do have an engineID (the local one). Most > > > > importantly, the user in an SNMP agent would still be there and valid > > > > if the SNMP agent's engineID is changed (administratively) and would > > > > be attached to the *old* engineID. But with the netconf setup, the > > > > user table would move right along to the new one and the (localized) > > > > key actually wouldn't be usable if the manager was deriving the key > > > > from a master key or password. > > > > > > > > In short: I think the local users need to be associated with the > > > > engineID too, since that's how every SNMPv3 engine out there > > > > fundamentally thinks. > > > > > > Well, as you say, local users *does* have an engine id, but it is > > > implicit. It is always the local one. So if the local engine id > > > changes (which should be rare), the keys have to be updated. > > > > > > So one change in the YANG view (engine-id), implies many changes in > > > the SNMP tables (all local users are changed). I don't think this is > > > inconsistent with the MIB model. > > > > Just to be absolutely clear: if the only information on hand is > > the "old" engine id, the "new" engine id, and a set of localized > > keys, computing the new set of localized keys is computationally > > infeasible by design. > > Sure. So the keys needs to be re-calculated. This is of course not > different from what you have to do with normal usm if the engine id is > changed. The point is that the information necessary for recalculation is NOT THERE. By design. Changing the engineId should normally require the user to re-supply the master key (since master keys should not be stored) if localized keys are to be used. > > > > And if the engineID changes within an SNMPv3 > > > > engine, the user table needs to still exist *as it was before the > > > > change*. A netconf dump, followed by an engineID change (inside or > > > > outside the yang data), followed by a restore will not let this > > > > happen properly. > > > > Particularly in the case where the keys in use were *not* generated by > > a localization algorithm! > > Can the keys be non-localized? It seems 3414 just talks about the key > being localized. Yes. There's nothing in the way USM works that requires keys to have been be derived using a localization algorithm. Using localized keys is a matter of maintaining a reasonable level of security while respecting the limits of human memory - an operational question, rather than a matter of interoperability. > But if the key is not localized, it doesn't matter if the engine id is > modified, right? That is correct. The administrator (or the administrator's tool) needs to know whether to employ a master key + engineID + localization algorithm, or a key directly supplied by the user, or possibly something else. How the key was derived is not recorded in the MIB, since USM doesn't know or care how the key came to be. Randy From j.schoenwaelder@jacobs-university.de Tue Nov 6 12:24:01 2012 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 758D521F8A14 for ; Tue, 6 Nov 2012 12:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzLPPwrP-5cA for ; Tue, 6 Nov 2012 12:24:00 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE6721F84D6 for ; Tue, 6 Nov 2012 12:23:59 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 397D620C04; Tue, 6 Nov 2012 21:23:58 +0100 (CET) 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 8Jf9j-Fm-2iT; Tue, 6 Nov 2012 21:23:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 67AC820BE1; Tue, 6 Nov 2012 21:23:56 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D36D222AE968; Tue, 6 Nov 2012 21:23:58 +0100 (CET) Date: Tue, 6 Nov 2012 21:23:58 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Message-ID: <20121106202358.GA73028@elstar.local> Mail-Followup-To: Randy Presuhn , netmod@ietf.org References: <0l8vaj73tz.fsf@wjh.hardakers.net> <20121106.133547.512035974.mbj@tail-f.com> <006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> <20121106.141241.530999387.mbj@tail-f.com> <000e01cdbd1f$fc479d40$6b01a8c0@oemcomputer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000e01cdbd1f$fc479d40$6b01a8c0@oemcomputer> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] review of netmod-snmp-cfg 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, 06 Nov 2012 20:24:01 -0000 On Wed, Nov 07, 2012 at 11:42:12AM -0800, Randy Presuhn wrote: > > > > Can the keys be non-localized? It seems 3414 just talks about the key > > being localized. > > Yes. > > There's nothing in the way USM works that requires keys to have been > be derived using a localization algorithm. Using localized keys is a > matter of maintaining a reasonable level of security while respecting > the limits of human memory - an operational question, rather than a > matter of interoperability. Sure? The RFC 3414 elements of procedure talk at several places about localized keys. Are you saying that this is just a term that might also mean non-localized keys? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From randy_presuhn@mindspring.com Tue Nov 6 13:42:34 2012 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 D35F821F847B for ; Tue, 6 Nov 2012 13:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.81 X-Spam-Level: X-Spam-Status: No, score=-97.81 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNwlwY0l5Pf8 for ; Tue, 6 Nov 2012 13:42:34 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2221F8A0C for ; Tue, 6 Nov 2012 13:42:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=sZK3qAhVaDGK32DEoyDJv40i7zCJtzXDkhjVQ21YMjiM4UUnJM8WIbD43f7BXicM; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.35.227.225] (helo=oemcomputer) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1TVqun-00010F-H1 for netmod@ietf.org; Tue, 06 Nov 2012 16:42:33 -0500 Message-ID: <000401cdbd30$ca0ad5c0$6b01a8c0@oemcomputer> From: "Randy Presuhn" To: References: <0l8vaj73tz.fsf@wjh.hardakers.net> <20121106.133547.512035974.mbj@tail-f.com> <006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> <20121106.141241.530999387.mbj@tail-f.com> <000e01cdbd1f$fc479d40$6b01a8c0@oemcomputer> <20121106202358.GA73028@elstar.local> Date: Wed, 7 Nov 2012 13:42:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88868e0cd313c0eb97e8cc5107e0ce36c94f49c62ef96023dd3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.35.227.225 Subject: Re: [netmod] review of netmod-snmp-cfg 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, 06 Nov 2012 21:42:34 -0000 Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Tuesday, November 06, 2012 12:23 PM > Subject: Re: [netmod] review of netmod-snmp-cfg ... > Sure? The RFC 3414 elements of procedure talk at several places about > localized keys. Are you saying that this is just a term that might > also mean non-localized keys? Yes. In those places there are typically words like "the user's localized private privKey is the secret key that can be used by the decryption algorithm." Whatever secret key happens to be there is referred to as "localized private". The authentication and privacy algorithms work whether the keys are derived using a localization algorithm or not. This is a little clearer in section 11.2, where it says "If the Appendix A algorithm is used..." Note the "if". Use of that (or some other!) key localization algorithm is optional. *Implementation* of the key localization algorithm is required (in 11.3), but the specification of the algorithms (A.2) also makes it clear that their *use* is optional. I'm certainly NOT going to recommend that folks start using non-localized keys as a matter of day-to-day practice! But I do think we need to recognize that the specification does *permit* their use. Randy From wjhns1@hardakers.net Tue Nov 6 13:54:58 2012 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 B573C21F8B87 for ; Tue, 6 Nov 2012 13:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr0tHeUcW9oQ for ; Tue, 6 Nov 2012 13:54:55 -0800 (PST) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D4A21F8B8B for ; Tue, 6 Nov 2012 13:54:44 -0800 (PST) Received: from localhost (unknown [IPv6:2001:df8:0:16:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 9E69533B; Tue, 6 Nov 2012 13:54:38 -0800 (PST) From: Wes Hardaker To: Randy Presuhn References: <0l8vaj73tz.fsf@wjh.hardakers.net> <20121106.133547.512035974.mbj@tail-f.com> <006701cdbd1a$1bb29460$6b01a8c0@oemcomputer> <20121106.141241.530999387.mbj@tail-f.com> <000e01cdbd1f$fc479d40$6b01a8c0@oemcomputer> <20121106202358.GA73028@elstar.local> Date: Tue, 06 Nov 2012 13:54:37 -0800 In-Reply-To: <20121106202358.GA73028@elstar.local> (Juergen Schoenwaelder's message of "Tue, 6 Nov 2012 21:23:58 +0100") Message-ID: <0l7gpymm76.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] review of netmod-snmp-cfg 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, 06 Nov 2012 21:54:58 -0000 Juergen Schoenwaelder writes: >> There's nothing in the way USM works that requires keys to have been >> be derived using a localization algorithm. Using localized keys is a >> matter of maintaining a reasonable level of security while respecting >> the limits of human memory - an operational question, rather than a >> matter of interoperability. > > Sure? The RFC 3414 elements of procedure talk at several places about > localized keys. Are you saying that this is just a term that might > also mean non-localized keys? I've always described it to people thusly: +----------+ +--------+ +-----------+ | master | | master | | localized | | password | --> | key | --> | key | +----------+ +--------+ +-----------+ You can start with any particular point to get to the final box. You can use random bits to generate a "localized key" if you want, and upload it to the box (inside or outside of SNMP itself) and it'll work just fine. Or you can start with a master key and use that master key (and the local engineID) to generate the localized key. Or you can start with a human password, use that to generate the master key and then ... And yes, I'm sure, because I've written the code to support it (and verified it works with a bunch of other implementations). Oh, and the SNMP-USNM-DH-OBJECTS-MIB and related RFC *could not* work without this ability :-) -- Wes Hardaker SPARTA, Inc. From equinox@diac24.net Tue Nov 6 15:00:37 2012 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 2CCC621F84BA for ; Tue, 6 Nov 2012 15:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hii-DChiBMw for ; Tue, 6 Nov 2012 15:00:35 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 356FB21F84A5 for ; Tue, 6 Nov 2012 15:00:35 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TVs8G-0000Ey-AN for netmod@ietf.org; Wed, 07 Nov 2012 00:00:32 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1TVs83-0094Wn-Nq for netmod@ietf.org; Wed, 07 Nov 2012 00:00:21 +0100 Date: Tue, 6 Nov 2012 18:00:19 -0500 From: David Lamparter To: netmod@ietf.org Message-ID: <20121106230019.GO1927048@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="54u2kuW9sGWg/X+X" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 06 Nov 2012 23:00:37 -0000 --54u2kuW9sGWg/X+X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I just commented about some weirdness with the MTU field in the interfaces draft. Here's a quote for reference: leaf mtu { type uint32; description "The size, in octets, of the largest packet that the interface can send and receive. This node might not be valid for all interface types. Media-specific modules must specify any restrictions on the mtu for their interface type."; reference "RFC 2863: The Interfaces Group MIB - ifMtu"; } The problem is quite simply that this doesn't say if it's referring to L2 or L3 MTU. I understand that there's some kind of consensus in usage =66rom history, but that's not useful in a specification if it's not written down. Aspects of the different values are: - L2: - it's the actual interface property - might make sense to have a max-mtu(ro) and mtu(rw) to support reducing allocated buffer sizes & such., but I believe that hosts can well handle that automatically - fits the location, we're below L3 in context - slightly confusing for subinterfaces. Let's say I have ethernet with 2 stacked 1Q labels. Is the mtu on the innermost still the same as on the parent ethernet, or is it reduced by 8? =3D> specification needed - better name: mfs (maximum frame size) - L3: - actually useful value - makes more sense with stacked encapsulations since it's clearly defined that it's returning the usable value with all overhead applied Relatedly, I see the need to add a MTU field on the IPv4/IPv6 levels. (Which is going to be fun dealing with for example on Linux because it only supports one value, but well... that's a Linux problem really.) Cheers, -David --54u2kuW9sGWg/X+X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCZloMACgkQCy20tTec6eMU/QD+L2q6jEuFJbRYaYxdG0FYYDDK gkEkDy2Rx54T3yM1QDYA/3c0eoJFfEUZK0t/sNl4J8INPGoRAw7RqfVWqh14KXdR =mzum -----END PGP SIGNATURE----- --54u2kuW9sGWg/X+X-- From j.schoenwaelder@jacobs-university.de Wed Nov 7 04:22:24 2012 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 B60A221F89B3 for ; Wed, 7 Nov 2012 04:22:24 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCMs5soNXApt for ; Wed, 7 Nov 2012 04:22:23 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 78E6121F89A3 for ; Wed, 7 Nov 2012 04:22:23 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 806E420C17; Wed, 7 Nov 2012 13:22:22 +0100 (CET) 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 n5luHdEXbOSZ; Wed, 7 Nov 2012 13:22:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1542F20C15; Wed, 7 Nov 2012 13:22:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 125DA22AFA87; Wed, 7 Nov 2012 13:22:23 +0100 (CET) Date: Wed, 7 Nov 2012 13:22:23 +0100 From: Juergen Schoenwaelder To: David Lamparter Message-ID: <20121107122223.GA77037@elstar.local> Mail-Followup-To: David Lamparter , netmod@ietf.org References: <20121106230019.GO1927048@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121106230019.GO1927048@jupiter.n2.diac24.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 12:22:24 -0000 On Tue, Nov 06, 2012 at 06:00:19PM -0500, David Lamparter wrote: > Hi, > > > I just commented about some weirdness with the MTU field in the > interfaces draft. Here's a quote for reference: > leaf mtu { > type uint32; > description > "The size, in octets, of the largest packet that the > interface can send and receive. This node might not be > valid for all interface types. > > Media-specific modules must specify any restrictions on > the mtu for their interface type."; > reference > "RFC 2863: The Interfaces Group MIB - ifMtu"; > } > > The problem is quite simply that this doesn't say if it's referring to > L2 or L3 MTU. I understand that there's some kind of consensus in usage > from history, but that's not useful in a specification if it's not > written down. > > Aspects of the different values are: > - L2: > - it's the actual interface property > - might make sense to have a max-mtu(ro) and mtu(rw) to support > reducing allocated buffer sizes & such., but I believe that hosts > can well handle that automatically > - fits the location, we're below L3 in context > - slightly confusing for subinterfaces. Let's say I have ethernet > with 2 stacked 1Q labels. Is the mtu on the innermost still the > same as on the parent ethernet, or is it reduced by 8? > => specification needed > - better name: mfs (maximum frame size) > - L3: > - actually useful value > - makes more sense with stacked encapsulations since it's clearly > defined that it's returning the usable value with all overhead > applied > > Relatedly, I see the need to add a MTU field on the IPv4/IPv6 levels. > (Which is going to be fun dealing with for example on Linux because it > only supports one value, but well... that's a Linux problem really.) Here is the definition of ifMtu in RFC 2863: "The size of the largest packet which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface." This says its the largest overall frame size except if you run IP over it (or some other protocol sending "network datagrams"), then it is the largest payload size. What are our options? 1) drop the interface mtu leaf and instead add an IP config mtu leaf (since this is what we understand well) 2) like 1) but add a generic read-only leaf to report the maximum frame size actually used, (that means to configure it, you need interface type specific data model extensions) 3) like 2) but add another generic leaf to report the maximum frame size possible as a read-only leaf (e.g. useful to learn whether an ethernetCsmacd interface supports jumbo frames) Anything else? /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 Nov 7 04:36:17 2012 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 9D3FA21F8B02 for ; Wed, 7 Nov 2012 04:36:17 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmBcT2PJ6+FM for ; Wed, 7 Nov 2012 04:36:17 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1180921F8ADD for ; Wed, 7 Nov 2012 04:36:17 -0800 (PST) Received: from localhost (dhcp-412b.meeting.ietf.org [130.129.65.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 179371200A6E for ; Wed, 7 Nov 2012 13:36:14 +0100 (CET) Date: Wed, 07 Nov 2012 07:36:12 -0500 (EST) Message-Id: <20121107.073612.358155100.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund 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: [netmod] comments on draft-ietf-netmod-routing-cfg-05 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, 07 Nov 2012 12:36:17 -0000 Hi, I have some minor comments: o Section 4.3 One or more routing tables MUST be configured for each address family supported by the server. Each router instance MUST designate, for every address family that the router instance supports, exactly one routing table as its main routing table. I don't think it is correct to use MUST like this. As an implementor, what am I supposed to do with these MUST statements? I would think that what the configuration looks like is the operator's task. o Section 4.3 o By default, a routing protocol SHOULD be connected to the main routing table of each address family supported by that routing protocol. See Section 4.4 for further explanation. I think that either s/SHOULD be/MUST be/ or s/SHOULD be/is/ This means that if the operator has not configured the system differently, the implementation must connect it to the main routing table. (The same SHOULD occurs in 4.4 and in the YANG module in one place) o Section 4.4.2 In order to make the document easier to read, I suggest you simply refer to the Appendix in this section, instead of inlining essentially the entire module. If you do this, I suggest you change your descriptive text into comments that you put in the Appendix. o Section 5 In all cases, the relevant parts of the core routing data model are disabled but MUST NOT be deleted from the configuration by the server. On a first read, I couldn't understand what this meant. After reading the rest of the section, I think I know what you mean, but I think you can make this simpler by removing the paragraph. I think the text is confusing b/c it kind of implies that if this paragraph was not there, an implementation could choose to delete the relevant parts of the configuration, and that would be just weird. o Many XPath expressions use the "//" construct for no apparent reason. It should be a single "/". o The example-rip module's filename has a revision date, but there is no revision statement in the module. I suggest you remove the revision statement from the filename (since this is just an example). /martin From jeffrey.K.lange@ge.com Wed Nov 7 05:52:53 2012 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 A40FA21F8B26 for ; Wed, 7 Nov 2012 05:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq5W7wd1kG+d for ; Wed, 7 Nov 2012 05:52:53 -0800 (PST) Received: from exprod5og108.obsmtp.com (exprod5og108.obsmtp.com [64.18.0.186]) by ietfa.amsl.com (Postfix) with ESMTP id DF01B21F8AD6 for ; Wed, 7 Nov 2012 05:52:51 -0800 (PST) Received: from alpmlip14.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob108.postini.com ([64.18.4.12]) with SMTP ID DSNKUJpnsx8/kD3sH1Dru5ZL0R7XlxcmKt4X@postini.com; Wed, 07 Nov 2012 05:52:52 PST Received: from unknown (HELO cinmlef07.e2k.ad.ge.com) ([3.159.213.38]) by alpmlip14.e2k.ad.ge.com with ESMTP; 07 Nov 2012 08:52:31 -0500 Received: from CINMLCH02.e2k.ad.ge.com ([3.159.212.51]) by cinmlef07.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 08:52:30 -0500 Received: from CINMBCNA01.e2k.ad.ge.com (3.159.212.55) by CINMLCH02.e2k.ad.ge.com (3.159.212.51) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 7 Nov 2012 08:52:28 -0500 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.108]) by CINMBCNA01.e2k.ad.ge.com ([169.254.1.62]) with mapi id 14.02.0309.002; Wed, 7 Nov 2012 08:52:28 -0500 From: "Lange, Jeffrey K (GE Energy)" To: "netmod@ietf.org" Thread-Topic: Attempts and timeouts in ietf-system Thread-Index: Ac287x9zlrwRMnwDQiaT8XBOJEpSjQ== Date: Wed, 7 Nov 2012 13:52:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [3.159.212.187] Content-Type: multipart/alternative; boundary="_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A8BDCINMBCNA02e2kad_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2012 13:52:30.0207 (UTC) FILETIME=[211878F0:01CDBCEF] Subject: [netmod] Attempts and timeouts in ietf-system 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, 07 Nov 2012 13:52:53 -0000 --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A8BDCINMBCNA02e2kad_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ietf-system model defines timeout and attempts leafs for both DNS and R= ADIUS servers as uint8 with no range. This results in some ambiguity as to= what the value of 0 means? Does a server with attempts set to 0 mean it's= in essence disabled? Does a timeout of 0 imply it should wait forever? I think that all of these fields should have a range from 1..n, it just do= esn't make sense to allow a zero value for these leafs. Jeff Lange Lead Software Engineer GE Energy Services Digital Energy --_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A8BDCINMBCNA02e2kad_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ietf-system model defines timeout and attempts l= eafs for both DNS and RADIUS servers as uint8 with no range.  This res= ults in some ambiguity as to what the value of 0 means?  Does a server= with attempts set to 0 mean it’s in essence disabled?  Does a timeout of 0 imply it should wait forever?

 

I think that all of these fields should have a = range from 1..n, it just doesn’t make sense to allow a zero value fo= r these leafs.

 

 

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy

 

--_000_B0FB1FAC2C7B234D87DCEBF309F703C51BB0A8BDCINMBCNA02e2kad_-- From lhotka@nic.cz Wed Nov 7 06:40:00 2012 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 9219821F8B4A for ; Wed, 7 Nov 2012 06:40:00 -0800 (PST) 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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XaVMA9mJt9x for ; Wed, 7 Nov 2012 06:39:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AB82321F8582 for ; Wed, 7 Nov 2012 06:39:58 -0800 (PST) Received: from dhcp-113f.meeting.ietf.org (dhcp-113f.meeting.ietf.org [130.129.17.63]) by mail.nic.cz (Postfix) with ESMTPSA id 88D9E140467 for ; Wed, 7 Nov 2012 15:39:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1352299197; bh=JZQa4ovqWkGoYdV1QgHjugbrZkwzXj0jaZ9Xct5PjbA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=leGMJ34jfVBDmYaIKDKvRFfhQ29vPHScQVcCJCM4HGEaDFlf7SMQNvRrQCIlc2cS2 pNQ4w2QIPdJFFBPBM0HiIqOfDuaGqE3nodo3xbk8MNlffAM51eVs0mY1T85iuQwh5x CdnyvB2WP0q+adGDS3isj9Za0JqmmVBvMnb/HOdg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121107122223.GA77037@elstar.local> Date: Wed, 7 Nov 2012 09:39:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> References: <20121106230019.GO1927048@jupiter.n2.diac24.net> <20121107122223.GA77037@elstar.local> To: netmod@ietf.org X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 14:40:00 -0000 On Nov 7, 2012, at 7:22 AM, Juergen Schoenwaelder = wrote: > On Tue, Nov 06, 2012 at 06:00:19PM -0500, David Lamparter wrote: >> Hi, >>=20 >>=20 >> I just commented about some weirdness with the MTU field in the >> interfaces draft. Here's a quote for reference: >> leaf mtu { >> type uint32; >> description >> "The size, in octets, of the largest packet that the >> interface can send and receive. This node might not be >> valid for all interface types. >>=20 >> Media-specific modules must specify any restrictions on >> the mtu for their interface type."; >> reference >> "RFC 2863: The Interfaces Group MIB - ifMtu"; >> } >>=20 >> The problem is quite simply that this doesn't say if it's referring = to >> L2 or L3 MTU. I understand that there's some kind of consensus in = usage >> from history, but that's not useful in a specification if it's not >> written down. >>=20 >> Aspects of the different values are: >> - L2: >> - it's the actual interface property >> - might make sense to have a max-mtu(ro) and mtu(rw) to support >> reducing allocated buffer sizes & such., but I believe that hosts >> can well handle that automatically >> - fits the location, we're below L3 in context >> - slightly confusing for subinterfaces. Let's say I have ethernet >> with 2 stacked 1Q labels. Is the mtu on the innermost still the >> same as on the parent ethernet, or is it reduced by 8? >> =3D> specification needed >> - better name: mfs (maximum frame size) >> - L3: >> - actually useful value >> - makes more sense with stacked encapsulations since it's clearly >> defined that it's returning the usable value with all overhead >> applied >>=20 >> Relatedly, I see the need to add a MTU field on the IPv4/IPv6 levels. >> (Which is going to be fun dealing with for example on Linux because = it >> only supports one value, but well... that's a Linux problem really.) >=20 > Here is the definition of ifMtu in RFC 2863: >=20 > "The size of the largest packet which can be sent/received > on the interface, specified in octets. For interfaces that > are used for transmitting network datagrams, this is the > size of the largest network datagram that can be sent on the > interface." >=20 > This says its the largest overall frame size except if you run IP over > it (or some other protocol sending "network datagrams"), then it is > the largest payload size. What are our options? >=20 > 1) drop the interface mtu leaf and instead add an IP config mtu leaf > (since this is what we understand well) >=20 > 2) like 1) but add a generic read-only leaf to report the maximum > frame size actually used, (that means to configure it, you need > interface type specific data model extensions) >=20 > 3) like 2) but add another generic leaf to report the maximum frame > size possible as a read-only leaf (e.g. useful to learn whether an > ethernetCsmacd interface supports jumbo frames) I support #1 because some L2 technologies, such as ATM, don't have the = notion of MTU. The future Ethernet module will define it and all should = be fine. Lada >=20 > Anything else? >=20 > /js >=20 > --=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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From equinox@diac24.net Wed Nov 7 07:10:44 2012 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 151A721F8BEA for ; Wed, 7 Nov 2012 07:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNVgjilVly8a for ; Wed, 7 Nov 2012 07:10:43 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id C748921F8C00 for ; Wed, 7 Nov 2012 07:10:40 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TW7H3-00074y-Vs; Wed, 07 Nov 2012 16:10:38 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1TW7Gm-009v1l-Hx; Wed, 07 Nov 2012 16:10:27 +0100 Date: Wed, 7 Nov 2012 10:10:20 -0500 From: David Lamparter To: Ladislav Lhotka Message-ID: <20121107151020.GP1927048@jupiter.n2.diac24.net> References: <20121106230019.GO1927048@jupiter.n2.diac24.net> <20121107122223.GA77037@elstar.local> <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DwoPkXS38qd3dnhB" Content-Disposition: inline In-Reply-To: <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 15:10:44 -0000 --DwoPkXS38qd3dnhB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 07, 2012 at 09:39:58AM -0500, Ladislav Lhotka wrote: >=20 > On Nov 7, 2012, at 7:22 AM, Juergen Schoenwaelder wrote: >=20 > > On Tue, Nov 06, 2012 at 06:00:19PM -0500, David Lamparter wrote: > >> Hi, > >>=20 > >>=20 > >> I just commented about some weirdness with the MTU field in the > >> interfaces draft. Here's a quote for reference: > >> leaf mtu { > >> type uint32; > >> description > >> "The size, in octets, of the largest packet that the > >> interface can send and receive. This node might not be > >> valid for all interface types. > >>=20 > >> Media-specific modules must specify any restrictions on > >> the mtu for their interface type."; > >> reference > >> "RFC 2863: The Interfaces Group MIB - ifMtu"; > >> } > >>=20 > >> The problem is quite simply that this doesn't say if it's referring to > >> L2 or L3 MTU. I understand that there's some kind of consensus in usa= ge > >> from history, but that's not useful in a specification if it's not > >> written down. > >>=20 > >> Aspects of the different values are: > >> - L2: > >> - it's the actual interface property > >> - might make sense to have a max-mtu(ro) and mtu(rw) to support > >> reducing allocated buffer sizes & such., but I believe that hosts > >> can well handle that automatically > >> - fits the location, we're below L3 in context > >> - slightly confusing for subinterfaces. Let's say I have ethernet > >> with 2 stacked 1Q labels. Is the mtu on the innermost still the > >> same as on the parent ethernet, or is it reduced by 8? > >> =3D> specification needed > >> - better name: mfs (maximum frame size) > >> - L3: > >> - actually useful value > >> - makes more sense with stacked encapsulations since it's clearly > >> defined that it's returning the usable value with all overhead > >> applied > >>=20 > >> Relatedly, I see the need to add a MTU field on the IPv4/IPv6 levels. > >> (Which is going to be fun dealing with for example on Linux because it > >> only supports one value, but well... that's a Linux problem really.) > >=20 > > Here is the definition of ifMtu in RFC 2863: > >=20 > > "The size of the largest packet which can be sent/received > > on the interface, specified in octets. For interfaces that > > are used for transmitting network datagrams, this is the > > size of the largest network datagram that can be sent on the > > interface." > >=20 > > This says its the largest overall frame size except if you run IP over > > it (or some other protocol sending "network datagrams"), then it is > > the largest payload size. What are our options? > >=20 > > 1) drop the interface mtu leaf and instead add an IP config mtu leaf > > (since this is what we understand well) This could be either on the ipv4, or the ipv6, or the general interface level. I'd like to argue for keeping it on the interface level (which I forgot as possibility when writing that rant about IPv4/IPv6 level above - sorry). See below for an adapted 1a) addressing a maximum value. > > 2) like 1) but add a generic read-only leaf to report the maximum > > frame size actually used, (that means to configure it, you need > > interface type specific data model extensions) > >=20 > > 3) like 2) but add another generic leaf to report the maximum frame > > size possible as a read-only leaf (e.g. useful to learn whether an > > ethernetCsmacd interface supports jumbo frames) >=20 > I support #1 because some L2 technologies, such as ATM, don't have the > notion of MTU. The future Ethernet module will define it and all > should be fine. These options aren't really excluding each other; I suppose you're simultaneously arguing for #1 and against #2/#3. So far, we have a consensus on #1 it seems. I agree that 2) is not that useful; it conveys only statistical / debugging information that is of very limited use. I do think 3) has some use, although I don't see an extreme need for it. (i.e. I'd like to see other feedback, but not taking much of a stance on it right now.) However, to make 3) actually useful if added, IMHO it needs be: 3a) adding an "encapsulationOverhead" field that indicates size of the L2 header including all overhead for additional encapsulations like 802.1Q, GRE, or whatever floats your boat. If we want to have some maximum value without going down the link-layer path, there is: 1a) add a maxMtu field on the IP level, explicitly defined as the maximum configurable _IP_ MTU. (This is a separate option again, non-exclusive with 3/3a) Note that for GRE with PMTU discovery, this topic gets another level of complication. If absolutely needed, I'd like to suggest using 0 for all "special" cases, including ATM and tunnels with dynamic MTU. This is also an issue for the MTU value on the IP level, for tunnels at least. An alternative option might be to have a defined meaning for the absence of a MTU value. -David --DwoPkXS38qd3dnhB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlCaedwACgkQCy20tTec6eMKegD+Ky+PZuKW1YiGGcmIAVlH1xQo 7DE1Ah/SjHwPJw3xdY0A/jKtajcpnQrP9MtmO5H5vgzNxHvvq0/DO1YZS31WzoOx =xAMt -----END PGP SIGNATURE----- --DwoPkXS38qd3dnhB-- From lhotka@nic.cz Wed Nov 7 08:40:20 2012 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 0316421F8C63 for ; Wed, 7 Nov 2012 08:40:20 -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=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibZP71ArAaEo for ; Wed, 7 Nov 2012 08:40:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0171121F8C5C for ; Wed, 7 Nov 2012 08:40:18 -0800 (PST) Received: from [IPv6:2001:df8::16:386d:db88:6c5f:8d39] (unknown [IPv6:2001:df8:0:16:386d:db88:6c5f:8d39]) by mail.nic.cz (Postfix) with ESMTPSA id 1351313F652; Wed, 7 Nov 2012 17:40:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1352306416; bh=nDBJmVNLJldTfZ1aTy+Zv6lL0pYsjxf5XgwekGhtZ5w=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Cu5jTG1mh5c2VCoLlzmjswkb9whF1MnauavABndz1pQI2u48/HyDp60+c2re66mGw NEDzd1gJduIB3Yv0ykEPVJDwzbO/MCQkiaW8M4y726p5QbrsfzLlzvbsrNQ0f8XNlX epgA/ndOTqO8qiXOl6sQnRxsGIJ8++tCYJybKprg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121107151020.GP1927048@jupiter.n2.diac24.net> Date: Wed, 7 Nov 2012 11:40:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4AC7DBEA-A903-4048-88C3-3A0449956F6E@nic.cz> References: <20121106230019.GO1927048@jupiter.n2.diac24.net> <20121107122223.GA77037@elstar.local> <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> <20121107151020.GP1927048@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 16:40:20 -0000 On Nov 7, 2012, at 10:10 AM, David Lamparter wrote: > On Wed, Nov 07, 2012 at 09:39:58AM -0500, Ladislav Lhotka wrote: >>=20 >> On Nov 7, 2012, at 7:22 AM, Juergen Schoenwaelder = wrote: >>=20 >>> On Tue, Nov 06, 2012 at 06:00:19PM -0500, David Lamparter wrote: >>>> Hi, >>>>=20 >>>>=20 >>>> I just commented about some weirdness with the MTU field in the >>>> interfaces draft. Here's a quote for reference: >>>> leaf mtu { >>>> type uint32; >>>> description >>>> "The size, in octets, of the largest packet that the >>>> interface can send and receive. This node might not be >>>> valid for all interface types. >>>>=20 >>>> Media-specific modules must specify any restrictions on >>>> the mtu for their interface type."; >>>> reference >>>> "RFC 2863: The Interfaces Group MIB - ifMtu"; >>>> } >>>>=20 >>>> The problem is quite simply that this doesn't say if it's referring = to >>>> L2 or L3 MTU. I understand that there's some kind of consensus in = usage >>>> from history, but that's not useful in a specification if it's not >>>> written down. >>>>=20 >>>> Aspects of the different values are: >>>> - L2: >>>> - it's the actual interface property >>>> - might make sense to have a max-mtu(ro) and mtu(rw) to support >>>> reducing allocated buffer sizes & such., but I believe that hosts >>>> can well handle that automatically >>>> - fits the location, we're below L3 in context >>>> - slightly confusing for subinterfaces. Let's say I have ethernet >>>> with 2 stacked 1Q labels. Is the mtu on the innermost still the >>>> same as on the parent ethernet, or is it reduced by 8? >>>> =3D> specification needed >>>> - better name: mfs (maximum frame size) >>>> - L3: >>>> - actually useful value >>>> - makes more sense with stacked encapsulations since it's clearly >>>> defined that it's returning the usable value with all overhead >>>> applied >>>>=20 >>>> Relatedly, I see the need to add a MTU field on the IPv4/IPv6 = levels. >>>> (Which is going to be fun dealing with for example on Linux because = it >>>> only supports one value, but well... that's a Linux problem = really.) >>>=20 >>> Here is the definition of ifMtu in RFC 2863: >>>=20 >>> "The size of the largest packet which can be sent/received >>> on the interface, specified in octets. For interfaces that >>> are used for transmitting network datagrams, this is the >>> size of the largest network datagram that can be sent on = the >>> interface." >>>=20 >>> This says its the largest overall frame size except if you run IP = over >>> it (or some other protocol sending "network datagrams"), then it is >>> the largest payload size. What are our options? >>>=20 >>> 1) drop the interface mtu leaf and instead add an IP config mtu leaf >>> (since this is what we understand well) >=20 > This could be either on the ipv4, or the ipv6, or the general = interface > level. I'd like to argue for keeping it on the interface level (which = I > forgot as possibility when writing that rant about IPv4/IPv6 level > above - sorry). >=20 > See below for an adapted 1a) addressing a maximum value. >=20 >>> 2) like 1) but add a generic read-only leaf to report the maximum >>> frame size actually used, (that means to configure it, you need >>> interface type specific data model extensions) >>>=20 >>> 3) like 2) but add another generic leaf to report the maximum frame >>> size possible as a read-only leaf (e.g. useful to learn whether an >>> ethernetCsmacd interface supports jumbo frames) >>=20 >> I support #1 because some L2 technologies, such as ATM, don't have = the >> notion of MTU. The future Ethernet module will define it and all >> should be fine. >=20 > These options aren't really excluding each other; I suppose you're > simultaneously arguing for #1 and against #2/#3. So far, we have a > consensus on #1 it seems. What I am saying is that the "mtu" leaf is present even for interfaces = where it doesn't make sense, albeit it is optional. >=20 > I agree that 2) is not that useful; it conveys only statistical / > debugging information that is of very limited use. >=20 > I do think 3) has some use, although I don't see an extreme need for = it. > (i.e. I'd like to see other feedback, but not taking much of a stance = on > it right now.) > However, to make 3) actually useful if added, IMHO it needs be: > 3a) adding an "encapsulationOverhead" field that indicates size of the > L2 header including all overhead for additional encapsulations = like > 802.1Q, GRE, or whatever floats your boat. >=20 > If we want to have some maximum value without going down the = link-layer > path, there is: > 1a) add a maxMtu field on the IP level, explicitly defined as the > maximum configurable _IP_ MTU. > (This is a separate option again, non-exclusive with 3/3a) I think all this belongs to media- or encapsulation-specific modules. Lada >=20 >=20 > Note that for GRE with PMTU discovery, this topic gets another level = of > complication. If absolutely needed, I'd like to suggest using 0 for = all > "special" cases, including ATM and tunnels with dynamic MTU. This is > also an issue for the MTU value on the IP level, for tunnels at least. > An alternative option might be to have a defined meaning for the = absence > of a MTU value. >=20 >=20 > -David >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Wed Nov 7 12:45:45 2012 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 6E30421F8BE7 for ; Wed, 7 Nov 2012 12:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVCEYmi6C56C for ; Wed, 7 Nov 2012 12:45:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC5C21F8BE4 for ; Wed, 7 Nov 2012 12:45:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 8E7AB54057F for ; Wed, 7 Nov 2012 21:45:42 +0100 (CET) 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 jsIQdS90n--X for ; Wed, 7 Nov 2012 21:45:39 +0100 (CET) Received: from localhost (dhcp-113f.meeting.ietf.org [130.129.17.63]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2B38554000E for ; Wed, 7 Nov 2012 21:45:33 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org In-Reply-To: <20121107.073612.358155100.mbj@tail-f.com> References: <20121107.073612.358155100.mbj@tail-f.com> User-Agent: Notmuch/0.14+37~gf227d63 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0) Mail-Followup-To: netmod@ietf.org Date: Wed, 07 Nov 2012 15:45:34 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [netmod] comments on draft-ietf-netmod-routing-cfg-05 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, 07 Nov 2012 20:45:45 -0000 Martin Bjorklund writes: > Hi, > > I have some minor comments: > > > o Section 4.3 > > One or more routing tables MUST be configured for each address > family supported by the server. Each router instance MUST > designate, for every address family that the router instance > supports, exactly one routing table as its main routing table. > > I don't think it is correct to use MUST like this. As an > implementor, what am I supposed to do with these MUST statements? > I would think that what the configuration looks like is the > operator's task. I agree this should be edited and clarified. My idea how this could work is this: A client creates a router instance and configures the name of the main routing table for every address supported by the router instance (this effectivelly turns on the address family for that instance). If any of the named tables doesn't exist, the server creates it. Does it make sense? > > > o Section 4.3 > > o By default, a routing protocol SHOULD be connected to the main > routing table of each address family supported by that routing > protocol. See Section 4.4 for further explanation. > > I think that either s/SHOULD be/MUST be/ or s/SHOULD be/is/ > > This means that if the operator has not configured the system > differently, the implementation must connect it to the main routing > table. This is the normal behaviour, but a special implementation may use another table for the default connection. > > (The same SHOULD occurs in 4.4 and in the YANG module in one place) > > > o Section 4.4.2 > > In order to make the document easier to read, I suggest you simply > refer to the Appendix in this section, instead of inlining > essentially the entire module. If you do this, I suggest you > change your descriptive text into comments that you put in the > Appendix. OK, I will do that, previously this section also sometimes got out of sync with the appendix. > > > o Section 5 > > In all cases, the relevant parts of the core routing data > model are disabled but MUST NOT be deleted from the > configuration by the server. > > On a first read, I couldn't understand what this meant. > > After reading the rest of the section, I think I know what you > mean, but I think you can make this simpler by removing the > paragraph. > > I think the text is confusing b/c it kind of implies that if this > paragraph was not there, an implementation could choose to delete > the relevant parts of the configuration, and that would be just > weird. OK. > > > o Many XPath expressions use the "//" construct for no apparent > reason. It should be a single "/". The reason was to enable the use of such XPath expressions without modification in different contexts where the XML root may be some encapsulating element (typically in the NETCONF namespace). But I agree it is a hack that makes XPath evaluation inefficient. I will remove it. > > > o The example-rip module's filename has a revision date, but there is > no revision statement in the module. I suggest you remove the > revision statement from the filename (since this is just an > example). Agreed. Thanks, Lada > > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From mbj@tail-f.com Wed Nov 7 14:30:32 2012 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 EDEC421F8495 for ; Wed, 7 Nov 2012 14:30:32 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+e9-IxIyhEF for ; Wed, 7 Nov 2012 14:30:32 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFEA21F89B5 for ; Wed, 7 Nov 2012 14:26:45 -0800 (PST) Received: from localhost (dhcp-17d4.meeting.ietf.org [130.129.23.212]) by mail.tail-f.com (Postfix) with ESMTPSA id C07AC1200A6E; Wed, 7 Nov 2012 23:26:42 +0100 (CET) Date: Wed, 07 Nov 2012 17:26:40 -0500 (EST) Message-Id: <20121107.172640.112309976.mbj@tail-f.com> To: equinox@diac24.net From: Martin Bjorklund In-Reply-To: <20121107151020.GP1927048@jupiter.n2.diac24.net> References: <20121107122223.GA77037@elstar.local> <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> <20121107151020.GP1927048@jupiter.n2.diac24.net> 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] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 22:30:33 -0000 Hi, David Lamparter wrote: > On Wed, Nov 07, 2012 at 09:39:58AM -0500, Ladislav Lhotka wrote: > > > > On Nov 7, 2012, at 7:22 AM, Juergen Schoenwaelder > > > This says its the largest overall frame size except if you run IP over > > > it (or some other protocol sending "network datagrams"), then it is > > > the largest payload size. What are our options? > > > > > > 1) drop the interface mtu leaf and instead add an IP config mtu leaf > > > (since this is what we understand well) > > This could be either on the ipv4, or the ipv6, or the general interface > level. I'd like to argue for keeping it on the interface level (which I > forgot as possibility when writing that rant about IPv4/IPv6 level > above - sorry). Are you suggesting that we add a single leaf ip-mtu (defined in the ip module)? And thus not have ipv4/mtu and ipv6/mtu? /martin From equinox@diac24.net Wed Nov 7 14:31:35 2012 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 C939021F841E for ; Wed, 7 Nov 2012 14:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5BwbXyWYupa for ; Wed, 7 Nov 2012 14:31:35 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:81:5c0::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7F21F8511 for ; Wed, 7 Nov 2012 14:30:39 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TWE8p-0001Lf-4q; Wed, 07 Nov 2012 23:30:35 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80) (envelope-from ) id 1TWE8a-00AIuh-5A; Wed, 07 Nov 2012 23:30:22 +0100 Date: Wed, 7 Nov 2012 17:30:20 -0500 From: David Lamparter To: Martin Bjorklund Message-ID: <20121107223019.GB1927048@jupiter.n2.diac24.net> References: <20121107122223.GA77037@elstar.local> <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> <20121107151020.GP1927048@jupiter.n2.diac24.net> <20121107.172640.112309976.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121107.172640.112309976.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 22:31:35 -0000 On Wed, Nov 07, 2012 at 05:26:40PM -0500, Martin Bjorklund wrote: > Hi, > > David Lamparter wrote: > > On Wed, Nov 07, 2012 at 09:39:58AM -0500, Ladislav Lhotka wrote: > > > > > > On Nov 7, 2012, at 7:22 AM, Juergen Schoenwaelder > > > > This says its the largest overall frame size except if you run IP over > > > > it (or some other protocol sending "network datagrams"), then it is > > > > the largest payload size. What are our options? > > > > > > > > 1) drop the interface mtu leaf and instead add an IP config mtu leaf > > > > (since this is what we understand well) > > > > This could be either on the ipv4, or the ipv6, or the general interface > > level. I'd like to argue for keeping it on the interface level (which I > > forgot as possibility when writing that rant about IPv4/IPv6 level > > above - sorry). > > Are you suggesting that we add a single leaf ip-mtu (defined in the ip > module)? And thus not have ipv4/mtu and ipv6/mtu? Yes, out of plain and simple reality acceptance. But this is based on my (limited) knowledge of existing device features. If someone tells me a large number of devices support separate MTUs here, I will instantly change my opinion. -David From j.schoenwaelder@jacobs-university.de Wed Nov 7 15:21:22 2012 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 1E5ED21F8B75 for ; Wed, 7 Nov 2012 15:21:22 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGA4T-xAExxF for ; Wed, 7 Nov 2012 15:21:18 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C01E521F8ACA for ; Wed, 7 Nov 2012 15:21:17 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6F8420BEF; Thu, 8 Nov 2012 00:21:16 +0100 (CET) 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 yTiMKtpjWUwQ; Thu, 8 Nov 2012 00:21:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 466D220BE8; Thu, 8 Nov 2012 00:21:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 12D5922B1019; Thu, 8 Nov 2012 00:21:19 +0100 (CET) Date: Thu, 8 Nov 2012 00:21:19 +0100 From: Juergen Schoenwaelder To: David Lamparter Message-ID: <20121107232118.GB78614@elstar.local> Mail-Followup-To: David Lamparter , Martin Bjorklund , netmod@ietf.org References: <20121107122223.GA77037@elstar.local> <7D02B37F-732C-4E91-8A6D-A96088C39414@nic.cz> <20121107151020.GP1927048@jupiter.n2.diac24.net> <20121107.172640.112309976.mbj@tail-f.com> <20121107223019.GB1927048@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121107223019.GB1927048@jupiter.n2.diac24.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 07 Nov 2012 23:21:22 -0000 On Wed, Nov 07, 2012 at 05:30:20PM -0500, David Lamparter wrote: > > > > Are you suggesting that we add a single leaf ip-mtu (defined in the ip > > module)? And thus not have ipv4/mtu and ipv6/mtu? > > Yes, out of plain and simple reality acceptance. But this is based on > my (limited) knowledge of existing device features. If someone tells me > a large number of devices support separate MTUs here, I will instantly > change my opinion. > Architecturally, I would argue they are not the same thing since they face different constraints. Some widely used router documentation says that they have commands such as ipv6 mtu with a default of 1280 bytes and ip mtu with a minimum of 128 bytes. Some other widely used router documentation hints at this: interface unit 0 family inet mtu family inet6 mtu If a Linux kernel only has one MTU value, then this might be a special case. I am not sure what a *BSD kernel offers in this regard (too lazy to check at the moment). So it seems appropriate to support IP version specific MTUs, but it might be useful to have text somewhere that details what should happen on boxes that only support a single per link MTU value. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From phil@juniper.net Wed Nov 7 21:05:56 2012 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 659FD21F8A72 for ; Wed, 7 Nov 2012 21:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbuUlqnHXcpm for ; Wed, 7 Nov 2012 21:05:55 -0800 (PST) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9B21F8A5D for ; Wed, 7 Nov 2012 21:05:15 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKUJs9ihJLeN+kL6w/3SSThBD/Y/RkClJq@postini.com; Wed, 07 Nov 2012 21:05:55 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 7 Nov 2012 21:04:46 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id qA854i355996; Wed, 7 Nov 2012 21:04:45 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id qA854gYa014281; Thu, 8 Nov 2012 00:04:43 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201211080504.qA854gYa014281@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20121107232118.GB78614@elstar.local> Date: Thu, 8 Nov 2012 00:04:42 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 08 Nov 2012 05:05:56 -0000 Juergen Schoenwaelder writes: >Architecturally, I would argue they are not the same thing since they >face different constraints. Some widely used router documentation says >that they have commands such as FWIW, googling yields some interesting stories about differing views on MTU, like: http://www.net-gyver.com/?p=1086 http://blog.ioshints.info/2011/07/all-mtus-are-not-same.html http://books.google.com/books?id=PWVJUuLvw3oC&pg=PA147&lpg=PA147&dq=mtu+junos+ios&source=bl&ots=dNftFM8zQV&sig=p_tHHgHu4w93xXr2JAatpTVHGhQ&hl=en&sa=X&ei=CTubUP-jE-iviQLou4CABA&ved=0CDQQ6AEwAQ#v=onepage&q=mtu%20junos%20ios&f=false http://www.gossamer-threads.com/lists/nsp/juniper/34633?do=post_view_threaded In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU as L3. The downside of using the L2 number is that the user needs to know the L2 overhead. The downside of using the L3 number is that the user needs to know the L2 overhead. ;^) Thanks, Phil From mbj@tail-f.com Thu Nov 8 06:02:27 2012 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 6CD8B21F8A60 for ; Thu, 8 Nov 2012 06:02:27 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR8K3oMPhbuz for ; Thu, 8 Nov 2012 06:02:27 -0800 (PST) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8228A21F887F for ; Thu, 8 Nov 2012 06:02:26 -0800 (PST) Received: from localhost (dhcp-469c.meeting.ietf.org [130.129.70.156]) by mail.tail-f.com (Postfix) with ESMTPSA id 09C0512008BF; Thu, 8 Nov 2012 15:02:23 +0100 (CET) Date: Thu, 08 Nov 2012 09:02:22 -0500 (EST) Message-Id: <20121108.090222.440897434.mbj@tail-f.com> To: phil@juniper.net From: Martin Bjorklund In-Reply-To: <201211080504.qA854gYa014281@idle.juniper.net> References: <20121107232118.GB78614@elstar.local> <201211080504.qA854gYa014281@idle.juniper.net> 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] draft-ietf-netmod-interfaces-cfg MTU value 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, 08 Nov 2012 14:02:27 -0000 Phil Shafer wrote: > In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU > as L3. This would be the mtu on the interface. All these implementations treat the ip mtu the same way (which makes sense...). It does seem weird that the mtu defined on the l2 level really is the l3 mtu. But RFC 2460 has this definition: packet - an IPv6 header plus payload. link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link. ... which adds to the confusion. Current consensus seems to be that we should not specify the mtu on the interface layer at all. We leave that up to the media-specific modules. So that they all can do it differently ;) /martin From lhotka@nic.cz Thu Nov 8 08:08:29 2012 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 A3B4B21F851C for ; Thu, 8 Nov 2012 08:08:29 -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=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLkrUkMcbo6e for ; Thu, 8 Nov 2012 08:08:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AF41D21F8443 for ; Thu, 8 Nov 2012 08:08:23 -0800 (PST) Received: from [IPv6:2001:df8::16:c4eb:e0a4:d405:1d30] (unknown [IPv6:2001:df8:0:16:c4eb:e0a4:d405:1d30]) by mail.nic.cz (Postfix) with ESMTPSA id 0CFD913F63F; Thu, 8 Nov 2012 17:08:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1352390902; bh=5pJKL/4xCVMubGIUUlwGNj15BRlgfJ5n1SWE1ZrJ5Sg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=yDVUQ0gGtCyGgasyA/Ku905dZpapMsfaY2xXkyH13MrHEzgy4/40hKGkuM7nIRGbG dryh8aovQmQ+PiDZw6bCK4z6ECTUDhdDOXSJuMQcg8apyjN2BTYqCEM1/L1PqdayOC eVsxoJrccVQUXKyObPmabftrtObm3yVKzumUC5uc= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ladislav Lhotka In-Reply-To: <20121108.090222.440897434.mbj@tail-f.com> Date: Thu, 8 Nov 2012 11:08:25 -0500 Content-Transfer-Encoding: 7bit Message-Id: <4A4691C9-C68C-47EE-BD1E-CBD3034493A6@nic.cz> References: <20121107232118.GB78614@elstar.local> <201211080504.qA854gYa014281@idle.juniper.net> <20121108.090222.440897434.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1499) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 08 Nov 2012 16:08:29 -0000 On Nov 8, 2012, at 9:02 AM, Martin Bjorklund wrote: > Phil Shafer wrote: >> In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU >> as L3. > > This would be the mtu on the interface. All these implementations > treat the ip mtu the same way (which makes sense...). > > It does seem weird that the mtu defined on the l2 level really is the > l3 mtu. But RFC 2460 has this definition: > > packet - an IPv6 header plus payload. > > link MTU - the maximum transmission unit, i.e., maximum packet > size in octets, that can be conveyed over a link. > > ... which adds to the confusion. > > > Current consensus seems to be that we should not specify the mtu on > the interface layer at all. We leave that up to the media-specific > modules. So that they all can do it differently ;) +1. It also allows media-specific modules to specify their default MTU value. Lada > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From ietfc@btconnect.com Thu Nov 8 10:20:15 2012 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 E653421F86A3 for ; Thu, 8 Nov 2012 10:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51ZfUk0teDeY for ; Thu, 8 Nov 2012 10:20:13 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id CABCC21F8609 for ; Thu, 8 Nov 2012 10:20:10 -0800 (PST) Received: from mail23-am1-R.bigfish.com (10.3.201.236) by AM1EHSOBE009.bigfish.com (10.3.204.29) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 18:20:09 +0000 Received: from mail23-am1 (localhost [127.0.0.1]) by mail23-am1-R.bigfish.com (Postfix) with ESMTP id 7A4753202F4; Thu, 8 Nov 2012 18:20:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(z1725nz9371I542M1432I4015Izz1de0h1202h1d1ah1d2ahzz8275ch1033IL17326ah8275eh8275bh8275dha1495iz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h304l1155h) Received: from mail23-am1 (localhost.localdomain [127.0.0.1]) by mail23-am1 (MessageSwitch) id 1352398807125298_1492; Thu, 8 Nov 2012 18:20:07 +0000 (UTC) Received: from AM1EHSMHS011.bigfish.com (unknown [10.3.201.238]) by mail23-am1.bigfish.com (Postfix) with ESMTP id 124543E007D; Thu, 8 Nov 2012 18:20:07 +0000 (UTC) Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by AM1EHSMHS011.bigfish.com (10.3.207.111) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 18:20:05 +0000 Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by pod51017.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.233.3; Thu, 8 Nov 2012 18:20:04 +0000 Message-ID: <013c01cdbddd$90656a80$4001a8c0@gateway.2wire.net> From: t.petch To: Juergen Schoenwaelder , Phil Shafer References: <201211080504.qA854gYa014281@idle.juniper.net> Date: Thu, 8 Nov 2012 18:19:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.21] X-FOPE-CRA-Verdict: 157.56.249.213$juniper.net%12218%4%btconnect.com%False%False%0$ X-OriginatorOrg: btconnect.com Cc: netmod@ietf.org Subject: Re: [netmod] draft-ietf-netmod-interfaces-cfg MTU value 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, 08 Nov 2012 18:20:15 -0000 ----- Original Message ----- From: "Phil Shafer" To: "Juergen Schoenwaelder" Cc: Sent: Thursday, November 08, 2012 5:04 AM > Juergen Schoenwaelder writes: > >Architecturally, I would argue they are not the same thing since they > >face different constraints. Some widely used router documentation says > >that they have commands such as > > FWIW, googling yields some interesting stories about differing > views on MTU, like: > > http://www.net-gyver.com/?p=1086 > http://blog.ioshints.info/2011/07/all-mtus-are-not-same.html > http://books.google.com/books?id=PWVJUuLvw3oC&pg=PA147&lpg=PA147&dq=mtu+ junos+ios&source=bl&ots=dNftFM8zQV&sig=p_tHHgHu4w93xXr2JAatpTVHGhQ&hl=en &sa=X&ei=CTubUP-jE-iviQLou4CABA&ved=0CDQQ6AEwAQ#v=onepage&q=mtu%20junos% 20ios&f=false > http://www.gossamer-threads.com/lists/nsp/juniper/34633?do=post_view_thr eaded > > In summary, JUNOS and IOS-XR view MTU as L2; IOS-classic views MTU > as L3. And we are the IETF and we speak with a single voice, namely " MTU: Maximum Transmission Unit, the size in bytes of the largest IP packet, including the IP header and payload, that can be transmitted on a link or path. Note that this could more properly be called the IP MTU, to be consistent with how other standards organizations use the acronym MTU. Link MTU: The Maximum Transmission Unit, i.e., maximum IP packet size in bytes, that can be conveyed in one piece over a link. Be aware that this definition is different from the definition used by other standards organizations. For IETF documents, link MTU is uniformly defined as the IP MTU over the link. This includes the IP header, but excludes link layer headers and other framing that is not part of IP or the IP payload. Be aware that other standards organizations generally define link MTU to include the link layer headers." Doubtless Google will find you the RFC that this comes from:-) I think you would be really wanting to create confusion if you depart from the accepted, over several decades, IETF use of the terms. Tom Petch > > The downside of using the L2 number is that the user needs to know > the L2 overhead. The downside of using the L3 number is that the > user needs to know the L2 overhead. ;^) > > Thanks, > Phil > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > From j.schoenwaelder@jacobs-university.de Thu Nov 8 15:40:55 2012 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 5004D21F8AFB for ; Thu, 8 Nov 2012 15:40:55 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDxQRaUozyi4 for ; Thu, 8 Nov 2012 15:40:54 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8C03521F8A8E for ; Thu, 8 Nov 2012 15:40:54 -0800 (PST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DAE620C14; Fri, 9 Nov 2012 00:40:53 +0100 (CET) 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 Qrst-sm7aiz5; Fri, 9 Nov 2012 00:40:53 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 12A3320BF9; Fri, 9 Nov 2012 00:40:53 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EAEB522B9646; Fri, 9 Nov 2012 00:40:54 +0100 (CET) Date: Fri, 9 Nov 2012 00:40:54 +0100 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20121108234053.GA81018@elstar.local> Mail-Followup-To: netmod@ietf.org, Benoit Claise 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] NETMOD @ IETF 85 summary 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: Thu, 08 Nov 2012 23:40:55 -0000 The NETMOD working group has met for 1.5 hours on Tuesday, November 6th, during the 85th IETF meeting. The meeting was attended by ~45 people. * The naming issue of the interfaces data model got resolved. There will be updated versions of draft-ietf-netmod-interfaces-cfg and draft-ietf-netmod-ip-cfg shortly after the meeting, ready for a second WG last call. * The routing data model has a few pending edits. Once a new revision is available, this document will be sent to the second WG last call. * The system data model needs some input from RADIUS experts. Once a new revision is available, the document will go to 1st WG last call. * A substantial review of some parts of the document has been provided just before the WG meeting. The editors will update the document to address the comments. This document needs further review by people familiar with SNMP implementations before it can be last called. * A proposal for a set of ACL data models was presented. While this work seems substantial and timely, the WG has to first finish the chartered work before it can consider to take on new work. The authors were encouraged to further refine the data models to make sure the models cover a number of popular firewall / packet filter implementations. The remaining agenda items had to be skipped because the WG did run out of time. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From internet-drafts@ietf.org Thu Nov 15 04:45:42 2012 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 1AE2D21F84E4; Thu, 15 Nov 2012 04:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgpCnfhd3FJ4; Thu, 15 Nov 2012 04:45:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8572D21F85AF; Thu, 15 Nov 2012 04:45:41 -0800 (PST) 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.36 Message-ID: <20121115124541.11252.98272.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 04:45:41 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-interfaces-cfg-08.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, 15 Nov 2012 12:45:42 -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 : A YANG Data Model for Interface Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-interfaces-cfg-08.txt Pages : 38 Date : 2012-11-15 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-interfaces-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-interfaces-cfg-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Nov 15 04:46:28 2012 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 3165821F869A; Thu, 15 Nov 2012 04:46:28 -0800 (PST) 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.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxR7mYNa3gBz; Thu, 15 Nov 2012 04:46:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744C221F888F; Thu, 15 Nov 2012 04:46:27 -0800 (PST) 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.36 Message-ID: <20121115124627.11258.13224.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 04:46:27 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-ip-cfg-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: Thu, 15 Nov 2012 12:46:28 -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 : A YANG Data Model for IP Management Author(s) : Martin Bjorklund Filename : draft-ietf-netmod-ip-cfg-07.txt Pages : 22 Date : 2012-11-15 Abstract: This document defines a YANG data model for management of IP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-ip-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-ip-cfg-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Nov 15 05:03:49 2012 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 76F9921F88EA; Thu, 15 Nov 2012 05:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18IN3YOjBaOW; Thu, 15 Nov 2012 05:03:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E9421F88ED; Thu, 15 Nov 2012 05:03:49 -0800 (PST) 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.36 Message-ID: <20121115130349.17512.66092.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 05:03:49 -0800 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-06.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, 15 Nov 2012 13:03:49 -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 : A YANG Data Model for Routing Management Author(s) : Ladislav Lhotka Filename : draft-ietf-netmod-routing-cfg-06.txt Pages : 68 Date : 2012-11-15 Abstract: This document contains a specification of three YANG modules. Together they form the core routing data model which serves as a framework for configuring and managing a routing subsystem. It is expected that these modules will be augmented by additional YANG modules defining data models for individual routing protocols and other related functions. The core routing data model provides common building blocks for such extensions - router instances, routes, routing tables, routing protocols and route filters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From muthu@cisco.com Thu Nov 15 09:36:40 2012 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 324EB21F88CC for ; Thu, 15 Nov 2012 09:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBnq3dITcppF for ; Thu, 15 Nov 2012 09:36:39 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B66E421F8957 for ; Thu, 15 Nov 2012 09:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23859; q=dns/txt; s=iport; t=1353000999; x=1354210599; h=from:to:subject:date:message-id:mime-version; bh=D8hUE1IaVDwl6MgWbH3tYlAum21DER5dGVMemVd0fGU=; b=IyJ3ErJ33MUprMGdDtczMEF4WPEmZG/Mx5i6lYQ9qdwBmpufN6fyr9TE VBeDf3hmOHrP4/sLQMdSSezPVckKGL2zaW7M8NKo77uGk7Eyw+UNge319 l03zjl5vXr+rx3zJ0ds3bHVfWnn+WCNn9tanqrHfLLqzoHLwTFPsm4IWW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8JAJwnpVCtJXG+/2dsb2JhbABEgkm2cwGIf4EBB4IgAQQSAXgBKhYBPycEGxqHawubQoEroA2RfGEDlxiNPIFrgm+CGQ X-IronPort-AV: E=McAfee;i="5400,1158,6897"; a="139858940" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 15 Nov 2012 17:36:38 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAFHac5M015544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 15 Nov 2012 17:36:38 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.63]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 11:36:38 -0600 From: "Muthumayan Madhayyan (muthu)" To: "netmod@ietf.org" Thread-Topic: YANG - question on module revision Thread-Index: AQHNw1fD9LDwI6sPjkquoPx1C9xayA== Date: Thu, 15 Nov 2012 17:36:37 +0000 Message-ID: <5A949C32AF740C4798AEECF2568F0D841972B4@xmb-rcd-x13.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.21.146.181] Content-Type: multipart/alternative; boundary="_000_5A949C32AF740C4798AEECF2568F0D841972B4xmbrcdx13ciscocom_" MIME-Version: 1.0 Subject: [netmod] YANG - question on module revision 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, 15 Nov 2012 17:36:40 -0000 --_000_5A949C32AF740C4798AEECF2568F0D841972B4xmbrcdx13ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a question regarding this revision rule in RFC 6020 (Section 10. Upd= ate a Module): New data definition statements may be added if they do not add mandatory nodes (Section 3.1) to existing nodes or at the top level in a module or submodule, or if they are conditionally dependent on a new feature (i.e., have an "if-feature" statement that refers to a new feature). Lets say we have a YANG module in revision1 that looks like this: Container A { Leaf L1 { } Leaf L2 { } } In revision2 of this module, we decide to add a new data container B inside= A and move those leaves inside that: Container A { Container B { Leaf L1 { } Leaf L2 { } } } Now, this change would obviously break revision1 implementation of the modu= le. However, it does not violate the revision rule stated in Section 10 of RFC = 6020. So are there any do's and don'ts on how one would go about introducing anot= her level of hierarchy ? One way is to retain both leaf nodes at both levels in the hierarchy.. Some= thing like this: Container A { Leaf L1 { } Leaf L2 { } Container B { Leaf L1 { } Leaf L2 { } } } Thanks, - muthu --_000_5A949C32AF740C4798AEECF2568F0D841972B4xmbrcdx13ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <0A6B8815C47E7F41812B701223224919@cisco.com> Content-Transfer-Encoding: quoted-printable 

I have a question regarding this revision r=
ule in RFC 6020 (Section 10. Update a Module):


      New data definition statements may be=
 added if they do not add
      mandatory nodes (Section 3.1) to existing nodes or at the top
      level in a module or submodule, or if they are conditionally
      dependent on a new feature (i.e., have an "if-feature" stat=
ement
      that refers to a new feature).


Lets say we have a YANG module in revision1=
 that looks like this:

Container A {
    Leaf L1 { }
    Leaf L2 { }
}

In revision2 of this module, we decide to a=
dd a new data container B inside A and move those leaves inside that:

Container A {
    Container B {
         Leaf L1 { }
         Leaf L2 { }
    }
}


Now, this change would obviously break=
 revision1 implementation of the module.

However, it does not violate the revision r=
ule stated in Section 10 of RFC 6020. 

So are there any do's and don'ts on how one=
 would go about introducing another level of hierarchy ?

One way is to retain both leaf nodes at bot=
h levels in the hierarchy.. Something like this:

Container A {
    Leaf =
L1 { }
    Leaf L2 { }    
=


    Container B {
         Leaf L1 {=
 }
         Leaf L2 { }
    }
}









Thanks,


- muthu
--_000_5A949C32AF740C4798AEECF2568F0D841972B4xmbrcdx13ciscocom_-- From andy@yumaworks.com Thu Nov 15 09:52:33 2012 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 2A9D921F86A2 for ; Thu, 15 Nov 2012 09:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rcdo76gvD8xB for ; Thu, 15 Nov 2012 09:52:31 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93421F85FC for ; Thu, 15 Nov 2012 09:52:30 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so2107193vbb.31 for ; Thu, 15 Nov 2012 09:52:30 -0800 (PST) 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=fBeUVFMz64X7E5queloTBaI2tszoC98uJ2bwxx84WHs=; b=ZwI+Y4f1HzA1VC7b7rkdwkqElPa8eY4QAz0AG+OnGtN/5HsprDmBrBxEFI3NkGByaq WcvuUiMw1ji6mAvguh6ksHxxtOv99WT2lAKu7gBb19UYETcRibW5uv/EDy7xYREE69/K eOMkAET2cyc0+Y6iNpc2Zqo/CtfiUgHzskfp+4EZ71zh/ZoSXEiq5ClDdK1GcaSIp6+j vpGX39AnvZ7/q1GoCrq9XdrMvSXWO3Bgl8Ynxs77QMLg4nOTaJbiqw3SEXMUOMTS+vlk AbQF8aO0glVVndFHfUyFaXUkcfTrUT6/Rp3hKiao4Y29bl1/E7t6HTmhioDdgrNlhIn9 yI1w== MIME-Version: 1.0 Received: by 10.58.239.138 with SMTP id vs10mr147535vec.16.1353001949929; Thu, 15 Nov 2012 09:52:29 -0800 (PST) Received: by 10.58.201.7 with HTTP; Thu, 15 Nov 2012 09:52:29 -0800 (PST) In-Reply-To: <5A949C32AF740C4798AEECF2568F0D841972B4@xmb-rcd-x13.cisco.com> References: <5A949C32AF740C4798AEECF2568F0D841972B4@xmb-rcd-x13.cisco.com> Date: Thu, 15 Nov 2012 09:52:29 -0800 Message-ID: From: Andy Bierman To: "Muthumayan Madhayyan (muthu)" Content-Type: multipart/alternative; boundary=047d7bdc96949b221204ce8c5009 X-Gm-Message-State: ALoCoQmrlYOp3cGuOquUPfwTZhmxFtNCyQg2PXzKujtTLsets4dGcuO3CoKZ5OlKDtzBBA0ZuaUu Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG - question on module revision 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, 15 Nov 2012 17:52:33 -0000 --047d7bdc96949b221204ce8c5009 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 15, 2012 at 9:36 AM, Muthumayan Madhayyan (muthu) < muthu@cisco.com> wrote: > > I have a question regarding this revision rule in RFC 6020 (Section 10. Update a Module): > > > > New data definition statements may be added if they do not add > mandatory nodes (Section 3.1 ) to existing nodes or at the top > level in a module or submodule, or if they are conditionally > dependent on a new feature (i.e., have an "if-feature" statement > that refers to a new feature). > > > > Lets say we have a YANG module in revision1 that looks like this: > > > Container A { > > Leaf L1 { } > > Leaf L2 { } > > } > > > In revision2 of this module, we decide to add a new data container B inside A and move those leaves inside that: > > > Container A { > > Container B { > > Leaf L1 { } > > Leaf L2 { } > > } > > } > > > > Now, this change would obviously break revision1 implementation of the module. > > > However, it does not violate the revision rule stated in Section 10 of RFC 6020. > > > I think this paragraph apples: Otherwise, if the semantics of any previous definition are changed (i.e., if a non-editorial change is made to any definition other than those specifically allowed above), then this MUST be achieved by a new definition with a new identifier. You are deleting leafs. That is a semantic change. > So are there any do's and don'ts on how one would go about introducing another level of hierarchy ? > > > One way is to retain both leaf nodes at both levels in the hierarchy.. Something like this: > > > Container A { > > Leaf L1 { } > > Leaf L2 { } > > > Container B { > > Leaf L1 { } > > Leaf L2 { } > > } > > } > > > yes -- mark the old leafs 'status deprecated;' There is no specific amount of time they need to be present in the implementation before you can mark them obsolete and actually delete them from your server. I suggest a year at least. Not sure if there are interactions between the old and new nodes. This could get messy in some corner-cases. > > Thanks, > > - muthu > > > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --047d7bdc96949b221204ce8c5009 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Nov 15, 2012 at 9:36 AM, Muthuma= yan Madhayyan (muthu) <muthu@cisco.com> wrote:

I have a question regarding this revision rule in RFC 6020 (Section 10. Upd=
ate a Module):


      New data definition statements may be added if they do not add
      mandatory nodes (Section 3.1) to existing nodes or at the top
      level in a module or submodule, or if they are conditionally
      dependent on a new feature (i.e., have an "if-feature" stat=
ement
      that refers to a new feature).


Lets say we have a YANG module in revision1 that looks like this:

Container A {
    Leaf L1 { }
    Leaf L2 { }
}

In revision2 of this module, we decide to add a new data container B inside=
 A and move those leaves inside that:

Container A {
    Container B {
         Leaf L1 { }
         Leaf L2 { }
    }
}


Now, this change would=C2=A0obviously break revision1 implementation of the=
 module.

However, it does not violate the revision rule stated in Section 10 of RFC =
6020.


I think this paragra= ph apples:

   Otherwise, if the semantics of any previous definition are =
changed
   (i.e., if a non-editorial change is made to any definition other than
   those specifically allowed above), then this MUST be achieved by a
   new definition with a new identifier.

You are deleting leafs. =C2=A0That is a semantic = change.

=C2=A0


So are there any do's and don'ts on how one would go about introduc=
ing another level of hierarchy ?





One way is to retain both leaf nodes at both levels in the hierarchy.. Some=
thing like this:





Container A {
    Leaf L1 { }
    Leaf L2 { }   =C2=A0

    Container B {
         Leaf L1 { }
         Leaf L2 { }
    }
}


=


yes -- mark the old leafs 'status deprecated;'=
=C2=A0
There is no specific amount of time they need to be
<=
div>
present in the implementation before you can mark them obsolete
a=
nd actually delete them from your server. =C2=A0I suggest a year at least.<=
/div>

Not sure if there are interactions between the old=
 and new nodes.


This could get messy in some corner-cases.











Thanks,


- muthu












Andy
=C2=A0
________________________________________=
_______


netmod mailing list

netmod@ietf.org

=
https://www.ietf.org/mailman/listinfo/netmod





--047d7bdc96949b221204ce8c5009--

From j.schoenwaelder@jacobs-university.de  Fri Nov 16 00:40:38 2012
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 941DF21F86DE for ; Fri, 16 Nov 2012 00:40:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.181
X-Spam-Level: 
X-Spam-Status: No, score=-103.181 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7N7zvoH1DHB for ; Fri, 16 Nov 2012 00:40:26 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id CC3C721F84DD for ; Fri, 16 Nov 2012 00:40:24 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94ADC20C87; Fri, 16 Nov 2012 09:40:22 +0100 (CET)
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 Gmn6lknoKxyr; Fri, 16 Nov 2012 09:40:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3947520C84; Fri, 16 Nov 2012 09:40:22 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AD91422D4463; Fri, 16 Nov 2012 09:40:25 +0100 (CET)
Date: Fri, 16 Nov 2012 09:40:24 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20121116084024.GA2302@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] 2nd wg last call on interfaces / ip / routing data models
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, 16 Nov 2012 08:40:38 -0000

Hi,

this is the start of the 2nd WG last call on the following set of
documents:

  http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
  http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
  http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06

A related document, the YANG version of the interface type and
AFN/SAFI IANA registries, had no issues raised during 1st WG last call
and has not changed:

  http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04

Please review the documents and raise any issues you might discover by
opening a thread on the mailing list. Editorial fixes can be sent
directly to the document editors.

Please indicate your support by *Friday, November 30, 2012*. We are
not only interested in receiving defect reports, we are equally
interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Fri Nov 16 06:46:26 2012
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 E935921F8688 for ; Fri, 16 Nov 2012 06:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.644
X-Spam-Level: 
X-Spam-Status: No, score=-5.644 tagged_above=-999 required=5 tests=[AWL=0.955,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pS2OFc1VkBr for ; Fri, 16 Nov 2012 06:46:25 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0271121F8967 for ; Fri, 16 Nov 2012 06:46:24 -0800 (PST)
Received: from mail66-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Fri, 16 Nov 2012 14:46:22 +0000
Received: from mail66-va3 (localhost [127.0.0.1])	by mail66-va3-R.bigfish.com (Postfix) with ESMTP id 05A8444030D; Fri, 16 Nov 2012 14:46:22 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -23
X-BigFish: PS-23(zz9371I542M1418Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h)
Received: from mail66-va3 (localhost.localdomain [127.0.0.1]) by mail66-va3 (MessageSwitch) id 1353077179208658_25800; Fri, 16 Nov 2012 14:46:19 +0000 (UTC)
Received: from VA3EHSMHS010.bigfish.com (unknown [10.7.14.251])	by mail66-va3.bigfish.com (Postfix) with ESMTP id 2FDA9400E1; Fri, 16 Nov 2012 14:46:19 +0000 (UTC)
Received: from DBXPRD0710HT005.eurprd07.prod.outlook.com (157.56.253.197) by VA3EHSMHS010.bigfish.com (10.7.99.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 16 Nov 2012 14:46:19 +0000
Received: from CH1PRD0410HT002.namprd04.prod.outlook.com (157.56.244.181) by pod51017.outlook.com (10.255.79.168) with Microsoft SMTP Server (TLS) id 14.16.239.5; Fri, 16 Nov 2012 14:46:16 +0000
Message-ID: <00fe01cdc408$ff636960$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Lange, Jeffrey K (GE Energy)" , 
References: 
Date: Fri, 16 Nov 2012 14:45:09 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.244.181]
X-OriginatorOrg: btconnect.com
Subject: Re: [netmod] Attempts and timeouts in ietf-system
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, 16 Nov 2012 14:46:26 -0000

----- Original Message -----
From: "Lange, Jeffrey K (GE Energy)" 
To: 
Sent: Wednesday, November 07, 2012 1:52 PM
Subject: [netmod] Attempts and timeouts in ietf-system


The ietf-system model defines timeout and attempts leafs for both DNS
and RADIUS servers as uint8 with no range.  This results in some
ambiguity as to what the value of 0 means?  Does a server with attempts
set to 0 mean it's in essence disabled?  Does a timeout of 0 imply it
should wait forever?

I think that all of these fields should have a  range from 1..n, it just
doesn't make sense to allow a zero value for these leafs.


In many contexts in many systems, a timeout value of zero means no
timeout, so while that is worth making explicit, I would expect many to
take it for granted.

As to whether zero attempts means none or infinite, I would suggest that
the latter is less likely, but I have seen it.  Again, worth making
explicit.

Restricting ranges on the grounds that some do not make sense is
sensible when the rules for update make it simple to add new values.
When the rules for update prohibit this, or make in uneconomic to
contemplate, as happened recently with a management protocol, then it is
better to allow a wider range with a suitable textual discouragement,
e.g. ('RESERVED FOR FUTURE USE').

Tom Petch

Jeff Lange
Lead Software Engineer
GE Energy Services
Digital Energy





------------------------------------------------------------------------
--------


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



From j.schoenwaelder@jacobs-university.de  Mon Nov 19 07:16:44 2012
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 8456421F865D for ; Mon, 19 Nov 2012 07:16:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.192
X-Spam-Level: 
X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyTuZh3ei9uc for ; Mon, 19 Nov 2012 07:16:43 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id BDE0E21F85AF for ; Mon, 19 Nov 2012 07:16:43 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A0CF220CD2; Mon, 19 Nov 2012 16:16:41 +0100 (CET)
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 bnDPrtAK8ZJW; Mon, 19 Nov 2012 16:16:41 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3CFDA20CE5; Mon, 19 Nov 2012 16:16:40 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id EFBAB22E036C; Mon, 19 Nov 2012 16:16:44 +0100 (CET)
Date: Mon, 19 Nov 2012 16:16:44 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20121119151643.GA8992@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 minutes of the netmod meeting in atlanta
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, 19 Nov 2012 15:16:44 -0000

Hi,

I have posted minutes of the netmod meeting in atlanta.

http://www.ietf.org/proceedings/85/minutes/minutes-85-netmod

Please let me know if something needs to fixed. Thanks to Lisandro
Granville for taking notes. WG editors, please check whether any
actions need to be taken to move things forward. In particular,

 - the system data model editors may want to consult RADIUS experts
   regarding the RADIUS client authentication configuration
   information needed and

 - the snmp configuration data model editors may want to consult with
   Wes Hardacker and Robert Story on any differences between SNMP MIB
   modules and the YANG data model and what is lacking with regard to
   other transports.

Updates to the interfaces, IP and routing data models have already
been posted and a second WG last call has been issued (please review).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From andy@yumaworks.com  Mon Nov 19 07:30:02 2012
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 8D65A21F868F for ; Mon, 19 Nov 2012 07:30:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.416,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGbhyfLHSi4k for ; Mon, 19 Nov 2012 07:30:01 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 893D521F8672 for ; Mon, 19 Nov 2012 07:30:01 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id fc26so5679942vbb.31 for ; Mon, 19 Nov 2012 07:30:01 -0800 (PST)
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=j7a6DiGNI90YKGzIm+ORi9Mv4qPVbXSqzc5qlULKNz0=; b=oVLyHZVHRKHtPrM266+mW0GgYBTiXDzwWPl6h9Kw7zer4yyPejBaOdZBykihfVU2H5 cIBNYrLj9YfrXlfALi+4nuOGVQ1Odo2H2nd7jt/rXFRNOdIAElhm7sKeZnlx/Uub3nyK PZbMKu5Ej56kaeD2cNuZ+CoIpANx2xMw/xO4BpLHKR/rRMHVRTuNu6jHfRdfqReoGY/o xQ0eSYl0GBnIFKlKDKXaFPZsytdZtZ9HM4DL5gRjlsxWPRihESXA0kLzX59DHcsv7tUv d1KrnKQba3BaGRYqRvaUtyAlBQM23Rvx1FREqVXrIRWHIFUvNDBHRfXZOgqO0SIwh80k HJlg==
MIME-Version: 1.0
Received: by 10.52.92.13 with SMTP id ci13mr4353296vdb.55.1353339000781; Mon, 19 Nov 2012 07:30:00 -0800 (PST)
Received: by 10.58.201.7 with HTTP; Mon, 19 Nov 2012 07:30:00 -0800 (PST)
In-Reply-To: <20121119151643.GA8992@elstar.local>
References: <20121119151643.GA8992@elstar.local>
Date: Mon, 19 Nov 2012 07:30:00 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , netmod@ietf.org
Content-Type: multipart/alternative; boundary=bcaec501670166f9c404cedacaa8
X-Gm-Message-State: ALoCoQnasGk9IxJv8Z4fNfOGSlJUu7FA0iJqdz1IDR3h3GFw0uZtFMtAGaxYrmbSGWJd2xDduE+p
Subject: Re: [netmod] draft minutes of the netmod meeting in atlanta
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, 19 Nov 2012 15:30:02 -0000

--bcaec501670166f9c404cedacaa8
Content-Type: text/plain; charset=UTF-8

On Mon, Nov 19, 2012 at 7:16 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Hi,
>
> I have posted minutes of the netmod meeting in atlanta.
>
> http://www.ietf.org/proceedings/85/minutes/minutes-85-netmod
>
> Please let me know if something needs to fixed. Thanks to Lisandro
> Granville for taking notes. WG editors, please check whether any
> actions need to be taken to move things forward. In particular,
>
>  - the system data model editors may want to consult RADIUS experts
>    regarding the RADIUS client authentication configuration
>    information needed and
>
>
I already heard from Alan DeKok who suggested that there
is an IANA registry for EAP types.

I assume he means the EAP Method Types:
http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3


Andy

 - the snmp configuration data model editors may want to consult with
>    Wes Hardacker and Robert Story on any differences between SNMP MIB
>    modules and the YANG data model and what is lacking with regard to
>    other transports.
>
> Updates to the interfaces, IP and routing data models have already
> been posted and a second WG last call has been issued (please review).
>
> /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
>

--bcaec501670166f9c404cedacaa8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Mon, Nov 19, 2012 at 7:16 AM, Juergen=
 Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:



Hi,



I have posted minutes of the netmod meeting in atlanta.



http://www.ietf.org/proceedings/85/minutes/minutes-85-netmo=
d



Please let me know if something needs to fixed. Thanks to Lisandro

Granville for taking notes. WG editors, please check whether any

actions need to be taken to move things forward. In particular,



=C2=A0- the system data model editors may want to consult RADIUS experts
=C2=A0 =C2=A0regarding the RADIUS client authentication configuration

=C2=A0 =C2=A0information needed and



I already heard from Alan DeKok who su=
ggested that there
is an IANA registry for EAP types.
<=
br>
I assume he means the EAP Method Types:




Andy


=C2=A0- the snmp configuration data model editors may want to consult with<=
br>
=C2=A0 =C2=A0Wes Hardacker and Robert Story on any differences between SNMP=
 MIB

=C2=A0 =C2=A0modules and the YANG data model and what is lacking with regar=
d to

=C2=A0 =C2=A0other transports.



Updates to the interfaces, IP and routing data models have already

been posted and a second WG last call has been issued (please review).



/js



--

Juergen Schoenwaelder =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jacobs University =
Bremen gGmbH

Phone: +49 421 200 3587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Campus Ring 1, 28759 Br=
emen, Germany

Fax: =C2=A0 +49 421 200 3103 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <http://www.jacobs-universi=
ty.de/>

_______________________________________________

netmod mailing list

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





--bcaec501670166f9c404cedacaa8--

From mbj@tail-f.com  Tue Nov 20 00:03:18 2012
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 39C2C21F8538 for ; Tue, 20 Nov 2012 00:03:18 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHOG2LqKDxXC for ; Tue, 20 Nov 2012 00:03:17 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id A86BF21F8524 for ; Tue, 20 Nov 2012 00:03:17 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 49B711200AC8; Tue, 20 Nov 2012 09:03:15 +0100 (CET)
Date: Tue, 20 Nov 2012 09:03:14 +0100 (CET)
Message-Id: <20121120.090314.491002829.mbj@tail-f.com>
To: ietfc@btconnect.com
From: Martin Bjorklund 
In-Reply-To: <00fe01cdc408$ff636960$4001a8c0@gateway.2wire.net>
References:  <00fe01cdc408$ff636960$4001a8c0@gateway.2wire.net>
X-Mailer: Mew version 6.4 on Emacs 23.3 / 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] Attempts and timeouts in ietf-system
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, 20 Nov 2012 08:03:18 -0000

Hi,

t.petch  wrote:
> ----- Original Message -----
> From: "Lange, Jeffrey K (GE Energy)" 
> To: 
> Sent: Wednesday, November 07, 2012 1:52 PM
> Subject: [netmod] Attempts and timeouts in ietf-system
> 
> 
> The ietf-system model defines timeout and attempts leafs for both DNS
> and RADIUS servers as uint8 with no range.  This results in some
> ambiguity as to what the value of 0 means?  Does a server with attempts
> set to 0 mean it's in essence disabled?  Does a timeout of 0 imply it
> should wait forever?
> 
> I think that all of these fields should have a  range from 1..n, it just
> doesn't make sense to allow a zero value for these leafs.

+1

> 
> In many contexts in many systems, a timeout value of zero means no
> timeout, so while that is worth making explicit, I would expect many to
> take it for granted.
> 
> As to whether zero attempts means none or infinite, I would suggest that
> the latter is less likely, but I have seen it.  Again, worth making
> explicit.
> 
> Restricting ranges on the grounds that some do not make sense is
> sensible when the rules for update make it simple to add new values.
> When the rules for update prohibit this, or make in uneconomic to
> contemplate, as happened recently with a management protocol, then it is
> better to allow a wider range with a suitable textual discouragement,
> e.g. ('RESERVED FOR FUTURE USE').

YANG data model update rules allow us to expand the ranges later, if
needed.


/martin

From mbj@tail-f.com  Tue Nov 20 03:47:13 2012
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 7EF4E21F867C for ; Tue, 20 Nov 2012 03:47:13 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-x9MU4BZafF for ; Tue, 20 Nov 2012 03:47:12 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id B778921F85B2 for ; Tue, 20 Nov 2012 03:47:12 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 924591200AC8; Tue, 20 Nov 2012 12:47:10 +0100 (CET)
Date: Tue, 20 Nov 2012 12:47:09 +0100 (CET)
Message-Id: <20121120.124709.476917507.mbj@tail-f.com>
To: andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20121119151643.GA8992@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] draft minutes of the netmod meeting in atlanta
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, 20 Nov 2012 11:47:13 -0000

Andy Bierman  wrote:
> On Mon, Nov 19, 2012 at 7:16 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >  - the system data model editors may want to consult RADIUS experts
> >    regarding the RADIUS client authentication configuration
> >    information needed and
> >
> >
> I already heard from Alan DeKok who suggested that there
> is an IANA registry for EAP types.
> 
> I assume he means the EAP Method Types:
> http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3

Specifically, he wrote:

alan>   OK.  I took a quick look at it.  I'm wary of having yet another
alan> registry.  If at all possible, it would be preferable to leverage
alan> existing registries.
alan> 
alan>   There is an IANA registry for EAP types.  Could netmod just reference
alan> that?
alan> 
alan>   e.g. just define a "radius-eap" type, with a "method" parameter that
alan> contains the actual EAP type to use.

I think this would mean something like this:

  identity radius-eap {
    base radius-authentication-type;
  }

and in the radius config:

  leaf eap-method {
    when "../authentication-type = radius-eap";
    mandatory true;
    type ???;
  }

One problem is the ??? above.  The IANA eap method regsitry defines
integer valued methods, and each such integer has a description, but
no symbolic name.  So we would have to use an integer to refer to the
method.  This is clearly not very user-friendly.

So I am thinking that the best option might be to include the base
identity, the pap/chap identities and the authentication type leaf as
suggested by Jeff Lange, but leave EAP out for now.



/martin

From ietfc@btconnect.com  Fri Nov 23 10:44:28 2012
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 95B4121F862A for ; Fri, 23 Nov 2012 10:44:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level: 
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.870,  BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnpsl6d-IKZe for ; Fri, 23 Nov 2012 10:44:27 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id C714821F862E for ; Fri, 23 Nov 2012 10:44:19 -0800 (PST)
Received: from mail71-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Fri, 23 Nov 2012 18:44:19 +0000
Received: from mail71-tx2 (localhost [127.0.0.1])	by mail71-tx2-R.bigfish.com (Postfix) with ESMTP id 2A2043E01ED; Fri, 23 Nov 2012 18:44:19 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -17
X-BigFish: PS-17(z426fnz9371I542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h)
Received: from mail71-tx2 (localhost.localdomain [127.0.0.1]) by mail71-tx2 (MessageSwitch) id 135369625775808_12948; Fri, 23 Nov 2012 18:44:17 +0000 (UTC)
Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.249])	by mail71-tx2.bigfish.com (Postfix) with ESMTP id 091A760068; Fri, 23 Nov 2012 18:44:17 +0000 (UTC)
Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 23 Nov 2012 18:44:10 +0000
Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.239.5; Fri, 23 Nov 2012 18:43:53 +0000
Message-ID: <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , 
References: <20121116084024.GA2302@elstar.local>
Date: Fri, 23 Nov 2012 15:00:40 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.165]
X-OriginatorOrg: btconnect.com
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 23 Nov 2012 18:44:28 -0000

/ routing defines the router-id as an ipv4 address; this is wrong, it is
a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: 
Sent: Friday, November 16, 2012 8:40 AM


> Hi,
>
> this is the start of the 2nd WG last call on the following set of
> documents:
>
>   http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
>   http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06
>
> A related document, the YANG version of the interface type and
> AFN/SAFI IANA registries, had no issues raised during 1st WG last call
> and has not changed:
>
>   http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04
>
> Please review the documents and raise any issues you might discover by
> opening a thread on the mailing list. Editorial fixes can be sent
> directly to the document editors.
>
> Please indicate your support by *Friday, November 30, 2012*. We are
> not only interested in receiving defect reports, we are equally
> interested in statements of the form:
>
>   "I have reviewed I-D XYZ and I found no issues"
>   "I have implemented the data model in I-D XYZ"
>   "I am implementing the data model in I-D XYZ"
>   "I am considering to implement the data model in I-D XYZ"
>
> /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
>



From lhotka@nic.cz  Sat Nov 24 04:16:21 2012
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 4F96D21F8562 for ; Sat, 24 Nov 2012 04:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmhh8oJEbMG6 for ; Sat, 24 Nov 2012 04:16:20 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1E821F855B for ; Sat, 24 Nov 2012 04:16:20 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 8820413FE26; Sat, 24 Nov 2012 13:16:07 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1353759367; bh=P4WBV6erwbNSsRZJuCWXGWMDjktlisYZrpe1Tj7s0zQ=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=i2bv53IfzoE71h9uIdbDTXIHkFGHnEolwSJFp3x34ecP+97LrzCXIPMDryBNdjCUM rEyPi7hypR4aaN10KS/FZ7sH11FQfYwUPgkAGhB215HDTkXcpV8D6sbTh7eLsYRFAl jjCThr0YJhRBnGfN59Rqf8W1z6+VXcB2/IuDqCXU=
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=windows-1252
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net>
Date: Sat, 24 Nov 2012 13:16:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 24 Nov 2012 12:16:21 -0000

On Nov 23, 2012, at 4:00 PM, t.petch  wrote:

> / routing defines the router-id as an ipv4 address; this is wrong, it =
is
> a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.

The description says:

"Global router ID in the form of an IPv4 address. =85"

And all implementations I am aware of express the 32-bit number in their =
configurations as a dotted quad.

Lada

>=20
> Tom Petch
>=20
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: 
> Sent: Friday, November 16, 2012 8:40 AM
>=20
>=20
>> Hi,
>>=20
>> this is the start of the 2nd WG last call on the following set of
>> documents:
>>=20
>>  http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
>>  http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
>>  http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06
>>=20
>> A related document, the YANG version of the interface type and
>> AFN/SAFI IANA registries, had no issues raised during 1st WG last =
call
>> and has not changed:
>>=20
>>  http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04
>>=20
>> Please review the documents and raise any issues you might discover =
by
>> opening a thread on the mailing list. Editorial fixes can be sent
>> directly to the document editors.
>>=20
>> Please indicate your support by *Friday, November 30, 2012*. We are
>> not only interested in receiving defect reports, we are equally
>> interested in statements of the form:
>>=20
>>  "I have reviewed I-D XYZ and I found no issues"
>>  "I have implemented the data model in I-D XYZ"
>>  "I am implementing the data model in I-D XYZ"
>>  "I am considering to implement the data model in I-D XYZ"
>>=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
>>=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 j.schoenwaelder@jacobs-university.de  Sat Nov 24 05:32:42 2012
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 456A521F84C0 for ; Sat, 24 Nov 2012 05:32:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.908
X-Spam-Level: 
X-Spam-Status: No, score=-102.908 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13cJsB1kaj3v for ; Sat, 24 Nov 2012 05:32:41 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 30CDF21F84B9 for ; Sat, 24 Nov 2012 05:32:41 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2323E20C12; Sat, 24 Nov 2012 14:32:40 +0100 (CET)
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 pn_qQLLf7psA; Sat, 24 Nov 2012 14:32:40 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 785EF20BDB; Sat, 24 Nov 2012 14:32:39 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id CA80A22FDF6B; Sat, 24 Nov 2012 14:32:44 +0100 (CET)
Date: Sat, 24 Nov 2012 14:32:44 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121124133244.GA69956@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "t.petch" , netmod@ietf.org
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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: Sat, 24 Nov 2012 13:32:42 -0000

On Sat, Nov 24, 2012 at 01:16:06PM +0100, Ladislav Lhotka wrote:
> 
> On Nov 23, 2012, at 4:00 PM, t.petch  wrote:
> 
> > / routing defines the router-id as an ipv4 address; this is wrong, it is
> > a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.
> 
> The description says:
> 
> "Global router ID in the form of an IPv4 address. …"
> 
> And all implementations I am aware of express the 32-bit number in their configurations as a dotted quad.
> 

Well, for an IPv6 only network, using an IPv6 address as the router ID
might seem not really useful. My understanding is that router IDs are
indeed unsigned 32-bit integers and commonly people use an IPv4
address. This seems similar to version numbers in DNS zone files that
are numbers but it is common practice to encode a date into the
number. So I think Tom has a point when the suggests to change

         leaf router-id {
           type inet:ipv4-address;
           description
             "Global router ID in the form of an IPv4 address.

              An implementation MAY select a value if this parameter is
              not configured.

              Routing protocols MAY override this global parameter
              inside their configuration.
             ";
         }

to a different type. Perhaps it even makes sense to define a special
YANG typedef that allows a value that is either numeric or a
dotted-quad notional (although we will have then again a problem
because we need to agree on a canonical format).

/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  Sat Nov 24 05:48:57 2012
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 2772F21F8567 for ; Sat, 24 Nov 2012 05:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52eQj2ZF3hI1 for ; Sat, 24 Nov 2012 05:48:56 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAD521F8563 for ; Sat, 24 Nov 2012 05:48:56 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BEF8813FB26; Sat, 24 Nov 2012 14:48:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1353764934; bh=1BPLBsKkB4SPPe3Q5qNxIw2ti3zmzhWCeb/A3Lb/3jQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=XtICB0rgbn/XoddDoC4wQ7wuGHp5Nh4J7tHBuZy0LgFzAYkdJx96eSUXWyDjIylqd ZEsP5FlNI6kTTYW91/FrK8L1HRs/Co/D3+u/WPRZjBc1efmbPbRyl90+kZg2buBrqu DYw6gmNBUvIMWENZeXd1J5PmBJmDjM/Vc5SmIovo=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121124133244.GA69956@elstar.local>
Date: Sat, 24 Nov 2012 14:48:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 24 Nov 2012 13:48:57 -0000

On Nov 24, 2012, at 2:32 PM, Juergen Schoenwaelder =
 wrote:

> On Sat, Nov 24, 2012 at 01:16:06PM +0100, Ladislav Lhotka wrote:
>>=20
>> On Nov 23, 2012, at 4:00 PM, t.petch  wrote:
>>=20
>>> / routing defines the router-id as an ipv4 address; this is wrong, =
it is
>>> a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.
>>=20
>> The description says:
>>=20
>> "Global router ID in the form of an IPv4 address. =85"
>>=20
>> And all implementations I am aware of express the 32-bit number in =
their configurations as a dotted quad.
>>=20
>=20
> Well, for an IPv6 only network, using an IPv6 address as the router ID
> might seem not really useful. My understanding is that router IDs are
> indeed unsigned 32-bit integers and commonly people use an IPv4
> address. This seems similar to version numbers in DNS zone files that
> are numbers but it is common practice to encode a date into the
> number. So I think Tom has a point when the suggests to change
>=20
>         leaf router-id {
>           type inet:ipv4-address;
>           description
>             "Global router ID in the form of an IPv4 address.
>=20
>              An implementation MAY select a value if this parameter is
>              not configured.
>=20
>              Routing protocols MAY override this global parameter
>              inside their configuration.
>             ";
>         }
>=20
> to a different type. Perhaps it even makes sense to define a special
> YANG typedef that allows a value that is either numeric or a
> dotted-quad notional (although we will have then again a problem
> because we need to agree on a canonical format).

One possibility would be to define "dotted-quad" datatype in =
ietf-inet-types and then make "ipv4-address" into a derived type of =
"dotted-quad". However, this looks like hyper-correctness to me - after =
all, real IPv4 addresses inside a packet are also 32-bit numbers. Some =
more explanation in the description should IMO suffice.

Lada
=20
>=20
> /js
>=20
> --=20
> 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 ietfc@btconnect.com  Tue Nov 27 02:53:53 2012
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 66BAC21F84D9 for ; Tue, 27 Nov 2012 02:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level: 
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRfm1qZ7JWTd for ; Tue, 27 Nov 2012 02:53:52 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id A983721F84B5 for ; Tue, 27 Nov 2012 02:53:52 -0800 (PST)
Received: from mail130-co1-R.bigfish.com (10.243.78.235) by CO1EHSOBE014.bigfish.com (10.243.66.77) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 10:53:51 +0000
Received: from mail130-co1 (localhost [127.0.0.1])	by mail130-co1-R.bigfish.com (Postfix) with ESMTP id 1C511D60373; Tue, 27 Nov 2012 10:53:51 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -18
X-BigFish: PS-18(z426fnz98dI9371I542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h)
Received: from mail130-co1 (localhost.localdomain [127.0.0.1]) by mail130-co1 (MessageSwitch) id 1354013629201041_4094; Tue, 27 Nov 2012 10:53:49 +0000 (UTC)
Received: from CO1EHSMHS032.bigfish.com (unknown [10.243.78.234])	by mail130-co1.bigfish.com (Postfix) with ESMTP id 2E3A4DC00C1; Tue, 27 Nov 2012 10:53:49 +0000 (UTC)
Received: from AMSPRD0710HT002.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS032.bigfish.com (10.243.66.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 10:53:48 +0000
Received: from CH1PRD0610HT002.namprd06.prod.outlook.com (157.56.244.229) by pod51017.outlook.com (10.255.160.165) with Microsoft SMTP Server (TLS) id 14.16.239.5; Tue, 27 Nov 2012 10:53:44 +0000
Message-ID: <025d01cdcc8d$4c228c40$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka , Juergen Schoenwaelder 
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz>
Date: Tue, 27 Nov 2012 10:51:43 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.244.229]
Content-Transfer-Encoding: quoted-printable
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 27 Nov 2012 10:53:53 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
To: "Juergen Schoenwaelder" 
Cc: "t.petch" ; 
Sent: Saturday, November 24, 2012 1:48 PM
On Nov 24, 2012, at 2:32 PM, Juergen Schoenwaelder
 wrote:

> On Sat, Nov 24, 2012 at 01:16:06PM +0100, Ladislav Lhotka wrote:
>>
>> On Nov 23, 2012, at 4:00 PM, t.petch  wrote:
>>
>>> / routing defines the router-id as an ipv4 address; this is wrong,
it is
>>> a 32-bit number as defined in, eg, protocols such as OSPF, RFC2328.
>>
>> The description says:
>>
>> "Global router ID in the form of an IPv4 address. =85"
>>
>> And all implementations I am aware of express the 32-bit number in
their configurations as a dotted quad.
>>
>
> Well, for an IPv6 only network, using an IPv6 address as the router ID
> might seem not really useful. My understanding is that router IDs are
> indeed unsigned 32-bit integers and commonly people use an IPv4
> address. This seems similar to version numbers in DNS zone files that
> are numbers but it is common practice to encode a date into the
> number. So I think Tom has a point when the suggests to change
>
>         leaf router-id {
>           type inet:ipv4-address;
>           description
>             "Global router ID in the form of an IPv4 address.
>
>              An implementation MAY select a value if this parameter is
>              not configured.
>
>              Routing protocols MAY override this global parameter
>              inside their configuration.
>             ";
>         }
>
> to a different type. Perhaps it even makes sense to define a special
> YANG typedef that allows a value that is either numeric or a
> dotted-quad notional (although we will have then again a problem
> because we need to agree on a canonical format).

One possibility would be to define "dotted-quad" datatype in
ietf-inet-types and then make "ipv4-address" into a derived type of
"dotted-quad". However, this looks like hyper-correctness to me - after
all, real IPv4 addresses inside a packet are also 32-bit numbers. Some
more explanation in the description should IMO suffice.


Lada

I agree that all the implementations that I know of express the router
id as a dotted quad but that does not make it an IPv4 address:-(  An
IPv4 address has particular semantics, eg for 0.0.0.0 or
255.255.255.255, and many will read meaning into 10.0.0.1 or 192.168.1.2
that does not apply.

Dotted quad is also used for OSPF areas, and here 0.0.0.0 has a quite
different semantic to an IPv4 address of 0.0.0.0.  Were it SNMP, I would
put dotted quad as the display hint, with 32 bit unsigned as the type
but RFC4750 actually says
"AreaID ::=3D TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
          "An OSPF Area Identifier.
           Note that the Area ID, in OSPF, has the same format
           as an IP address, but has the function of defining
           a summarization point for link state advertisements."
       SYNTAX       IpAddress"

Tom Petch


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  Tue Nov 27 03:47:08 2012
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 5C06821F84DE for ; Tue, 27 Nov 2012 03:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESiG7roX6oDB for ; Tue, 27 Nov 2012 03:47:07 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BAE9E21F84DB for ; Tue, 27 Nov 2012 03:47:07 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D1C6413FCD8; Tue, 27 Nov 2012 12:47:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354016825; bh=hO3ABmodh1OLUKPNj+0sIXwgT0guKFO0be/1u0W2UFw=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mt+z6R1ItyljVjBr9lRIxXGWLPepmOtV4wrJqBEg6NbS7Dj/Fvkzoa//WG8hhL/D2 T5Qdt4f7cLlZJuJfndx48pBT/0s0krtAWvL2anARHx7fyncM2L02MqfUefnPjj+sHj A0zq4rjuSyVWIbNAHlLNjSQ5H8Czw2hkc5KRxNVo=
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset=windows-1252
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <025d01cdcc8d$4c228c40$4001a8c0@gateway.2wire.net>
Date: Tue, 27 Nov 2012 12:47:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <55D59973-4376-48CF-AC8C-EE681998A827@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <025d01cdcc8d$4c228c40$4001a8c0@gateway.2wire.net>
To: t.petch 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 27 Nov 2012 11:47:08 -0000

On Nov 27, 2012, at 11:51 AM, t.petch  wrote:
>=20
> 
> Lada
>=20
> I agree that all the implementations that I know of express the router
> id as a dotted quad but that does not make it an IPv4 address:-(  An
> IPv4 address has particular semantics, eg for 0.0.0.0 or
> 255.255.255.255, and many will read meaning into 10.0.0.1 or =
192.168.1.2
> that does not apply.
>=20
> Dotted quad is also used for OSPF areas, and here 0.0.0.0 has a quite
> different semantic to an IPv4 address of 0.0.0.0.  Were it SNMP, I =
would
> put dotted quad as the display hint, with 32 bit unsigned as the type
> but RFC4750 actually says
> "AreaID ::=3D TEXTUAL-CONVENTION
>       STATUS       current
>       DESCRIPTION
>          "An OSPF Area Identifier.
>           Note that the Area ID, in OSPF, has the same format
>           as an IP address, but has the function of defining
>           a summarization point for link state advertisements."
>       SYNTAX       IpAddress"
>=20
> Tom Petch
> 


I guess we have two options:

1. Add a note to "router-id" description, similar to the one in "AreaID" =
definition.

2. Introduce a new type, "dotted-quad" with the same definition as the =
current "ipv4-address". Such a type would probably belong to the =
"ietf-inet-types" module.

I am fine with either option, my only concern is that the latter could =
delay the advancement of the routing draft.

Any opinions?

Lada

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





From ietfc@btconnect.com  Tue Nov 27 09:00:33 2012
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 D6ED821F87B3 for ; Tue, 27 Nov 2012 09:00:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiBWx3Ri7W6u for ; Tue, 27 Nov 2012 09:00:32 -0800 (PST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA921F876B for ; Tue, 27 Nov 2012 09:00:32 -0800 (PST)
Received: from mail28-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Nov 2012 17:00:30 +0000
Received: from mail28-co1 (localhost [127.0.0.1])	by mail28-co1-R.bigfish.com (Postfix) with ESMTP id E31584C01BD; Tue, 27 Nov 2012 17:00:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -18
X-BigFish: PS-18(z426fnz98dI9371I542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h)
Received: from mail28-co1 (localhost.localdomain [127.0.0.1]) by mail28-co1 (MessageSwitch) id 1354035628159876_1580; Tue, 27 Nov 2012 17:00:28 +0000 (UTC)
Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.231])	by mail28-co1.bigfish.com (Postfix) with ESMTP id 2451AB40135; Tue, 27 Nov 2012 17:00:28 +0000 (UTC)
Received: from DBXPRD0710HT005.eurprd07.prod.outlook.com (157.56.253.197) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Nov 2012 16:59:58 +0000
Received: from CH1PRD0610HT001.namprd06.prod.outlook.com (157.56.244.229) by pod51017.outlook.com (10.255.79.168) with Microsoft SMTP Server (TLS) id 14.16.239.5; Tue, 27 Nov 2012 16:59:45 +0000
Message-ID: <06f101cdccc0$6dcab240$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Ladislav Lhotka 
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <025d01cdcc8d$4c228c40$4001a8c0@gateway.2wire.net> <55D59973-4376-48CF-AC8C-EE681998A827@nic.cz>
Date: Tue, 27 Nov 2012 16:58:23 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.244.229]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 27 Nov 2012 17:00:33 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
To: "t.petch" 
Cc: "Juergen Schoenwaelder" ;

Sent: Tuesday, November 27, 2012 11:47 AM
On Nov 27, 2012, at 11:51 AM, t.petch  wrote:
>
> 
> Lada
>
> I agree that all the implementations that I know of express the router
> id as a dotted quad but that does not make it an IPv4 address:-(  An
> IPv4 address has particular semantics, eg for 0.0.0.0 or
> 255.255.255.255, and many will read meaning into 10.0.0.1 or
192.168.1.2
> that does not apply.
>
> Dotted quad is also used for OSPF areas, and here 0.0.0.0 has a quite
> different semantic to an IPv4 address of 0.0.0.0.  Were it SNMP, I
would
> put dotted quad as the display hint, with 32 bit unsigned as the type
> but RFC4750 actually says
> "AreaID ::= TEXTUAL-CONVENTION
>       STATUS       current
>       DESCRIPTION
>          "An OSPF Area Identifier.
>           Note that the Area ID, in OSPF, has the same format
>           as an IP address, but has the function of defining
>           a summarization point for link state advertisements."
>       SYNTAX       IpAddress"
>
> Tom Petch
> 


I guess we have two options:

1. Add a note to "router-id" description, similar to the one in "AreaID"
definition.

2. Introduce a new type, "dotted-quad" with the same definition as the
current "ipv4-address". Such a type would probably belong to the
"ietf-inet-types" module.

I am fine with either option, my only concern is that the latter could
delay the advancement of the routing draft.

Any opinions?


I would introduce a new type, as the right thing for the long term.  We
create this one, we use it for decades (hopefully).

Tom Petch


Lada

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







From j.schoenwaelder@jacobs-university.de  Tue Nov 27 22:55:44 2012
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 55C2821F8461 for ; Tue, 27 Nov 2012 22:55:44 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzRaRPICwYCg for ; Tue, 27 Nov 2012 22:55:43 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4B80921F8455 for ; Tue, 27 Nov 2012 22:55:41 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 767CA20A13; Wed, 28 Nov 2012 07:55:40 +0100 (CET)
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 4kexXgxA9VbN; Wed, 28 Nov 2012 07:55:40 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C874C209DC; Wed, 28 Nov 2012 07:55:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E2D882310C04; Wed, 28 Nov 2012 07:55:45 +0100 (CET)
Date: Wed, 28 Nov 2012 07:55:45 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121128065545.GA99496@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "t.petch" , netmod@ietf.org
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 06:55:44 -0000

On Sat, Nov 24, 2012 at 02:48:54PM +0100, Ladislav Lhotka wrote:
> 
> > Well, for an IPv6 only network, using an IPv6 address as the router ID
> > might seem not really useful. My understanding is that router IDs are
> > indeed unsigned 32-bit integers and commonly people use an IPv4
> > address. This seems similar to version numbers in DNS zone files that
> > are numbers but it is common practice to encode a date into the
> > number. So I think Tom has a point when the suggests to change
> > 
> >         leaf router-id {
> >           type inet:ipv4-address;
> >           description
> >             "Global router ID in the form of an IPv4 address.
> > 
> >              An implementation MAY select a value if this parameter is
> >              not configured.
> > 
> >              Routing protocols MAY override this global parameter
> >              inside their configuration.
> >             ";
> >         }
> > 
> > to a different type. Perhaps it even makes sense to define a special
> > YANG typedef that allows a value that is either numeric or a
> > dotted-quad notional (although we will have then again a problem
> > because we need to agree on a canonical format).
> 
> One possibility would be to define "dotted-quad" datatype in ietf-inet-types and then make "ipv4-address" into a derived type of "dotted-quad". However, this looks like hyper-correctness to me - after all, real IPv4 addresses inside a packet are also 32-bit numbers. Some more explanation in the description should IMO suffice.
> 

If we talk about hyper-correctness, note that the ipv4-address type is
not just a 32-bit number since it includes support for zones. So even
if you use ipv4-address, you would have to subtype it to get rid of
the zone (or add non-machine readable description text stating that
zone information is ignored or something like that).

I assume the simplest solution is to define a router-id type in the
routing data model, something along the lines:

   typedef router-id {
     type string {
       pattern
         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
     }
     description
       "The router-id type represents the identity (a 32-bit unsigned 
        integer value) of a router in dotted-quad notation.";
   }

But then I also find this in RFC 5643:

 Ospfv3RouterIdTC ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "d"
          STATUS      current
          DESCRIPTION
               "A 32-bit, unsigned integer uniquely identifying the
               router in the Autonomous System.  To ensure
               uniqueness, this may default to the value of one of
               the router's IPv4 host addresses if IPv4 is
               configured on the router."
          REFERENCE
               "OSPF for IPv6, Appendix C.1, Global Parameters"
          SYNTAX      Unsigned32 (1..'FFFFFFFF'h)

So apparently, this is not a dotted quad notation in the MIBs anymore
for boxes that do OSPF for IPv6...

/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  Wed Nov 28 03:40:17 2012
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 7558521F87E1 for ; Wed, 28 Nov 2012 03:40:17 -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=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1trCJe7eAzt for ; Wed, 28 Nov 2012 03:40:16 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5581721F8620 for ; Wed, 28 Nov 2012 03:40:16 -0800 (PST)
Received: from [IPv6:2001:1488:ac14:1400:7846:38f9:e10f:fe94] (unknown [IPv6:2001:1488:ac14:1400:7846:38f9:e10f:fe94]) by mail.nic.cz (Postfix) with ESMTPSA id 4EAEB13FD8A; Wed, 28 Nov 2012 12:40:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354102814; bh=/qpCyxsaGDli7yzVYJy9EYPyHOQZaDw9rD+YOA9VYgg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PbxEULenZ+RtQwmzYV1GSukEPbOPUZLKzV5ErPFgzEQmWJGM7MUCRzRAsPOLRiRHG UfJbN6NGa10bPMZaaiF4XkPwllcee0A8ySOt/a3v6JFZYEgz+SrtUC1eJS7pDG5PIq BebkVAVvrSOkaL131plEwnT1cNljkK/rD/J1zEpg=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128065545.GA99496@elstar.local>
Date: Wed, 28 Nov 2012 12:40:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 11:40:17 -0000

On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder =
 wrote:

> On Sat, Nov 24, 2012 at 02:48:54PM +0100, Ladislav Lhotka wrote:
>>=20
>>> Well, for an IPv6 only network, using an IPv6 address as the router =
ID
>>> might seem not really useful. My understanding is that router IDs =
are
>>> indeed unsigned 32-bit integers and commonly people use an IPv4
>>> address. This seems similar to version numbers in DNS zone files =
that
>>> are numbers but it is common practice to encode a date into the
>>> number. So I think Tom has a point when the suggests to change
>>>=20
>>>        leaf router-id {
>>>          type inet:ipv4-address;
>>>          description
>>>            "Global router ID in the form of an IPv4 address.
>>>=20
>>>             An implementation MAY select a value if this parameter =
is
>>>             not configured.
>>>=20
>>>             Routing protocols MAY override this global parameter
>>>             inside their configuration.
>>>            ";
>>>        }
>>>=20
>>> to a different type. Perhaps it even makes sense to define a special
>>> YANG typedef that allows a value that is either numeric or a
>>> dotted-quad notional (although we will have then again a problem
>>> because we need to agree on a canonical format).
>>=20
>> One possibility would be to define "dotted-quad" datatype in =
ietf-inet-types and then make "ipv4-address" into a derived type of =
"dotted-quad". However, this looks like hyper-correctness to me - after =
all, real IPv4 addresses inside a packet are also 32-bit numbers. Some =
more explanation in the description should IMO suffice.
>>=20
>=20
> If we talk about hyper-correctness, note that the ipv4-address type is
> not just a 32-bit number since it includes support for zones. So even
> if you use ipv4-address, you would have to subtype it to get rid of
> the zone (or add non-machine readable description text stating that
> zone information is ignored or something like that).

Yes, that's a good point, so the type of "router-id" is wrong in any =
case.

>=20
> I assume the simplest solution is to define a router-id type in the
> routing data model, something along the lines:
>=20
>   typedef router-id {
>     type string {
>       pattern
>         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>     }
>     description
>       "The router-id type represents the identity (a 32-bit unsigned=20=

>        integer value) of a router in dotted-quad notation.";
>   }
>=20

I can do that but perhaps you could also include "dotted-quad" in the =
future revision of "ietf-inet-types" because it is also used in other =
places.


> But then I also find this in RFC 5643:
>=20
> Ospfv3RouterIdTC ::=3D TEXTUAL-CONVENTION
>          DISPLAY-HINT "d"
>          STATUS      current
>          DESCRIPTION
>               "A 32-bit, unsigned integer uniquely identifying the
>               router in the Autonomous System.  To ensure
>               uniqueness, this may default to the value of one of
>               the router's IPv4 host addresses if IPv4 is
>               configured on the router."
>          REFERENCE
>               "OSPF for IPv6, Appendix C.1, Global Parameters"
>          SYNTAX      Unsigned32 (1..'FFFFFFFF'h)
>=20
> So apparently, this is not a dotted quad notation in the MIBs anymore
> for boxes that do OSPF for IPv6=85

The CLIs of my three "reference" implementations (IOS, JUNOS, BIRD) all =
use the dotted quad notation.

Lada

>=20
> /js
>=20
> --=20
> 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 j.schoenwaelder@jacobs-university.de  Wed Nov 28 04:14:55 2012
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 EC40221F87ED for ; Wed, 28 Nov 2012 04:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.746
X-Spam-Level: 
X-Spam-Status: No, score=-102.746 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qua+njjjsq8H for ; Wed, 28 Nov 2012 04:14:55 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id ACCE621F883A for ; Wed, 28 Nov 2012 04:14:54 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A138A20AFE; Wed, 28 Nov 2012 13:14:53 +0100 (CET)
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 LzEM0XpYPDny; Wed, 28 Nov 2012 13:14:53 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3259F20B6C; Wed, 28 Nov 2012 13:14:53 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 257C8231142D; Wed, 28 Nov 2012 13:15:00 +0100 (CET)
Date: Wed, 28 Nov 2012 13:15:00 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121128121459.GA321@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "t.petch" , netmod@ietf.org
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 12:14:56 -0000

On Wed, Nov 28, 2012 at 12:40:14PM +0100, Ladislav Lhotka wrote:
> 
> > 
> > I assume the simplest solution is to define a router-id type in the
> > routing data model, something along the lines:
> > 
> >   typedef router-id {
> >     type string {
> >       pattern
> >         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
> >       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
> >     }
> >     description
> >       "The router-id type represents the identity (a 32-bit unsigned 
> >        integer value) of a router in dotted-quad notation.";
> >   }
> > 
> 
> I can do that but perhaps you could also include "dotted-quad" in
> the future revision of "ietf-inet-types" because it is also used in
> other places.

I usually prefer to have types that carry more specific semantics.

Introducing a router-id type in the routing document may be
procedurally faster (otherwise the routing document gets a normative
dependency on the 6021bis document and likely sits a long time in the
RFC editor queue).

/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  Wed Nov 28 04:26:43 2012
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 E8E3421F8458 for ; Wed, 28 Nov 2012 04:26:43 -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=-2.599, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyw4y+ETONJf for ; Wed, 28 Nov 2012 04:26:43 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7621F8460 for ; Wed, 28 Nov 2012 04:26:43 -0800 (PST)
Received: from [IPv6:2001:1488:ac14:1400:7846:38f9:e10f:fe94] (unknown [IPv6:2001:1488:ac14:1400:7846:38f9:e10f:fe94]) by mail.nic.cz (Postfix) with ESMTPSA id 9044C13FE17; Wed, 28 Nov 2012 13:26:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354105602; bh=0IwhVQJocZT2Qb5e5ioWtLzFDb3gTZbWLw/XCfQJRjI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rtgkAg0O/4vCycgo3VxaMBdh1GrDSwCqmo8UVsQCR35DsboaBheDUTR1upDfFY1v7 BQOpa0OUJEMdIinxbGSXEAegW7JbMwG/cqyx2jkmqZEKstU4JydluxxGoztj8GaGBE muQrNuLVf6ML9SSIj09CGQGuswYijrmh83gXtae8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128121459.GA321@elstar.local>
Date: Wed, 28 Nov 2012 13:26:42 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz> <20121128121459.GA321@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 12:26:44 -0000

On Nov 28, 2012, at 1:15 PM, Juergen Schoenwaelder =
 wrote:

> On Wed, Nov 28, 2012 at 12:40:14PM +0100, Ladislav Lhotka wrote:
>>=20
>>>=20
>>> I assume the simplest solution is to define a router-id type in the
>>> routing data model, something along the lines:
>>>=20
>>>  typedef router-id {
>>>    type string {
>>>      pattern
>>>        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>>>      +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])';
>>>    }
>>>    description
>>>      "The router-id type represents the identity (a 32-bit unsigned=20=

>>>       integer value) of a router in dotted-quad notation.";
>>>  }
>>>=20
>>=20
>> I can do that but perhaps you could also include "dotted-quad" in
>> the future revision of "ietf-inet-types" because it is also used in
>> other places.
>=20
> I usually prefer to have types that carry more specific semantics.

I think it is better to avoid repeating the clumsy regex patterns.
 =20
>=20
> Introducing a router-id type in the routing document may be
> procedurally faster (otherwise the routing document gets a normative
> dependency on the 6021bis document and likely sits a long time in the
> RFC editor queue).

Absolutely, and that's what I'm going to do in any case.

Lada

>=20
> /js
>=20
> --=20
> 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 j.schoenwaelder@jacobs-university.de  Wed Nov 28 05:03:47 2012
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 E4E2921F85F4 for ; Wed, 28 Nov 2012 05:03:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.914
X-Spam-Level: 
X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLPYLs7cyDEy for ; Wed, 28 Nov 2012 05:03:46 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF0221F85A2 for ; Wed, 28 Nov 2012 05:03:46 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93FA020BD4; Wed, 28 Nov 2012 14:03:45 +0100 (CET)
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 SWCsbJMMxbQx; Wed, 28 Nov 2012 14:03:45 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FE9C20AFE; Wed, 28 Nov 2012 14:03:45 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1CD59231155E; Wed, 28 Nov 2012 14:03:52 +0100 (CET)
Date: Wed, 28 Nov 2012 14:03:52 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121128130352.GB387@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "t.petch" , netmod@ietf.org
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz> <20121128121459.GA321@elstar.local> <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 13:03:47 -0000

On Wed, Nov 28, 2012 at 01:26:42PM +0100, Ladislav Lhotka wrote:
> 
> I think it is better to avoid repeating the clumsy regex patterns.

In favour of what?

There is no generic dotted-quad data type around and waiting for one
to be published as part of 6021bis will leave the routing document in
the RFC editor's queue for quite some time. Or are you now saying we
better use simply uint32?

I am confused now.

/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  Wed Nov 28 09:01:41 2012
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 7A2E421F88B5 for ; Wed, 28 Nov 2012 09:01:41 -0800 (PST)
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]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opic2Lmfht70 for ; Wed, 28 Nov 2012 09:01:40 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8D221F84F9 for ; Wed, 28 Nov 2012 09:01:40 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7224F13FAFF; Wed, 28 Nov 2012 18:01:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354122099; bh=w1n+QSfjrS8FqnZZgqqdSZvJR7GD8BK+J7I/K6y5prQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=gij8qsAF+ghoYzbKWcuJadFcB38NELE1nG7mtcDmJj+oJpyu2UtLKGIKBUPtK7dqr 8va079+rBNg0IUdq30qHFARa9P+aIhcOVe9zmBd53npxeY9SAVs2BRVPqXrN/oYVFW bW2CNGapI2XH70g3fq6etpRcfTyPyGTRLRmrKKq0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128130352.GB387@elstar.local>
Date: Wed, 28 Nov 2012 18:01:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz> <20121128121459.GA321@elstar.local> <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz> <20121128130352.GB387@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 17:01:41 -0000

On Nov 28, 2012, at 2:03 PM, Juergen Schoenwaelder =
 wrote:

> On Wed, Nov 28, 2012 at 01:26:42PM +0100, Ladislav Lhotka wrote:
>>=20
>> I think it is better to avoid repeating the clumsy regex patterns.
>=20
> In favour of what?

In favour of having it just in one place, i.e. in the typedef of =
"dotted-quad".

>=20
> There is no generic dotted-quad data type around and waiting for one
> to be published as part of 6021bis will leave the routing document in
> the RFC editor's queue for quite some time. Or are you now saying we
> better use simply uint32?

No, my plan is to define the "dotted-quad" type in the routing document =
and use it for "router-id". This means no new downrefs for the routing =
document.=20

If, in the future, the "dotted-quad" type appeared in a published =
revision of, say, "ietf-inet-type", the next revision(s) of the routing =
module could use that global "dotted-quad" type instead.

Lada
 =20
>=20
> I am confused now.
>=20
> /js
>=20
> --=20
> 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 Nov 28 09:16:42 2012
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 0EA2A21F8894 for ; Wed, 28 Nov 2012 09:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDkPMkKpOqkP for ; Wed, 28 Nov 2012 09:16:41 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 5B14E21F8871 for ; Wed, 28 Nov 2012 09:16:41 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 480EB13FAFF for ; Wed, 28 Nov 2012 18:16:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354123000; bh=H6naG/X4C+J6y6Qvo2GpFO61IopdRUD9XuyegqPxj5I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=P2txLZ1qj4NjIri3x627pAzXuxk3fWIl5No//6ZEuxFMr8hUZpk14un+Hk640LSZ8 hd80LHcUvJlbmYaYrMkV2GMI0SkAGIzomehNgwn8KUF5oyz0fFImdFihjgdwHe1cju LO6QRTG7auRT0CkQFPCOocdkPeQ90P4NgGvIZK7I=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128065545.GA99496@elstar.local>
Date: Wed, 28 Nov 2012 18:16:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6FCC16C5-2DF6-406A-8194-45D440D794BF@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local>
To: netmod@ietf.org
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Subject: [netmod] IP addresses with zone indices
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, 28 Nov 2012 17:16:42 -0000

On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder =
 wrote:

> If we talk about hyper-correctness, note that the ipv4-address type is
> not just a 32-bit number since it includes support for zones. So even
> if you use ipv4-address, you would have to subtype it to get rid of
> the zone (or add non-machine readable description text stating that
> zone information is ignored or something like that).

BTW, I think there are many uses of IP addresses where zone indices are =
not allowed, so it might be useful to have separate types "ipv4-address" =
and "ipv4-address-with-zone-index", and similarly for "ipv6-*".

Lada

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





From j.schoenwaelder@jacobs-university.de  Wed Nov 28 09:35:06 2012
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 B210621F85FE for ; Wed, 28 Nov 2012 09:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.998
X-Spam-Level: 
X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBfxI9EZ2RQu for ; Wed, 28 Nov 2012 09:35:06 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0258D21F84B9 for ; Wed, 28 Nov 2012 09:35:06 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 598F22096B; Wed, 28 Nov 2012 18:35:05 +0100 (CET)
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 JG8Mhp4XkaZk; Wed, 28 Nov 2012 18:35:05 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC25E20825; Wed, 28 Nov 2012 18:35:04 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 2CB302311B1C; Wed, 28 Nov 2012 18:35:10 +0100 (CET)
Date: Wed, 28 Nov 2012 18:35:10 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121128173510.GA891@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <6FCC16C5-2DF6-406A-8194-45D440D794BF@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6FCC16C5-2DF6-406A-8194-45D440D794BF@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 28 Nov 2012 17:35:06 -0000

On Wed, Nov 28, 2012 at 06:16:39PM +0100, Ladislav Lhotka wrote:
> 
> On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder  wrote:
> 
> > If we talk about hyper-correctness, note that the ipv4-address type is
> > not just a 32-bit number since it includes support for zones. So even
> > if you use ipv4-address, you would have to subtype it to get rid of
> > the zone (or add non-machine readable description text stating that
> > zone information is ignored or something like that).
> 
> BTW, I think there are many uses of IP addresses where zone indices are not allowed, so it might be useful to have separate types "ipv4-address" and "ipv4-address-with-zone-index", and similarly for "ipv6-*".
> 

Hard to judge 'many' - in many cases people forget that they actually
should support zone indexes when it is too late. ;-) Technically, it
is easy to subtype the zone index away if it is in the way.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From j.schoenwaelder@jacobs-university.de  Wed Nov 28 09:37:41 2012
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 E49FD21F861D for ; Wed, 28 Nov 2012 09:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.048
X-Spam-Level: 
X-Spam-Status: No, score=-103.048 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wIU1aZZHUm9 for ; Wed, 28 Nov 2012 09:37:41 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8021F85FE for ; Wed, 28 Nov 2012 09:37:41 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FB8620A9B; Wed, 28 Nov 2012 18:37:40 +0100 (CET)
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 mpkB0ILrIe22; Wed, 28 Nov 2012 18:37:40 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A4BD20A1C; Wed, 28 Nov 2012 18:37:40 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 2E6812311B9E; Wed, 28 Nov 2012 18:37:47 +0100 (CET)
Date: Wed, 28 Nov 2012 18:37:47 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121128173747.GB891@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "t.petch" , netmod@ietf.org
References: <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz> <20121128121459.GA321@elstar.local> <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz> <20121128130352.GB387@elstar.local> <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 17:37:42 -0000

On Wed, Nov 28, 2012 at 06:01:38PM +0100, Ladislav Lhotka wrote:
> > 
> > There is no generic dotted-quad data type around and waiting for one
> > to be published as part of 6021bis will leave the routing document in
> > the RFC editor's queue for quite some time. Or are you now saying we
> > better use simply uint32?
> 
> No, my plan is to define the "dotted-quad" type in the routing document and use it for "router-id". This means no new downrefs for the routing document. 
> 
> If, in the future, the "dotted-quad" type appeared in a published revision of, say, "ietf-inet-type", the next revision(s) of the routing module could use that global "dotted-quad" type instead.
> 

Well, my personal preference would be to have a semantically more
meaningful router-id type instead of an open ended dotted-quad type
but I am able to compromise on this if you feel strongly an open ended
dotted-quad type is more useful.

/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  Wed Nov 28 09:57:50 2012
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 54DB421F86A3 for ; Wed, 28 Nov 2012 09:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPgMBylO-7nZ for ; Wed, 28 Nov 2012 09:57:49 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4721F8623 for ; Wed, 28 Nov 2012 09:57:49 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 6B0F313FAFF; Wed, 28 Nov 2012 18:57:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354125468; bh=t7AFnS0F3Nv8/Or+ObaWeCa2Vzy98m/VeQ+EfGsaf48=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=PNfiTBZk0moAe9fXD/MRcn5q7a3AgfeyCB+huTDT4eAsG5w5ec9Uk7Y2FM12TB0Cj 7DXJHDj8KLPqyoDbx3K2Lwai/MuQNkBp/7EOim+Ojbw5fFl2uM2FbLigIsByXwr1aM j0trtaxEtQG1QP+dGB6fCRboqVdnT2PFr79P1V+s=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128173747.GB891@elstar.local>
Date: Wed, 28 Nov 2012 18:57:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz> <20121128121459.GA321@elstar.local> <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz> <20121128130352.GB387@elstar.local> <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz> <20121128173747.GB891@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 17:57:50 -0000

On Nov 28, 2012, at 6:37 PM, Juergen Schoenwaelder =
 wrote:

> On Wed, Nov 28, 2012 at 06:01:38PM +0100, Ladislav Lhotka wrote:
>>>=20
>>> There is no generic dotted-quad data type around and waiting for one
>>> to be published as part of 6021bis will leave the routing document =
in
>>> the RFC editor's queue for quite some time. Or are you now saying we
>>> better use simply uint32?
>>=20
>> No, my plan is to define the "dotted-quad" type in the routing =
document and use it for "router-id". This means no new downrefs for the =
routing document.=20
>>=20
>> If, in the future, the "dotted-quad" type appeared in a published =
revision of, say, "ietf-inet-type", the next revision(s) of the routing =
module could use that global "dotted-quad" type instead.
>>=20
>=20
> Well, my personal preference would be to have a semantically more
> meaningful router-id type instead of an open ended dotted-quad type
> but I am able to compromise on this if you feel strongly an open ended
> dotted-quad type is more useful.

Well, yes, I do prefer to put semantics on data nodes rather than their =
types.

In fact, the special semantics that Tom mentioned, like 0.0.0.0 or =
255.255.255.255, do not hold universally for all IP addresses but only =
for their special uses, e.g. as a source or destination address, but not =
both.

The practical advantage is that the "dotted-quad" type can be used in =
other contexts, e.g. for OSPF Area ID.

Lada
=20
>=20
> /js
>=20
> --=20
> 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 mbj@tail-f.com  Wed Nov 28 10:26:17 2012
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 3F80A21F858B for ; Wed, 28 Nov 2012 10:26:17 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrZSxr215aac for ; Wed, 28 Nov 2012 10:26:16 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id AE14C21F8415 for ; Wed, 28 Nov 2012 10:26:16 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C9BF81200D10; Wed, 28 Nov 2012 19:26:13 +0100 (CET)
Date: Wed, 28 Nov 2012 19:26:12 +0100 (CET)
Message-Id: <20121128.192612.492072838.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20121128173747.GB891@elstar.local>
References: <20121128130352.GB387@elstar.local> <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz> <20121128173747.GB891@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] 2nd wg last call on interfaces / ip / routing data models
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, 28 Nov 2012 18:26:17 -0000

Juergen Schoenwaelder  wrote:
> On Wed, Nov 28, 2012 at 06:01:38PM +0100, Ladislav Lhotka wrote:
> > > 
> > > There is no generic dotted-quad data type around and waiting for one
> > > to be published as part of 6021bis will leave the routing document in
> > > the RFC editor's queue for quite some time. Or are you now saying we
> > > better use simply uint32?
> > 
> > No, my plan is to define the "dotted-quad" type in the routing document and
> > use it for "router-id". This means no new downrefs for the routing document.
> > 
> > If, in the future, the "dotted-quad" type appeared in a published revision
> > of, say, "ietf-inet-type", the next revision(s) of the routing module could
> > use that global "dotted-quad" type instead.
> > 
> 
> Well, my personal preference would be to have a semantically more
> meaningful router-id type instead of an open ended dotted-quad type

+1

I.e., define router-id, but no dotted-quad.


/martin

From lhotka@nic.cz  Wed Nov 28 23:12:57 2012
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 B2D2921F89E9 for ; Wed, 28 Nov 2012 23:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.924
X-Spam-Level: 
X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j32FH1ODyLHl for ; Wed, 28 Nov 2012 23:12:57 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 142DE21F8937 for ; Wed, 28 Nov 2012 23:12:57 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D390813F68C; Thu, 29 Nov 2012 08:12:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354173175; bh=EgKo9Te7q5Ez2XcnqmWOL92zlS8ekEpFM+8G9ZWVSR8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ZaYuTG8Mv+dfWLC0hygJtFtq6YfuGfITv+A0P0ltuwh7eHgpm4OoMpXFfWd/GI3iP h2c8uO+74wGrevwM2LsrmCLId0NKhodAC8DCHSsoayRMPpeRrVwgBPaYt5r/fwW08L eDs2mHmbUJjg3LTQ1krihlFxG7WT3Vlb5uUUTmaY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128.192612.492072838.mbj@tail-f.com>
Date: Thu, 29 Nov 2012 08:12:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <94593503-1565-4FA7-9130-935E98C69C5B@nic.cz>
References: <20121128130352.GB387@elstar.local> <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz> <20121128173747.GB891@elstar.local> <20121128.192612.492072838.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 29 Nov 2012 07:12:57 -0000

On Nov 28, 2012, at 7:26 PM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
>> On Wed, Nov 28, 2012 at 06:01:38PM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>> There is no generic dotted-quad data type around and waiting for =
one
>>>> to be published as part of 6021bis will leave the routing document =
in
>>>> the RFC editor's queue for quite some time. Or are you now saying =
we
>>>> better use simply uint32?
>>>=20
>>> No, my plan is to define the "dotted-quad" type in the routing =
document and
>>> use it for "router-id". This means no new downrefs for the routing =
document.
>>>=20
>>> If, in the future, the "dotted-quad" type appeared in a published =
revision
>>> of, say, "ietf-inet-type", the next revision(s) of the routing =
module could
>>> use that global "dotted-quad" type instead.
>>>=20
>>=20
>> Well, my personal preference would be to have a semantically more
>> meaningful router-id type instead of an open ended dotted-quad type
>=20
> +1
>=20
> I.e., define router-id, but no dotted-quad.

Why, if there is only one instance of this type? What's wrong on the =
following definition?

      leaf router-id {
        type dotted-quad;
        description
          "Globally unique identifier of the router instance. It is
           a 32-bit number written using the dotted-quad (dot-decimal)
           notation.=20

           An implementation MAY select a value if this parameter is
           not configured. For example, it can be a global IPv4 address
           that is configured on one of the interfaces of this router
           instance.

           Routing protocols MAY override this global parameter
           inside their configuration.
          ";
      }

All necessary information is in one place, and a reader probably even =
won't need to look up
the definition of the "dotted-quad" type.

I don't understand what's "open-ended" with the "dotted-quad" type - it =
just represents an unsigned 32-bit integer expressed in a special =
notation that's widely understood. Nothing more and nothing less.

Without this type, when it comes to defining the OSPF Area ID, is the =
data modeller supposed to create a new type like "ospf-area-id", and =
copy-and-paste the same regex pattern to it? I think this is confusing =
and error-prone.

Lada =20

>=20
>=20
> /martin

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





From lhotka@nic.cz  Wed Nov 28 23:17:58 2012
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 4F66121F8A0E for ; Wed, 28 Nov 2012 23:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.939
X-Spam-Level: 
X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.060,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50C52XD95FmN for ; Wed, 28 Nov 2012 23:17:57 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id AD33521F8A0D for ; Wed, 28 Nov 2012 23:17:57 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id BA99013F68C; Thu, 29 Nov 2012 08:17:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354173476; bh=jdBxM//ueRzq8QahaMHp9SXioBcyxAJ3/238GDlT7d8=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fCu7mDM++OFEyXmbJg62L6ciEwtex7X5j4RitEF/0B0htu0FejFKRIGbddlRssPLI vid/Sa+8XlhnyUYdCxhQPy3Z41a/r69jOEH/Qu2fAr8aetqAx1/Vdg/1nrS5Tq4888 Prr1ZK2ts60/VbIoUTjtWcjmj0z4ZoNYlkY+ZE0I=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121128173510.GA891@elstar.local>
Date: Thu, 29 Nov 2012 08:17:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz>
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <6FCC16C5-2DF6-406A-8194-45D440D794BF@nic.cz> <20121128173510.GA891@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 29 Nov 2012 07:17:58 -0000

On Nov 28, 2012, at 6:35 PM, Juergen Schoenwaelder =
 wrote:

> On Wed, Nov 28, 2012 at 06:16:39PM +0100, Ladislav Lhotka wrote:
>>=20
>> On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder =
 wrote:
>>=20
>>> If we talk about hyper-correctness, note that the ipv4-address type =
is
>>> not just a 32-bit number since it includes support for zones. So =
even
>>> if you use ipv4-address, you would have to subtype it to get rid of
>>> the zone (or add non-machine readable description text stating that
>>> zone information is ignored or something like that).
>>=20
>> BTW, I think there are many uses of IP addresses where zone indices =
are not allowed, so it might be useful to have separate types =
"ipv4-address" and "ipv4-address-with-zone-index", and similarly for =
"ipv6-*".
>>=20
>=20
> Hard to judge 'many' - in many cases people forget that they actually
> should support zone indexes when it is too late. ;-) Technically, it
> is easy to subtype the zone index away if it is in the way.

OK, so let's start with the "ietf-ip" module. Does it make any sense to =
allow a zone index in the value of the "address/ip" leaf? If it does, =
what's the zone index supposed to be?

Lada

>=20
> /js
>=20
> --=20
> 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 j.schoenwaelder@jacobs-university.de  Thu Nov 29 01:22:30 2012
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 0B94621F84C8 for ; Thu, 29 Nov 2012 01:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.081
X-Spam-Level: 
X-Spam-Status: No, score=-103.081 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64qGwS56jhFn for ; Thu, 29 Nov 2012 01:22:29 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 35F0421F84C6 for ; Thu, 29 Nov 2012 01:22:29 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E937F20BFD; Thu, 29 Nov 2012 10:22:27 +0100 (CET)
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 DnQzZwpIXd-a; Thu, 29 Nov 2012 10:22:27 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6B14C20BFA; Thu, 29 Nov 2012 10:22:27 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C1E5123124A6; Thu, 29 Nov 2012 10:22:33 +0100 (CET)
Date: Thu, 29 Nov 2012 10:22:33 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121129092233.GA2172@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <20121116084024.GA2302@elstar.local> <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <6FCC16C5-2DF6-406A-8194-45D440D794BF@nic.cz> <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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: Thu, 29 Nov 2012 09:22:30 -0000

On Thu, Nov 29, 2012 at 08:17:56AM +0100, Ladislav Lhotka wrote:
> 
> On Nov 28, 2012, at 6:35 PM, Juergen Schoenwaelder  wrote:
> 
> > On Wed, Nov 28, 2012 at 06:16:39PM +0100, Ladislav Lhotka wrote:
> >> 
> >> On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder  wrote:
> >> 
> >>> If we talk about hyper-correctness, note that the ipv4-address type is
> >>> not just a 32-bit number since it includes support for zones. So even
> >>> if you use ipv4-address, you would have to subtype it to get rid of
> >>> the zone (or add non-machine readable description text stating that
> >>> zone information is ignored or something like that).
> >> 
> >> BTW, I think there are many uses of IP addresses where zone indices are not allowed, so it might be useful to have separate types "ipv4-address" and "ipv4-address-with-zone-index", and similarly for "ipv6-*".
> >> 
> > 
> > Hard to judge 'many' - in many cases people forget that they actually
> > should support zone indexes when it is too late. ;-) Technically, it
> > is easy to subtype the zone index away if it is in the way.
> 
> OK, so let's start with the "ietf-ip" module. Does it make any sense to allow a zone index in the value of the "address/ip" leaf? If it does, what's the zone index supposed to be?
> 

My point was that 'many' is essentially an arbitrary claim and we can
endlessly discuss this. Its pointless for making progress. I tend to
agree that address/ip in the ietf-ip likely does not need a zone
identifier since it is associated with an interface anyway. Martin?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         

From ietfc@btconnect.com  Thu Nov 29 07:54:11 2012
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 43D7421F8AAE for ; Thu, 29 Nov 2012 07:54:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.674
X-Spam-Level: 
X-Spam-Status: No, score=-3.674 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl8INDM4iayY for ; Thu, 29 Nov 2012 07:54:06 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id EAE0B21F8AA1 for ; Thu, 29 Nov 2012 07:54:05 -0800 (PST)
Received: from mail265-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Nov 2012 15:54:05 +0000
Received: from mail265-va3 (localhost [127.0.0.1])	by mail265-va3-R.bigfish.com (Postfix) with ESMTP id 3A86A1602DE; Thu, 29 Nov 2012 15:54:05 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -18
X-BigFish: PS-18(z426fnz98dI9371I542M1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h304l1155h)
Received: from mail265-va3 (localhost.localdomain [127.0.0.1]) by mail265-va3 (MessageSwitch) id 13542044447019_31794; Thu, 29 Nov 2012 15:54:04 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.248])	by mail265-va3.bigfish.com (Postfix) with ESMTP id E804410800FB; Thu, 29 Nov 2012 15:54:03 +0000 (UTC)
Received: from DBXPRD0710HT005.eurprd07.prod.outlook.com (157.56.253.197) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Nov 2012 15:54:03 +0000
Received: from DB3PRD0410HT004.eurprd04.prod.outlook.com (157.56.252.21) by pod51017.outlook.com (10.255.79.168) with Microsoft SMTP Server (TLS) id 14.16.239.5; Thu, 29 Nov 2012 15:53:59 +0000
Message-ID: <054001cdce49$910a05a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Juergen Schoenwaelder , Ladislav Lhotka 
References: <007901cdc9aa$53bc8720$4001a8c0@gateway.2wire.net> <03394FC3-186E-4621-98F5-84B8023389AF@nic.cz> <20121124133244.GA69956@elstar.local> <2EC57510-ABF9-44DE-A3DD-CFDBE7EB8210@nic.cz> <20121128065545.GA99496@elstar.local> <735F685D-92E6-4E1A-8D87-4C75057471C5@nic.cz> <20121128121459.GA321@elstar.local> <4E5C4455-2290-4EC4-B4F2-F110A43446D1@nic.cz> <20121128130352.GB387@elstar.local> <482559EE-08FB-4FFB-9206-95EAD2B0464C@nic.cz> <20121128173747.GB891@elstar.local>
Date: Thu, 29 Nov 2012 15:50:17 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.252.21]
X-OriginatorOrg: btconnect.com
Cc: netmod@ietf.org
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 29 Nov 2012 15:54:11 -0000

----- Original Message -----
From: "Juergen Schoenwaelder" 
To: "Ladislav Lhotka" 
Cc: "t.petch" ; 
Sent: Wednesday, November 28, 2012 5:37 PM
> On Wed, Nov 28, 2012 at 06:01:38PM +0100, Ladislav Lhotka wrote:
> > >
> > > There is no generic dotted-quad data type around and waiting for
one
> > > to be published as part of 6021bis will leave the routing document
in
> > > the RFC editor's queue for quite some time. Or are you now saying
we
> > > better use simply uint32?
> >
> > No, my plan is to define the "dotted-quad" type in the routing
document and use it for "router-id". This means no new downrefs for the
routing document.
> >
> > If, in the future, the "dotted-quad" type appeared in a published
revision of, say, "ietf-inet-type", the next revision(s) of the routing
module could use that global "dotted-quad" type instead.
> >
>
> Well, my personal preference would be to have a semantically more
> meaningful router-id type instead of an open ended dotted-quad type
> but I am able to compromise on this if you feel strongly an open ended
> dotted-quad type is more useful.

dotted quad, besides router Id, IPv4 address and OSPF area Id, is used
for LSR Id and LMP Node Id, which are similar to router Id; it is not
(officially) used for 4-octet AS numbers or BGP communities.

As long as router Id is not IPv4 address, I am not too fussed which way
this goes (but I hanker after SNMP display hints while realising that
they do not fit the YANG model).

Tom Petch




>
> /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  Thu Nov 29 13:42:44 2012
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 F20C321F8C65 for ; Thu, 29 Nov 2012 13:42:43 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbUYRXsFDAjT for ; Thu, 29 Nov 2012 13:42:43 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4760B21F8BFF for ; Thu, 29 Nov 2012 13:42:43 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 28D6F12008F7 for ; Thu, 29 Nov 2012 22:42:41 +0100 (CET)
Date: Thu, 29 Nov 2012 22:42:40 +0100 (CET)
Message-Id: <20121129.224240.535966809.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20121116084024.GA2302@elstar.local>
References: <20121116084024.GA2302@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
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 29 Nov 2012 21:42:44 -0000

Hi,

Juergen Schoenwaelder  wrote:
> this is the start of the 2nd WG last call on the following set of
> documents:
> 
>   http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
>   http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
>   http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06

Here are my comments on draft-ietf-netmod-routing-cfg-06.

I think Ladislav has done a great job with this document.  My comments
are mostly editorial.


o  2.3

  Remove rip from the prefix list.  The prefix is not used in text,
  and since it is just an example module, it is nice to get rid of it
  from this list.


o  4.2

  The text mentions "destination-prefix".   It is called "dest-prefix"
  in the module.

  Also, should this section mention that this is for the ip families,
  and other modules are supposed to define their own nodes?


o  4.3

    Servers supporting only one routing table per address family MAY
    therefore decide to remove the container
    "recipient-routing-tables", together with its contents, from the
    data model.

  If we want to allow servers to not implement some nodes, we should
  use a feature.  So we should either add a feature for this case, or
  remove this text.


o  4.3

     A routing table MUST NOT appear among its own recipient routing
     tables.

   and:
               must "name != ../../name" {

   I think this is too limited.  We really want to say that there must
   not be any cycles, but we cannot express that with a simple must
   statement.  So I would prefer to add this to the description, and
   remove the must statement.


o  4.4.1

     Every router instance MUST implement exactly one instance of the
     "direct" pseudo-protocol type.  The name of this instance MUST
     also be "direct".

  Should this be:

   Every router instance MUST implement exactly one instance of the
   "direct" pseudo-protocol type.  The "direct" protocol is
   operationally used even if it is not configured.  It can be
   configured in order to disable it (?) or use filters.  If
   configured, the name of this instance MUST be "direct".

     The "direct" pseudo-protocol MUST always be connected to the main
     routing tables of all supported address families.

  I think this should be:

   The "direct" pseudo-protocol is connected to the main
   routing tables of all supported address families.


o  4.5

  Remove the last sentence:

    The default value for the route
    filter type is the identity "deny-all-route-filter".

  This is not true anymore.


o  5.2

     In addition, the "ietf-ip" module allows for configuring IPv4 and
     IPv6 addresses and subnet masks on network layer interfaces.

   s/and subnet masks/and subnet prefixed or masks/ ?

  (twice)


o  Running pyang --ietf on these module reveals two occurrences of
   statements in non-canonical order; ietf-routing@2012-11-15.yang:443
   and ietf-ipv6-unicast-routing@2012-11-15.yang:156.



/martin

From mbj@tail-f.com  Thu Nov 29 13:47:40 2012
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 EE39821F8C6D for ; Thu, 29 Nov 2012 13:47:39 -0800 (PST)
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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdZ3Cs56cJ3Z for ; Thu, 29 Nov 2012 13:47:39 -0800 (PST)
Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 647F021F8C6C for ; Thu, 29 Nov 2012 13:47:39 -0800 (PST)
Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id AA37B12008F7; Thu, 29 Nov 2012 22:47:38 +0100 (CET)
Date: Thu, 29 Nov 2012 22:47:38 +0100 (CET)
Message-Id: <20121129.224738.335399884.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20121129092233.GA2172@elstar.local>
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@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] IP addresses with zone indices
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, 29 Nov 2012 21:47:40 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Nov 29, 2012 at 08:17:56AM +0100, Ladislav Lhotka wrote:
> > 
> > On Nov 28, 2012, at 6:35 PM, Juergen Schoenwaelder
> >  wrote:
> > 
> > > On Wed, Nov 28, 2012 at 06:16:39PM +0100, Ladislav Lhotka wrote:
> > >> 
> > >> On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder
> > >>  wrote:
> > >> 
> > >>> If we talk about hyper-correctness, note that the ipv4-address type is
> > >>> not just a 32-bit number since it includes support for zones. So even
> > >>> if you use ipv4-address, you would have to subtype it to get rid of
> > >>> the zone (or add non-machine readable description text stating that
> > >>> zone information is ignored or something like that).
> > >> 
> > >> BTW, I think there are many uses of IP addresses where zone indices are
> > >> not allowed, so it might be useful to have separate types "ipv4-address"
> > >> and "ipv4-address-with-zone-index", and similarly for "ipv6-*".
> > >> 
> > > 
> > > Hard to judge 'many' - in many cases people forget that they actually
> > > should support zone indexes when it is too late. ;-) Technically, it
> > > is easy to subtype the zone index away if it is in the way.
> > 
> > OK, so let's start with the "ietf-ip" module. Does it make any sense to
> > allow a zone index in the value of the "address/ip" leaf? If it does, what's
> > the zone index supposed to be?
> > 
> 
> My point was that 'many' is essentially an arbitrary claim and we can
> endlessly discuss this. Its pointless for making progress. I tend to
> agree that address/ip in the ietf-ip likely does not need a zone
> identifier since it is associated with an interface anyway. Martin?

I agree.  So how should we do this?  If we believe that a subtype w/o
the zone identifier is useful in general this should go into
ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe
not even use a typedef).


/martin

From alex@cisco.com  Thu Nov 29 14:20:40 2012
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 4DEB421F8BF3 for ; Thu, 29 Nov 2012 14:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irSjlm5yZsmG for ; Thu, 29 Nov 2012 14:20:39 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 57E1E21F886A for ; Thu, 29 Nov 2012 14:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3470; q=dns/txt; s=iport; t=1354227639; x=1355437239; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Fbuh/sTvyGklxJOUIuP+H50XWC1qlmhLh4TbqtcoZAU=; b=kCM3Ne1Lxn4XUREm3rwCdAlHFQYRA24kjpMaJBBSQFtTyQFhp5RL8rO3 0K9HbrkZFZW+if4GdiOTZ8rKs3mny0RKY7qQXiqn56fgs0+VkVNdqgyDV 8m8Uip+ByvXoxmlrn+3t/Ey9A1tHU/S4WrIjb8TH1Vo7218noCWB1vjWt o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAEret1CtJXHB/2dsb2JhbABBA8AFFnOCHgEBAQQBAQE3NBcCAgIBCA4CAQQBAQsUCQcbDAsUCQgCBAESCIgIDL8UBIw8gRWCS2EDlx2PKIJygWMGOA
X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="144733663"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2012 22:20:38 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qATMKcNJ007162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 22:20:38 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.79]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 16:20:38 -0600
From: "Alexander Clemm (alex)" 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] 2nd wg last call on interfaces / ip / routing data models
Thread-Index: AQHNw9YQjjnSUgBCv0WKck8rLEOVrZgBblsg
Date: Thu, 29 Nov 2012 22:20:38 +0000
Message-ID: 
References: <20121116084024.GA2302@elstar.local>
In-Reply-To: <20121116084024.GA2302@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.154.200.200]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 29 Nov 2012 22:20:40 -0000

Hi,

I have reviewed http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg=
-08 and have just a few comments:

- leaf location (p13):
It seems to make sense to add a clause analogous to the description in leaf=
 "name" that spells out what happens if an application were to try to set l=
ocation in a manner that is invalid.  There, it states "If a NETCONF server=
 that implements this restriction is
sent a value that doesn't match the restriction, it MUST
reply with an rpc-error with the error-tag
'invalid-value'."

- leaf enabled (p13):
Just as a thought, here is always a possibility that an application does no=
t initially populate all leaves when creating an interface, but sends them =
e.g. in successive operations.  That raises the question when the interface=
 should actually go into effect .  Would it make sense to add a clause to t=
he description that states that if an interface is initially created but do=
es not yet contain all the settings, an application SHOULD set the leaf to =
"enabled=3Dfalse"?  (Or should perhaps even the default be false, not true,=
 for that reason to require explicit turning on of the interface when the c=
onfiguration is fully ready?) =20

- leaf oper-status, enum value "not-present" (p14): I am wondering if the d=
escription can be made a little more specific - the precise meaning of "som=
e component is missing" is not clear.  At a minimum, the enum description s=
hould add what is stated further below (typically, missing hardware compone=
nts)? =20

- leaf last-change (p15):
Would it make sense to name this "last-oper-change"?  "last-change" could a=
lso be interpreted to mean "last config change", but this is not what is me=
ant here. =20

Thanks
--- Alex

-----Original Message-----
From: netmod-bounces@ietf.org [mailto:netmod-bounces@ietf.org] On Behalf Of=
 Juergen Schoenwaelder
Sent: Friday, November 16, 2012 12:40 AM
To: netmod@ietf.org
Subject: [netmod] 2nd wg last call on interfaces / ip / routing data models

Hi,

this is the start of the 2nd WG last call on the following set of
documents:

  http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
  http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07
  http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-06

A related document, the YANG version of the interface type and AFN/SAFI IAN=
A registries, had no issues raised during 1st WG last call and has not chan=
ged:

  http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-04

Please review the documents and raise any issues you might discover by open=
ing a thread on the mailing list. Editorial fixes can be sent directly to t=
he document editors.

Please indicate your support by *Friday, November 30, 2012*. We are not onl=
y interested in receiving defect reports, we are equally interested in stat=
ements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented the data model in I-D XYZ"
  "I am implementing the data model in I-D XYZ"
  "I am considering to implement the data model in I-D XYZ"

/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

From j.schoenwaelder@jacobs-university.de  Thu Nov 29 14:58:31 2012
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 4BBED21F8B0F for ; Thu, 29 Nov 2012 14:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.105
X-Spam-Level: 
X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpQXra6KMX5b for ; Thu, 29 Nov 2012 14:58:30 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC2721F8B08 for ; Thu, 29 Nov 2012 14:58:28 -0800 (PST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFBF020222; Thu, 29 Nov 2012 23:58:26 +0100 (CET)
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 mkrDtixClXPK; Thu, 29 Nov 2012 23:58:26 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47F6720BDA; Thu, 29 Nov 2012 23:58:25 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AD60B23132A6; Thu, 29 Nov 2012 23:58:32 +0100 (CET)
Date: Thu, 29 Nov 2012 23:58:32 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20121129225832.GA3474@elstar.local>
Mail-Followup-To: Martin Bjorklund , lhotka@nic.cz, netmod@ietf.org
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20121129.224738.335399884.mbj@tail-f.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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: Thu, 29 Nov 2012 22:58:31 -0000

On Thu, Nov 29, 2012 at 10:47:38PM +0100, Martin Bjorklund wrote:
> 
> I agree.  So how should we do this?  If we believe that a subtype w/o
> the zone identifier is useful in general this should go into
> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe
> not even use a typedef).
> 

Yep, I would simply add a suitable simple pattern to address/ip and
declare the issue resolved.

/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  Fri Nov 30 01:41:16 2012
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 4324B21F846A for ; Fri, 30 Nov 2012 01:41:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level: 
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0XCzcMZYBKe for ; Fri, 30 Nov 2012 01:41:15 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7F91221F843E for ; Fri, 30 Nov 2012 01:41:15 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 4C66C13F64F; Fri, 30 Nov 2012 10:41:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354268473; bh=UitgRShj1+ZF6loHMgU5lsVgPidYx+uVRLhSKTr/glc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tWcqj1OXKeC7QCk4Na8rPpL4JYxcJzX+m88xxLqMViPD7861K7ZsxrninXkB4zDEX YqitVXIjEDHPELS2qBWMRSol4wwnUHrGnhsqm95q85gKfGQPyhxLW12jo/1DK3c1no v6R+yhDibq2r73t51hVhx/Uh8oYHaBkvhPO4YEik=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121129.224738.335399884.mbj@tail-f.com>
Date: Fri, 30 Nov 2012 10:41:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 30 Nov 2012 09:41:16 -0000

On Nov 29, 2012, at 10:47 PM, Martin Bjorklund  wrote:

> Juergen Schoenwaelder  wrote:
>> On Thu, Nov 29, 2012 at 08:17:56AM +0100, Ladislav Lhotka wrote:
>>>=20
>>> On Nov 28, 2012, at 6:35 PM, Juergen Schoenwaelder
>>>  wrote:
>>>=20
>>>> On Wed, Nov 28, 2012 at 06:16:39PM +0100, Ladislav Lhotka wrote:
>>>>>=20
>>>>> On Nov 28, 2012, at 7:55 AM, Juergen Schoenwaelder
>>>>>  wrote:
>>>>>=20
>>>>>> If we talk about hyper-correctness, note that the ipv4-address =
type is
>>>>>> not just a 32-bit number since it includes support for zones. So =
even
>>>>>> if you use ipv4-address, you would have to subtype it to get rid =
of
>>>>>> the zone (or add non-machine readable description text stating =
that
>>>>>> zone information is ignored or something like that).
>>>>>=20
>>>>> BTW, I think there are many uses of IP addresses where zone =
indices are
>>>>> not allowed, so it might be useful to have separate types =
"ipv4-address"
>>>>> and "ipv4-address-with-zone-index", and similarly for "ipv6-*".
>>>>>=20
>>>>=20
>>>> Hard to judge 'many' - in many cases people forget that they =
actually
>>>> should support zone indexes when it is too late. ;-) Technically, =
it
>>>> is easy to subtype the zone index away if it is in the way.
>>>=20
>>> OK, so let's start with the "ietf-ip" module. Does it make any sense =
to
>>> allow a zone index in the value of the "address/ip" leaf? If it =
does, what's
>>> the zone index supposed to be?
>>>=20
>>=20
>> My point was that 'many' is essentially an arbitrary claim and we can
>> endlessly discuss this. Its pointless for making progress. I tend to
>> agree that address/ip in the ietf-ip likely does not need a zone
>> identifier since it is associated with an interface anyway. Martin?
>=20
> I agree.  So how should we do this?  If we believe that a subtype w/o
> the zone identifier is useful in general this should go into
> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe
> not even use a typedef).

Would you mind defining the "dotted-quad" type there and using it for =
"ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure =
there will be other uses.

Lada

>=20
>=20
> /martin

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





From j.schoenwaelder@jacobs-university.de  Fri Nov 30 02:15:41 2012
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 383A221F86BD for ; Fri, 30 Nov 2012 02:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.123
X-Spam-Level: 
X-Spam-Status: No, score=-103.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McVCx9upzKDP for ; Fri, 30 Nov 2012 02:15:40 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E52C21F86AD for ; Fri, 30 Nov 2012 02:15:40 -0800 (PST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 594CE20C1B; Fri, 30 Nov 2012 11:15:39 +0100 (CET)
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 tLKhAAg9Yink; Fri, 30 Nov 2012 11:15:39 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C49B420C1A; Fri, 30 Nov 2012 11:15:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 86BF42313D69; Fri, 30 Nov 2012 11:15:45 +0100 (CET)
Date: Fri, 30 Nov 2012 11:15:45 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121130101545.GA6989@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com> 
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] IP addresses with zone indices
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, 30 Nov 2012 10:15:41 -0000

On Fri, Nov 30, 2012 at 10:41:12AM +0100, Ladislav Lhotka wrote:
> 
> > 
> > I agree.  So how should we do this?  If we believe that a subtype w/o
> > the zone identifier is useful in general this should go into
> > ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe
> > not even use a typedef).
> 
> Would you mind defining the "dotted-quad" type there and using it for "ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure there will be other uses.
> 

There is an IP address type in RFC 6021 and I think this is what we
should use unless we have concensus it is broken. I do not think it is
broken.

/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  Fri Nov 30 02:20:45 2012
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 B24A621F86C3 for ; Fri, 30 Nov 2012 02:20:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.956
X-Spam-Level: 
X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNHH1pUp+Mpe for ; Fri, 30 Nov 2012 02:20:45 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC3821F86BE for ; Fri, 30 Nov 2012 02:20:45 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 07A1214048B; Fri, 30 Nov 2012 11:20:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354270844; bh=wOMp6ak7nKr9JZkGoj0oIM2HygWYW5ASI6Lui4DFJek=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=MZ0fF+xp4JoUqkT3LPqWLJFserdOkwfIgtExC4PQK05FiXT4kfOkUQhSUTJsHRa4C /3usbVmS1g8Fpp4Lbgj5QYsemj9S0oZMIXcu4KtWB+qsI3/civ3ZwDFYF8aHdpZjYd H9zU9DLfC9OQfpxZfo0uCBsLdUS7rtQG5TTbb6ZA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121130101545.GA6989@elstar.local>
Date: Fri, 30 Nov 2012 11:20:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz>
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>  <20121130101545.GA6989@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 30 Nov 2012 10:20:45 -0000

On Nov 30, 2012, at 11:15 AM, Juergen Schoenwaelder =
 wrote:

> On Fri, Nov 30, 2012 at 10:41:12AM +0100, Ladislav Lhotka wrote:
>>=20
>>>=20
>>> I agree.  So how should we do this?  If we believe that a subtype =
w/o
>>> the zone identifier is useful in general this should go into
>>> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip =
(maybe
>>> not even use a typedef).
>>=20
>> Would you mind defining the "dotted-quad" type there and using it for =
"ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure =
there will be other uses.
>>=20
>=20
> There is an IP address type in RFC 6021 and I think this is what we
> should use unless we have concensus it is broken. I do not think it is
> broken.

It is certainly not broken and the routing module will continue using =
it, e. g. for "next-hop" in routes.
The "dotted-quad" type would simply enable code reuse. I see no point in =
having the same formidable regex patterns in multiple places.

Lada
=20
>=20
> /js
>=20
> --=20
> 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 j.schoenwaelder@jacobs-university.de  Fri Nov 30 02:44:30 2012
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 2E6DA21F8617 for ; Fri, 30 Nov 2012 02:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.137
X-Spam-Level: 
X-Spam-Status: No, score=-103.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7IQVPeHmKZJ for ; Fri, 30 Nov 2012 02:44:20 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 490D121F8611 for ; Fri, 30 Nov 2012 02:44:20 -0800 (PST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A091D20C22; Fri, 30 Nov 2012 11:44:19 +0100 (CET)
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 o_oP_kesd2WY; Fri, 30 Nov 2012 11:44:19 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 036A620C1E; Fri, 30 Nov 2012 11:44:18 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5C50A2313E1F; Fri, 30 Nov 2012 11:44:26 +0100 (CET)
Date: Fri, 30 Nov 2012 11:44:26 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121130104426.GA7067@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>  <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 30 Nov 2012 10:44:30 -0000

On Fri, Nov 30, 2012 at 11:20:43AM +0100, Ladislav Lhotka wrote:
> 
> On Nov 30, 2012, at 11:15 AM, Juergen Schoenwaelder  wrote:
> 
> > On Fri, Nov 30, 2012 at 10:41:12AM +0100, Ladislav Lhotka wrote:
> >> 
> >>> 
> >>> I agree.  So how should we do this?  If we believe that a subtype w/o
> >>> the zone identifier is useful in general this should go into
> >>> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip (maybe
> >>> not even use a typedef).
> >> 
> >> Would you mind defining the "dotted-quad" type there and using it for "ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure there will be other uses.
> >> 
> > 
> > There is an IP address type in RFC 6021 and I think this is what we
> > should use unless we have concensus it is broken. I do not think it is
> > broken.
> 
> It is certainly not broken and the routing module will continue using it, e. g. for "next-hop" in routes.
> The "dotted-quad" type would simply enable code reuse. I see no point in having the same formidable regex patterns in multiple places.
> 

I believe the proper type for ipv4/address/ip is ipv4-address.

Perhaps there could be a universal dotted-quad type somewhere at
sometime. But our goal right now is to finish and deliver. Having a
dotted-quad pattern copied is not worth further delaying the
completion of this work.

/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  Fri Nov 30 02:49:53 2012
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 71F8F21F86FF for ; Fri, 30 Nov 2012 02:49:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.962
X-Spam-Level: 
X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkFDprTG1ra7 for ; Fri, 30 Nov 2012 02:49:52 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A6E7A21F84D0 for ; Fri, 30 Nov 2012 02:49:52 -0800 (PST)
Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id D83F2140404; Fri, 30 Nov 2012 11:49:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354272585; bh=jkcxcMyrSKs9H+ur3BSgLJlSJq0pecBvGsYyWLEcp8M=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=mu8+Mmh5vdnHksFHBBLzRgCQwlVUMHxXPyTnfgij3pg3s3EtS8DgXhA74BJayHpBk +J7k/L/rj49dxP+0HrXc0fHSQmaAnAobrOWTLXs/1RGrxKDRHbX++1B3GnOe2PgTuN 48HK6tQ9F6BRHNuz4CYQiVqojoVx7IC3y6wFptPo=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121130104426.GA7067@elstar.local>
Date: Fri, 30 Nov 2012 11:49:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>  <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 30 Nov 2012 10:49:53 -0000

On Nov 30, 2012, at 11:44 AM, Juergen Schoenwaelder =
 wrote:

> On Fri, Nov 30, 2012 at 11:20:43AM +0100, Ladislav Lhotka wrote:
>>=20
>> On Nov 30, 2012, at 11:15 AM, Juergen Schoenwaelder =
 wrote:
>>=20
>>> On Fri, Nov 30, 2012 at 10:41:12AM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>>>=20
>>>>> I agree.  So how should we do this?  If we believe that a subtype =
w/o
>>>>> the zone identifier is useful in general this should go into
>>>>> ietf-inet-types.  Otherwise we can subtype privately in ietf-ip =
(maybe
>>>>> not even use a typedef).
>>>>=20
>>>> Would you mind defining the "dotted-quad" type there and using it =
for "ipv4/address/ip"? I'd reuse the for the "router-id", and I am sure =
there will be other uses.
>>>>=20
>>>=20
>>> There is an IP address type in RFC 6021 and I think this is what we
>>> should use unless we have concensus it is broken. I do not think it =
is
>>> broken.
>>=20
>> It is certainly not broken and the routing module will continue using =
it, e. g. for "next-hop" in routes.
>> The "dotted-quad" type would simply enable code reuse. I see no point =
in having the same formidable regex patterns in multiple places.
>>=20
>=20
> I believe the proper type for ipv4/address/ip is ipv4-address.

I had the impression we all agreed that zone indices are not desirable =
there and therefore the "ipv4-address" type won't be used for it - at =
least the one from "ietf-inet-types".
=20
>=20
> Perhaps there could be a universal dotted-quad type somewhere at
> sometime. But our goal right now is to finish and deliver. Having a
> dotted-quad pattern copied is not worth further delaying the
> completion of this work.

If it is defined in "ietf-ip", it won't create any (new) downrefs.

Lada
=20
>=20
> /js
>=20
> --=20
> 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 j.schoenwaelder@jacobs-university.de  Fri Nov 30 02:53:12 2012
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 E942B21F84ED for ; Fri, 30 Nov 2012 02:53:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.148
X-Spam-Level: 
X-Spam-Status: No, score=-103.148 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPTaZf5+kX2t for ; Fri, 30 Nov 2012 02:53:12 -0800 (PST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5292E21F84D0 for ; Fri, 30 Nov 2012 02:53:12 -0800 (PST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AEBBC20C1E; Fri, 30 Nov 2012 11:53:11 +0100 (CET)
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 0aWQh0C26eab; Fri, 30 Nov 2012 11:53:11 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4BC6C20C1D; Fri, 30 Nov 2012 11:53:11 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A2AEF2313E83; Fri, 30 Nov 2012 11:53:18 +0100 (CET)
Date: Fri, 30 Nov 2012 11:53:18 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20121130105318.GA7104@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>  <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local> 
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] IP addresses with zone indices
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, 30 Nov 2012 10:53:13 -0000

On Fri, Nov 30, 2012 at 11:49:43AM +0100, Ladislav Lhotka wrote:
> 
> > 
> > I believe the proper type for ipv4/address/ip is ipv4-address.
> 
> I had the impression we all agreed that zone indices are not desirable there and therefore the "ipv4-address" type won't be used for it - at least the one from "ietf-inet-types".
>  

The ipv4-address type is more generic, so you subtype it to make it
specific to what ipv4/address/ip needs. This can very easily be done
inline of the leaf definition. Not a big deal, get it done, move on.

> > Perhaps there could be a universal dotted-quad type somewhere at
> > sometime. But our goal right now is to finish and deliver. Having a
> > dotted-quad pattern copied is not worth further delaying the
> > completion of this work.
> 
> If it is defined in "ietf-ip", it won't create any (new) downrefs.

But then it will still be in the wrong place. And ietf-ip won't 
need this type since ipv4/address/ip is an ipv4-address (and
ipv6/address/ip is an IPv6 address without a zone id).

/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  Fri Nov 30 04:35:53 2012
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 EE5B921F8860 for ; Fri, 30 Nov 2012 04:35:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.966
X-Spam-Level: 
X-Spam-Status: No, score=-1.966 tagged_above=-999 required=5 tests=[AWL=0.033,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR0p6vsqIyKM for ; Fri, 30 Nov 2012 04:35:53 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id ED5FD21F885F for ; Fri, 30 Nov 2012 04:35:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 27B165405BE for ; Fri, 30 Nov 2012 13:35:51 +0100 (CET)
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 yyXPED2gLCfY for ; Fri, 30 Nov 2012 13:35:45 +0100 (CET)
Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id BB1C8540297 for ; Fri, 30 Nov 2012 13:35:41 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
In-Reply-To: <20121129.224240.535966809.mbj@tail-f.com>
References: <20121116084024.GA2302@elstar.local> <20121129.224240.535966809.mbj@tail-f.com>
User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: netmod@ietf.org
Date: Fri, 30 Nov 2012 13:35:20 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [netmod] 2nd wg last call on interfaces / ip / routing data models
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, 30 Nov 2012 12:35:54 -0000

Hi Martin,

thanks for the review, I applied most of your suggestions, and below are my comments to the rest.

Martin Bjorklund  writes:
>
> o  4.3
>
>     Servers supporting only one routing table per address family MAY
>     therefore decide to remove the container
>     "recipient-routing-tables", together with its contents, from the
>     data model.
>
>   If we want to allow servers to not implement some nodes, we should
>   use a feature.  So we should either add a feature for this case, or
>   remove this text.

OK, I will add a new feature "multiple-routing-tables".

>
>
> o  4.3
>
>      A routing table MUST NOT appear among its own recipient routing
>      tables.
>
>    and:
>                must "name != ../../name" {
>
>    I think this is too limited.  We really want to say that there must
>    not be any cycles, but we cannot express that with a simple must
>    statement.  So I would prefer to add this to the description, and
>    remove the must statement.

No, I think it is correct. Cycles are permitted, the simplest case being a pair of routing tables that receive routes from each other. Because of route filters, this may be actually quite useful. 

>
>
> o  4.4.1
>
>      Every router instance MUST implement exactly one instance of the
>      "direct" pseudo-protocol type.  The name of this instance MUST
>      also be "direct".
>
>   Should this be:
>
>    Every router instance MUST implement exactly one instance of the
>    "direct" pseudo-protocol type.  The "direct" protocol is
>    operationally used even if it is not configured.  It can be
>    configured in order to disable it (?) or use filters.  If
>    configured, the name of this instance MUST be "direct".

OK, I will use this formulation. This is where the missing link between configuration and state data makes things complicated. 

I will also disable the "connected-routing-tables" node for the "direct-protocol", by means of a "when" or "must" constraint.

>
> o  Running pyang --ietf on these module reveals two occurrences of
>    statements in non-canonical order; ietf-routing@2012-11-15.yang:443
>    and ietf-ipv6-unicast-routing@2012-11-15.yang:156.

Yes, and thanks for correcting it.

Lada

>
>
>
> /martin
> _______________________________________________
> 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  Fri Nov 30 07:16:28 2012
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 3A00921F8B11 for ; Fri, 30 Nov 2012 07:16:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level: 
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.030,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Btw+VgrYaY0M for ; Fri, 30 Nov 2012 07:16:27 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6D88D21F8543 for ; Fri, 30 Nov 2012 07:16:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id C645F5405BE; Fri, 30 Nov 2012 16:16:25 +0100 (CET)
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 VNKrivrkbzyL; Fri, 30 Nov 2012 16:16:16 +0100 (CET)
Received: from localhost (unknown [10.107.191.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id B5D69540113; Fri, 30 Nov 2012 16:16:12 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: <20121116084024.GA2302@elstar.local>
References: <20121116084024.GA2302@elstar.local>
User-Agent: Notmuch/0.14+100~ge0adf10 (http://notmuchmail.org) Emacs/23.3.50.1 (i386-apple-darwin9.8.0)
Mail-Followup-To: Juergen Schoenwaelder , netmod@ietf.org
Date: Fri, 30 Nov 2012 16:15:51 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [netmod] LL review of interfaces and ip drafts
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, 30 Nov 2012 15:16:28 -0000

Hi,

Juergen Schoenwaelder  writes:
> this is the start of the 2nd WG last call on the following set of
> documents:
>
>   http://tools.ietf.org/html/draft-ietf-netmod-interfaces-cfg-08
>   http://tools.ietf.org/html/draft-ietf-netmod-ip-cfg-07

I reviewed both drafts and I think they now fulfil the stated objectives. I especially like the approach to interface layering, it is simple yet clever.

Here are my comments:

** draft-ietf-netmod-interfaces-cfg-08

*** Section 3.3

OLD

   There are two state data leaf-list nodes "higher-layer-if" and
   "lower-layer-if" defined, that contains a read-only view of the
   interface layering hierarchy.

NEW

   Two state data leaf-lists, "higher-layer-if" and "lower-layer-if",
   represent a read-only view of the interface layering hierarchy.

*** Appendix E.1

Since the IANA type doesn't discriminate fast and gigabit ethernet,
what is supposed to happen if a physical interface is pre-provisioned
as "fastethernet-1/0" and then a gigabit ethernet port appears at
location "1/0"?

** draft-ietf-netmod-ip-cfg-07

*** Section 4

    - Why are the defaults for "prefix-length" set to 32 for IPv4 and
      128 for IPv6? Such values are only useful for loopback
      interfaces. I'd recommend to remove the defaults and make these
      leafs mandatory.
    - As we've been discussing in a separate thread, the "ip" leafs
      should not use the "inet:ipv[46]-address" types because of the
      zone indices. I think it is not very practical to use a
      restriction of said types because it probably means that
      validation of each configured IP address would involve matching
      it against two regular expressions where the expression in the
      definition of "inet:ipv[46]-address" type is completely
      redundant.

Lada

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

From lhotka@nic.cz  Fri Nov 30 07:51:22 2012
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 7A6FA21F84C6 for ; Fri, 30 Nov 2012 07:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level: 
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, J_CHICKENPOX_23=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNuYEq8uEG4s for ; Fri, 30 Nov 2012 07:51:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 1417121F8B25 for ; Fri, 30 Nov 2012 07:51:10 -0800 (PST)
Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 7FDCD13F9B0; Fri, 30 Nov 2012 16:51:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1354290668; bh=Ii8N5ozknPzvHYo5M32qvKLdSEXlAcOgN95QYAf+hRw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=AhIyNN6Gq2KDDJYkc1r1ZrcPilR9nsAvkOI7NACLW69O2QbZcKHpvx9DeUoBy4dYV Vzqx2T8YkrfhirpTys49cMJrXuqLFcp0wm/N5cK35Qmg1l8pem6VBRcBmNluqR9h2b PZIhQnfCA3vjMH6dGgbc8JDBqfz6qGN+hbYldeQI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Ladislav Lhotka 
In-Reply-To: <20121130105318.GA7104@elstar.local>
Date: Fri, 30 Nov 2012 16:51:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121128173510.GA891@elstar.local> <743AE045-177A-4C9C-B90A-45B769E8EE64@nic.cz> <20121129092233.GA2172@elstar.local> <20121129.224738.335399884.mbj@tail-f.com>  <20121130101545.GA6989@elstar.local> <3CDC6495-DDAE-4190-B84E-D3BA6EAF5F4D@nic.cz> <20121130104426.GA7067@elstar.local>  <20121130105318.GA7104@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.1499)
X-Virus-Scanned: clamav-milter 0.96.5 at mail
X-Virus-Status: Clean
Cc: netmod@ietf.org
Subject: Re: [netmod] IP addresses with zone indices
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, 30 Nov 2012 15:51:22 -0000

On Nov 30, 2012, at 11:53 AM, Juergen Schoenwaelder =
 wrote:

> On Fri, Nov 30, 2012 at 11:49:43AM +0100, Ladislav Lhotka wrote:
>>=20
>>>=20
>>> I believe the proper type for ipv4/address/ip is ipv4-address.
>>=20
>> I had the impression we all agreed that zone indices are not =
desirable there and therefore the "ipv4-address" type won't be used for =
it - at least the one from "ietf-inet-types".
>>=20
>=20
> The ipv4-address type is more generic, so you subtype it to make it
> specific to what ipv4/address/ip needs. This can very easily be done
> inline of the leaf definition. Not a big deal, get it done, move on.

Not a big deal for human readers, if they never mind the regular =
expressions, but it means a performance penalty for automatic =
validation. Given that something like 95 % IP addresses appearing =
elsewhere in configurations or state data will not use zone indices, I =
am not sure it is worth the extra cycles. Perhaps a better model for =
those places that permit zone indices would be

1.2.3.4
eth0

with zone-id being optional.

Lada
 =20
>=20
>>> Perhaps there could be a universal dotted-quad type somewhere at
>>> sometime. But our goal right now is to finish and deliver. Having a
>>> dotted-quad pattern copied is not worth further delaying the
>>> completion of this work.
>>=20
>> If it is defined in "ietf-ip", it won't create any (new) downrefs.
>=20
> But then it will still be in the wrong place. And ietf-ip won't=20
> need this type since ipv4/address/ip is an ipv4-address (and
> ipv6/address/ip is an IPv6 address without a zone id).
>=20
> /js
>=20
> --=20
> 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 andy@yumaworks.com  Fri Nov 30 14:27:22 2012
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 8448D21F8605 for ; Fri, 30 Nov 2012 14:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVzhdjrplPWy for ; Fri, 30 Nov 2012 14:27:22 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CF90521F859A for ; Fri, 30 Nov 2012 14:27:21 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so160316vcb.31 for ; Fri, 30 Nov 2012 14:27:21 -0800 (PST)
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=2MYM4kLKfoM1Jd8yAeEnW0gwfI6xEoJLlkYjm9gZZCI=; b=Ye0cjtwNP1M9emunNiiyCYo4ePd9dFKAflOxstdUdhXSqOi2IdbaDLOHYE2Souk8gn Of+FrHHWRn/nETJPQMw1Q4+5FbSJwwPT+KwaQmfcGgryq26CJbhuM2CBLPkoCsGsvkyN tDDjQ1CbjZ/zRgeb+H6/JoFpeK2ZRZofhISmZYeJNSdLqMi8lu+H2kN/piNbF95xb111 scZ9Mj77jmQfoqAHXGiaZ3mw/5JdQjYE/7byKuR5o0nZgH+8rglpIcjalU2fExNuzB26 +/iTTUxSM0yJi3uMBLhxUxoYSpBd5cI184xwAf9igdC1cK4xd6ojFTPBYC+br6WY98Ng C7xQ==
MIME-Version: 1.0
Received: by 10.52.98.105 with SMTP id eh9mr2062833vdb.11.1354314441167; Fri, 30 Nov 2012 14:27:21 -0800 (PST)
Received: by 10.58.69.14 with HTTP; Fri, 30 Nov 2012 14:27:21 -0800 (PST)
In-Reply-To: <20121130222344.14056.57485.idtracker@ietfa.amsl.com>
References: <20121130222344.14056.57485.idtracker@ietfa.amsl.com>
Date: Fri, 30 Nov 2012 14:27:21 -0800
Message-ID: 
From: Andy Bierman 
To: Netconf , netmod@ietf.org
Content-Type: multipart/alternative; boundary=20cf307f319e2e12c104cfbde7cd
X-Gm-Message-State: ALoCoQlPuNxAazHJUp/tD9HrBY0Gu9t29soFKj9XwvRn/4ICirEXbY4MrT938r22Fhovlo4vLCGq
Subject: [netmod] Fwd: New Version Notification for draft-bierman-netconf-yang-api-01.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, 30 Nov 2012 22:27:22 -0000

--20cf307f319e2e12c104cfbde7cd
Content-Type: text/plain; charset=UTF-8

FYI,

The YANG-API draft has been updated and made much simpler.


Andy


---------- Forwarded message ----------
From: 
Date: Fri, Nov 30, 2012 at 2:23 PM
Subject: New Version Notification for draft-bierman-netconf-yang-api-01.txt
To: andy@yumaworks.com
Cc: mbj@tail-f.com



A new version of I-D, draft-bierman-netconf-yang-api-01.txt
has been successfully submitted by Andy Bierman and posted to the
IETF repository.

Filename:        draft-bierman-netconf-yang-api
Revision:        01
Title:           YANG-API Protocol
Creation date:   2012-11-30
WG ID:           Individual Submission
Number of pages: 68
URL:
http://www.ietf.org/internet-drafts/draft-bierman-netconf-yang-api-01.txt
Status:
http://datatracker.ietf.org/doc/draft-bierman-netconf-yang-api
Htmlized:
http://tools.ietf.org/html/draft-bierman-netconf-yang-api-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-yang-api-01

Abstract:
   This document describes a RESTful protocol that provides a
   programmatic interface over HTTP for accessing data defined in YANG,
   using the datastores defined in NETCONF.




The IETF Secretariat

--20cf307f319e2e12c104cfbde7cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

FYI,

The YANG-API draft has been updated and made much s=
impler.


Andy


---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>

Date: Fri, Nov 30, 2012 at 2:23 PM
Subject: New Version Notification for=
 draft-bierman-netconf-yang-api-01.txt
To: andy@yumaworks.com
Cc: mb=
j@tail-f.com





A new version of I-D, draft-bierman-netconf-yang-api-01.txt

has been successfully submitted by Andy Bierman and posted to the

IETF repository.



Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-bierman-netconf-yang-api

Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A001

Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG-API Protocol

Creation date: =C2=A0 2012-11-30

WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Number of pages: 68

URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.ietf.org/internet-drafts/draft-bierman-netconf-yang-api-01.txt<=
/a>

Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://datatrac=
ker.ietf.org/doc/draft-bierman-netconf-yang-api

Htmlized: =C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/=
html/draft-bierman-netconf-yang-api-01

Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http=
://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-netconf-yang-api-01



Abstract:

=C2=A0 =C2=A0This document describes a RESTful protocol that provides a

=C2=A0 =C2=A0programmatic interface over HTTP for accessing data defined in=
 YANG,

=C2=A0 =C2=A0using the datastores defined in NETCONF.









The IETF Secretariat







--20cf307f319e2e12c104cfbde7cd--