thanks for the information
On Thursday, January 4, 2018 4:42 AM, "ietf-request@xxxxxxxx" <ietf-request@xxxxxxxx> wrote:
Send ietf mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ietf digest..."
Today's Topics:
1. Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root? (S Moonesamy)
2. Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root? (Nick Hilliard)
3. Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root? (Mark Andrews)
4. Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root? (Amreesh Phokeer)
5. Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root? (S Moonesamy)
6. Re: Last Call: <draft-ietf-netmod-entity-07.txt> (A YANG Data
Model for Hardware Management) to Proposed Standard (tom p.)
----------------------------------------------------------------------
Message: 1
Date: Wed, 03 Jan 2018 15:13:50 -0800
From: S Moonesamy <sm+ietf@xxxxxxxxxxxx>
Subject: Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root?
Message-ID: <6.2.5.6.2.20180103145346.11b53e40@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Dave,
At 09:08 AM 02-01-2018, Dave Burstein wrote:
>today. The principles are simple; the implementation is demanding.
>So I'm asking engineers, "What technical systems must must be built
>to ensure robust interconnection, assuming everyone wants to work in
>good faith?"
The proceedings of SIGCOMM 1988, 106-114, discuss about survivability
in the face of failure. That might be similar to the "robust
interconnection" which is mentioned above. Part of the message [1] is
about DNS. There is a 2006 document about that (SSAC 009).
Regards,
S. Moonesamy
------------------------------
Message: 2
Date: Wed, 03 Jan 2018 23:54:42 +0000
From: Nick Hilliard <nick@xxxxxxxxxx>
To: S Moonesamy <sm+ietf@xxxxxxxxxxxx>
Subject: Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root?
Message-ID: <5A4D6D42.9050800@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8
S Moonesamy wrote:
> Hi Dave,
> At 09:08 AM 02-01-2018, Dave Burstein wrote:
>> today. The principles are simple; the implementation is demanding. So
>> I'm asking engineers, "What technical systems must must be built to
>> ensure robust interconnection, assuming everyone wants to work in good
>> faith?"
>
> The proceedings of SIGCOMM 1988, 106-114, discuss about survivability in
> the face of failure. That might be similar to the "robust
> interconnection" which is mentioned above. Part of the message [1] is
> about DNS. There is a 2006 document about that (SSAC 009).
it would be important to be careful about language. "Interconnection"
refers to IP layer connectivity, but this is a discussion about
alternative DNS roots.
The technical work on this was done in two tranches: the first works in
the 1990s were a result of the AlterNIC saga, when BIND 4.9 was hardened
against dns pollution from alternative servers. Until then, DNS
poisoning from misconfigured and malconfigured DNS server had been an
ongoing problem, but this formed a new baseline standard for handling
cache pollution.
The second major improvement was dnssec, which requires a single root
per resolver. If Russia or anyone else sets up an alternative root, then
dnssec-enabled resolution will fail for dnssec domains on other roots.
Incidentally, alternative DNS roots are nothing new. ICANN even has an
info page on them:
Nick
------------------------------
Message: 3
Date: Thu, 4 Jan 2018 13:48:34 +1100
From: Mark Andrews <marka@xxxxxxx>
To: Nick Hilliard <nick@xxxxxxxxxx>
Cc: S Moonesamy <sm+ietf@xxxxxxxxxxxx>, Dave Burstein
Subject: Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root?
Message-ID: <C1C08207-6F30-4E17-A580-E6ABFE3E61A5@xxxxxxx>
Content-Type: text/plain; charset=utf-8
> On 4 Jan 2018, at 10:54 am, Nick Hilliard <nick@xxxxxxxxxx> wrote:
>
> S Moonesamy wrote:
>> Hi Dave,
>> At 09:08 AM 02-01-2018, Dave Burstein wrote:
>>> today. The principles are simple; the implementation is demanding. So
>>> I'm asking engineers, "What technical systems must must be built to
>>> ensure robust interconnection, assuming everyone wants to work in good
>>> faith?"
>>
>> The proceedings of SIGCOMM 1988, 106-114, discuss about survivability in
>> the face of failure. That might be similar to the "robust
>> interconnection" which is mentioned above. Part of the message [1] is
>> about DNS. There is a 2006 document about that (SSAC 009).
>
> it would be important to be careful about language. "Interconnection"
> refers to IP layer connectivity, but this is a discussion about
> alternative DNS roots.
>
> The technical work on this was done in two tranches: the first works in
> the 1990s were a result of the AlterNIC saga, when BIND 4.9 was hardened
> against dns pollution from alternative servers. Until then, DNS
> poisoning from misconfigured and malconfigured DNS server had been an
> ongoing problem, but this formed a new baseline standard for handling
> cache pollution.
>
> The second major improvement was dnssec, which requires a single root
> per resolver. If Russia or anyone else sets up an alternative root, then
> dnssec-enabled resolution will fail for dnssec domains on other roots.
It requires that trust anchors be install for each of the namespaces so
that DNSSEC will work. Its a bit brittle but not impossible. If ICANN
was to remove .ru from the root you could restore validation by configuring
the validators to know about .ru DNSSEC key.
e.g. (for BIND/named)
managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
ru. initial 257 3 8 "AwEAAcqaT0pNXB/C84rvc/ola8FMLUBF4roNNt4062EjXlUcKIHCCy/Xw4gkQzYG4pfr4MVsjUwp2D1SFFGGwx3Gp2/gZ1za7mGDoNHUeIZqGRxJmHlWatwaFcFh2yteyHRHh5L0WaJkMhoWrojXBf5S/Cl4BFr/5VuSFMuFV7JrEFkv9ybsiGEvsLT6c/bEhduqHSYj5wAvwHep7If92UO8accRP5AxAphkb6dlRc6kv+yJ+GABaNvxHMYJLwYai2/yvhpvvluT9BB/BtIct85Xh1BTcDpGnv1fhJo/dJPTcynjXY0i5GPVvQaOZbuyHdZEaCUJfSWAmERjYvpPlcamiTE=?;
};
zone ?ru? {
type stub;
masters { 194.190.124.17; 193.232.156.17; 193.232.128.6; 193.232.142.17; 194.85.252.62; };
file ?ru.stub?;
};
Similar is possible for all other nameservers.
> Incidentally, alternative DNS roots are nothing new. ICANN even has an
> info page on them:
>
>
> Nick
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx
------------------------------
Message: 4
Date: Thu, 4 Jan 2018 10:04:30 +0400
From: Amreesh Phokeer <amreesh.phokeer@xxxxxxxxx>
To: Dave Burstein <daveb@xxxxxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root?
Message-ID:
<CACRw5znS6vbNzSLq9N8qFh9kqk8thuesexz4oR5RmbmaeJep=g@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Hi Dave,
On Tue, Jan 2, 2018 at 9:08 PM, Dave Burstein <daveb@xxxxxxxxxxxx> wrote:
>
> I'm on the U.S. State Department ITAC and know the U.S. position is that
> DNS must be controlled by ICANN (which does a decent job.)
> Columbia Professor Eli Noam convinced me a "network of networks" was
> possible <http://bit.ly/ManyNets>
> ?. With "robust interconnection" Noam and ICANN CEO Fadi Chehadi confirmed
> to me there was no technical reason the Chinese, Hebrews, Verizon or any
> other competent party couldn't set up independently. With "robust
> inteerconnection" the primary benefits of "The Internet" could be
> maintained. Fadi added the rub was how to ensure that robust
> interconnection.
>
Indeed. A truly decentralized internet is what we should aim for. But think
of DNSSEC, things are very much centralized at the moment.
There have been some attempts:
And also some blockchain-based alternatives:
Regards,
--
Amreesh Phokeer
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 5
Date: Wed, 03 Jan 2018 23:18:50 -0800
From: S Moonesamy <sm+ietf@xxxxxxxxxxxx>
Cc: Dave Burstein <daveb@xxxxxxxxxxxx>
Subject: Re: Reporter re: Technical solution for robust
interconnection if Russia & BRICs set own root?
Message-ID: <6.2.5.6.2.20180103223446.112110f8@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"; format=flowed
Hi Nick,
At 03:54 PM 03-01-2018, Nick Hilliard wrote:
>it would be important to be careful about language. "Interconnection"
>refers to IP layer connectivity, but this is a discussion about
>alternative DNS roots.
Yes. There isn't much to add to an "alternative DNS roots"
discussion as there has been numerous discussions about that topic.
Regards,
S. Moonesamy
------------------------------
Message: 6
Date: Thu, 4 Jan 2018 12:37:02 -0000
From: "tom p." <daedulus@xxxxxxxxxxxxx>
To: <ietf@xxxxxxxx>
Subject: Re: Last Call: <draft-ietf-netmod-entity-07.txt> (A YANG Data
Model for Hardware Management) to Proposed Standard
Message-ID: <04bb01d38558$bf88b4a0$4001a8c0@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
This I-D illlustrates a problem that the netmod WG has been wrestling
with for a decade or more and (IMHO) has yet fully to solve. This I-D
is in Last Call at the same time as netmod-revised-datastores, which
proposes the most recent solution.
The problem is that an 'object' can take more than one value and the
question is how to represent that. Previously it was by having twin
trees in the schema; now it is by having one common schema and multiple
datastores, <running> for the user-supplied values, <operational> for
those actually in use, the latter including values learnt from the
hardware or protocols or some other means.
In this model the situation arises with 'serial-num' which may take a
value from the hardware or may be written as part of configuration (the
idea of configuring serial numbers may seem unusual but has been
inherited from the Entity MIB [RFC6933] with the endorsement of the
netmod WG).
So if there is an accessible hardware value and the user writes a value,
who wins? There is no way of specifying this, neither in YANG nor in
'revised-datastores'; in this case, the 'description' specifies that the
value determined from the component should be used so a user can
configure a value, see it in the <running> datastore but not in the
<operational> datastore and cannot tell why, unless they are familiar
with the minutiae of description clauses.
In this case, the model is clear as to which value, configured or
learnt, wins; here, it is learnt. In other cases, it may be that
configured wins or that may be something a user wants to influence as
part of policy.
Is that still one schema or is it now two slightly different schemas
based on the description clause coupled with the datastore that the
schema is being applied to?
Is the description clause an adequate way of expressing policy?
In passing, routing protocols addressed this dilemma a long time ago,
with concepts such as 'Admin Distance'.
(Whether or not this particular value should be configurable is a
different and irrelevant discussion; the MIB WG decided it should be,
the YANG WG likewise - and there are plenty of other objects which
illustrate this dilemma, how to specify who wins).
Tom Petch
----- Original Message -----
From: "The IESG" <iesg-secretary@xxxxxxxx>
Sent: Thursday, December 21, 2017 10:22 PM
> The IESG has received a request from the Network Modeling WG (netmod)
to
> consider the following document: - 'A YANG Data Model for Hardware
Management'
> <draft-ietf-netmod-entity-07.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
final
> comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2018-01-10. Exceptionally, comments may
be
> sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
> This document defines a YANG data model for the management of
> hardware on a single server.
>
> The file can be obtained via
>
> IESG discussion can be tracked via
>
> No IPR declarations have been submitted directly on this I-D.
------------------------------
Subject: Digest Footer
_______________________________________________
ietf mailing list
------------------------------
End of ietf Digest, Vol 116, Issue 6
************************************