From nobody Wed Nov 1 11:53:51 2017
Return-Path: Hello Adrian, Thanks again for your highly detailed review.=C2=A0 Please see bel=
ow: At the moment, you should also consider that devices leak like
sieves.=C2=A0 Bad guys can do a very good job of mapping devices th=
ey
are looking for, and aggregating that information.=C2=A0 So before =
you
go reaching for that button, get hold of WireShark :-( And as you consider this as an issue, also consider the threat
that you face at home.=C2=A0 Every single one of those devices, if
hacked, will absolutely violate your privacy, to say the least.=C2=A0=
The goal here is to stop that.
Hello,=20
I have been selected as the Routing Directorate reviewer for this draft. =
The
Routing Directorate seeks to review all routing or routing-related drafts=
as
they pass through IETF last call and IESG review, and sometimes on specia=
l
request. The purpose of the review is to provide assistance to the Routin=
g ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg=
Dir=20
Although these comments are primarily for the use of the Routing ADs, it =
would
be helpful if you could consider them along with any other IETF Last Call=
comments that you receive, and strive to resolve them through discussion =
or by
updating the draft.=20
Document: draft-ietf-opsawg-mud-13.txt
Reviewer: Adrian Farrel=20
Review Date: 1 November 2017
IETF LC End Date: 7 November 2017
Intended Status: Standard Track
Overview
Manufacturer Usage Descriptions (MUD) provide a means for elements of
an IoT network to indicate what sorts of access and network=20
functionality they require in order to function properly. The=20
emphasis of this document is on access control although the authors=20
envision future extensions for "other aspects".
The document is a collection of bits and pieces to enable MUD: two
YANG modules, IPv4 and IPv6 DHCP options, an LLDP TLV, a URL suffix
specification, an X.509 certificate extension, and a means to sign and=
verify the descriptions.
Some future work is listed, but I see no evidence that this work is=20
actually anything more than a possibility: there are no drafts that=20
appear to cover any additional MUD specifications.
=20
Summary:=20
I have some minor concerns about this document that I think should be
resolved before publication. I have flagged one of these as a more
serious issue, although I think it may be possible to solve with some
2119 language that governs expectations on implementations.
The document was easy to read although the number of minor issues and
nits in the early section suggests that the late-stage reviews were more
focused on the YANG than the text.
Adrian
=3D=3D=3D
Major Issues:=20
I know I ranted about privacy before and the authors took some text I wro=
te as
the basis of the privacy considerations, but I'm still worried that the d=
efault
will be that devices are MUD-enabled (good) and that users will not be
protected. It would be sad if the user's only option is to reject MUD dev=
ices
(especially as they might not even know that the devices are MUD-enabled)=
=2E More
burble below, but it seems to me that we should make privacy-supporting m=
odes of
operation at least the default, but possibly the only approach.
Section 15 has...
The release of a MUD URL by a Thing reveals what the Thing is, and
provides an attacker with guidance on what vulnerabilities may be
present.
Pleased to see this text: it was a security concern I had. Good to have
it flagged. However, the mitigation suggested 2 paragraphs later is a
bit thin and sounds rather optional. I see how an implementer might
take action, but what can a user do to protect their device? [...]
While this may not be a *perfect* solve for all of your concerns, I
hope you will find=C2=A0 the proposal below Good Enough.=C2=A0 Keep i=
n mind
that we are attempting to address a very broad set of devices with a
large variety of capabilities, from energy-harvesting devices that
may never encrypt (think a wall switch) to devices that have heaps
of power and memory (think robots).=C2=A0 Many of the devices have ve=
ry
limited privacy concerns, while others will have quite a few.=C2=A0 I=
n
addition, whatever capabilities the device has must intersect the
capabilities found in deployments.
With all that in mind, what I propose is the following:
=3D=3D=3D
Minor Issues:=20
The last call indicated a Downref to draft-ietf-netmod-acl-model. All wel=
l and
good.
idnits reports RFC 2818 as a Downref as well, but didn't appear in the la=
st
call.
It's on the right list.
---
Abstract
Referring to "Things" is cute, but actually doesn't help the reader.
Could you give a clue or two?
BTW, the definition in 1.6 is a little thin and circular. A Thing is=20
something to which you apply MUD, but what is it actually?
This is addressed, I think, in response to mnot's review.
---
The Abstract says...
The initial focus is on access control.
But the Introduction says...
Although this memo may seem to stress
access requirements, usage intent also consists of quality of service
needs a device may have.
Please decide which you mean.
Right.=C2=A0 Mark caught this as well.
---
Introduction
OLD
The Internet has largely been constructed on general purpose
computers, those devices that may be used for a purpose that is
specified by those who buy the device.
NEW
The Internet is largely constructed from general purpose computers.
These are devices that may be used for a purpose that is specified by
those who buy the device.
Although this is ambiguous and probably wrong: I think routers and=20
switches probably form a part of the Internet, and I suspect they are
somewhat specific to their use.
I think the participle we are looking for is "for".=C2=A0 Propose to
change to that.
---
Introduction
In the context of a smarter
device that has a built in Linux stack, it might be an integrator of
that device.
Is there something special about Linux?
That's meant as an example, nothing more.=C2=A0 To clarify, I propose=
to
add "For example" in the previous sentence.
---
1.5
This section introduces the "MUD controller." It's unexplained.
It could be helpful to pull section 1.6 up perhaps to 1.3.
Ok.
---
There seems to be some overlap of terms and definitions in 1.5 and 1.6.=
pre>
Can you be more specific?
---
1.7 has a nice picture, thanks.
But I note that the text describes a "web site" while the picture shows
a "file server".
Similarly, the text has "network management system" while the picture
has "MUD controller".
What I propose is to make the terms consistent, but added
parentheticals to remind people what those terms mean.
---
3.3 makes reference to "is supported" and 3.4 gives clarity to what=20
that means. Shouldn't this section also describe the meaning of this
object when the Thang isn't supported?
That is actually discussed in Section 3.4 (these are short
sections).
Yes.
---
3.5 has me confused. Looks like a fine idea, but how does it work? A
Thing reports the MUD URL, and the file that is pulled contains the
systeminfo URL, and the info that is pulled contains the localised info.
Have I got that right?
That means that the MUD URL has to include the correct systeminfo for
the locality. Presumably we're interested in the locality of the MUD
controller.
The intent here is basically to allow for language tags to do their
thing through one level of indirection.=C2=A0 That doesn't require an=
y
specific change to the URL itself.=C2=A0 I've included some text in
response to Mark, but that text may further shift based on other
suggestions Mark may have.
---
16.2
Something messed up here.
We have
The IANA has allocated option 161 in the Dynamic Host Configuration
Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters registry
for the MUD DHCPv4 option.
IANA is requested to allocated the DHCPv4 and v6 options as specified
in Section 9.
But section 9 has 161 and 112 explicitly mentioned.
116 is already in the registry, but presumably you have an IANA action
to update the reference to this document when it becomes an RFC.
112 is also already in the DHCPv6 options registry.
So you probably want to point at that instead of the current 2nd para.
=3D=3D=3D=3D =20 Nits:=20 Introduction Please do NOT use random uppercase words in your text. There's NO need: the readers are no more stupid than the average reader of an RFC. Ditto 3.4, 3.6
--- Introduction The key points are that the device itself is expected to serve a limited purpose, I think you mean s/expected/intended/
--- Introduction The intent of MUD is to solve for the following problems: d/for/
Although the list that follows is not a list of problems. So, perhaps, The intent of MUD is to provide the following function:
--- Introduction o Provide for a means to scale network policies to the ever- increasing number types of devices in the network. d/for/
s/types/of types/
--- Introduction Provide a means to address at least some vulnerabilities in a way that is faster than it might take to update systems. s/than/than the time/ --- Introduction o A classifier that a device emits that can be used to locate a description; Classifier or classification?
--- OLD 1.1. What MUD doesn't do NEW 1.1. What MUD Doesn't Do
--- Section 1.1 No matter how good a MUD-enabled network is, it will never replace the need for manufacturers to patch vulnerabilities. It may, however, provide network administrators with some additional protection when those vulnerabilities exist. Does this paragraph belong in this section? Seems to say what MUD does, not what MUD doesn't do. Maybe flip the order of presentation?... MUD may provide network administrators with some protection when vulnerabilities exist, however, no matter how good a MUD-enabled=20 network is, it will never replace the need for manufacturers to=20 patch vulnerabilities.
--- 1.2 s/an app on smart phone/an application on a smart phone/
--- 1.4 para 2 Might be worth splitting this into bullets
--- 1.5 s/configuration of is/configuration is/
--- 2. s/only"accept"/only "accept"/
--- I think [I-D.ietf-netmod-rfc6087bis] may be used in a normative way to explain the notation used in this document.
--- 3. Note that in this section, when we use the term "match" we are referring to the ACL model "matches" node, and thus returns positive such that an action should be applied. Is that English? I know what it means, but not what it says.
--- 3.1 s/containers indicate/containers indicates/
--- 3.1 [I-D.ietf-netmod-acl-model] describes access-lists but does not attempt to indicate where they are applied as that is handled elsewhere in a configuration "a configuration file?" "operation"? "in configuration information"?
ok--- 3.8 Say that this is a null-valued node
--- 3.11 s/mud/MUD/
file"ietf-l3vpn-svc@2017-09-14.yang"
>>>> module ietf-l3vpn-svc-2 {
>>>> yang-version 1.1;
>>>> namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
>>>> prefix l3vpn-svc;
>>>> *_obsolete|update _*ietf-l3vpn-svc@2017-01-2
>>>>
>>>> And whose responsibility is this to warn/push all authors of
>>>> ietf-routing YANG modules to move to ietf-routing-2? (*)
>>>>
>>>> The following are non solution IMO:
>>>> - Going from the draft-wu-l3sm-rfc8049bis YANG _module _to the
>>>> draft-wu-l3sm-rfc8049bis _document _to lookup the IETF "obsolete"
>>>> flag in order to understand that the RFC8049 YANG module is
>>>> obsolete is not an automatic solution.
>>>> - Using the yangcatalog.org might be a solution as we track the
>>>> derived semantic, but this is just an offline trick. This is not
>>>> what I call "automatic way"
>>>> - Using the YANG module description field might be interesting, but
>>>> again this is not an "automatic way":
>>>>
>>>> description
>>>> "This YANG module defines a generic service configuration
>>>> model for Layer 3 VPNs. This model is common across all
>>>> vendor implementations. This obsoletes the RFC8049 YANG
>>>> module, ietf-l3vpn-svc@2017-01-2";
>>>> revision 2017-09-14 {
>>>> description
>>>>
>>>> "First revision ofRFC8049 .";
>>>> reference
>>>> "RFC xxxx: YANG Data Model for L3VPN Service Delivery";
>>>>
>>>>
>>>> In conclusion, I believe openconfig got this right and that
>>>> solution #1 is the solution to go ... while waiting for a new YANG
>>>> keyword in YANG 2.0
>>>>
>>>> (*) If you want to change the module from ietf-routing to
>>>> ietf-routing-2, then you should follow with all authors of
>>>> dependent modules to make sure they transition to ietf-routing-2
>>>> In the yangcatalog.org, because I needed the information as OPS AD,
>>>> we created a small script to get that authors list for IETF drafts.
>>>> For the ietf-routing, this produces the following
>>>> {
>>>> Â Â Â "output": {
>>>> Â Â Â Â Â Â Â "author-email": [
>>>> "draft-ietf-mpls-static-yang@ietf.org",
>>>> "draft-ietf-mpls-base-yang@ietf.org",
>>>> "draft-ietf-ospf-sr-yang@ietf.org",
>>>> "draft-ietf-pim-yang@ietf.org",
>>>> "draft-ietf-bier-bier-yang@ietf.org",
>>>> "draft-zhang-bier-te-yang@ietf.org",
>>>> "draft-ietf-isis-yang-isis-cfg@ietf.org",
>>>> "draft-ietf-teas-yang-rsvp-te@ietf.org",
>>>> "draft-ietf-mpls-mldp-yang@ietf.org",
>>>> "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
>>>> "draft-ietf-isis-sr-yang@ietf.org",
>>>> "draft-acee-rtgwg-yang-rib-extend@ietf.org",
>>>> "draft-ietf-pim-igmp-mld-yang@ietf.org",
>>>> "draft-ietf-i2rs-fb-rib-data-model@ietf.org",
>>>> "draft-ietf-ospf-yang@ietf.org",
>>>> "draft-ietf-rtgwg-yang-rip@ietf.org",
>>>> "draft-ietf-spring-sr-yang@ietf.org",
>>>> "draft-ietf-teas-yang-rsvp@ietf.org",
>>>> "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
>>>> "draft-ietf-mpls-ldp-yang@ietf.org",
>>>> "draft-ietf-bfd-yang@ietf.org",
>>>> "draft-ietf-pim-msdp-yang@ietf.org"
>>>> Â Â Â Â Â Â Â ]
>>>> Â Â Â }
>>>> }
>>>>
>>>> Fortunately, we only deal with IETF dependent YANG modules in case
>>>> of the ietf-routing. That's an easier case.
>>>> If we would change ietf-interfaces to ietf-interfaces-2, we would
>>>> have an cross SDO issue ... Btw, there are no automatic ways to
>>>> extract the authors of YANG modules from different SDOs: it's only
>>>> a metadata that that the different SDOs should insert in the
>>>> yangcatalog. So we would have to rely on liaisons or direct emails,
>>>> assuming we know the authors. Time consuming, believe me.
>>>>
>>>> Regards, Benoit
>>>>> Hi,
>>>>>
>>>>> Â Â Â As part of the my Routing Directorate review of
>>>>> draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
>>>>> changes being made to the ietf-l3vpn-svc module without changing the
>>>>> name. I raised this with the YANG doctors and others involved with the
>>>>> draft and it surfaced some topics which really should be discussed here
>>>>> in NetMod.
>>>>>
>>>>> The background (as explained off-list by others, so I hope I have it
>>>>> right)Â is that one of the YANG Doctors noted that RFC8049 was broken
>>>>> and could not be implemented as defined, and therefore a fix was
>>>>> needed. L3SM has concluded so the fix is in the individual draft
>>>>> draft-wu-l3sm-rfc8049bis. Since the rfc8049 version of ietf-l3vpn-svc
>>>>> module could not be implemented, the feeling by the YANG Dr was that
>>>>> even though the new module is incompatible with the original definition
>>>>> the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
>>>>> RFC 6020) didn't have to be followed and the same name could be used.
>>>>>
>>>>> In the subsequent discussion with the YANG Drs., the general discussion
>>>>> was heading down the path of using a new module name, and thereby not
>>>>> violating YANG module update rules. This lead us back to the a similar
>>>>> discussion we've been having in the context of 8022bis: how best to
>>>>> indicate that a whole module is being obsoleted. RFCs do this by adding
>>>>> 'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
>>>>> help YANG tooling. For 8022, we have one approach - publishing an
>>>>> updated rev of the original module marking all nodes as deprecated - but
>>>>> that doesn't really make sense for rfc8049bis.
>>>>>
>>>>> So the discussion for the WG is:
>>>>>
>>>>> How do we handle incompatible module changes, notably when one module
>>>>> 'obsoletes' another module --Â from both the process and tooling
>>>>> perspectives?
>>>>>
>>>>> I know Benoit plans to bring in some thoughts/proposals, perhaps there
>>>>> are others.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Lou
>>>>>
>>>>> (as contributor/reviewer)
>>>>>
>>>>>
>>>>>
>>>>>
>>
>
--------------8089E1673C08B81B6A9250AA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
Dear all,
Let me present this draft https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
New YANG Module Update Procedure
draft-clacla-netmod-yang-model-update-01
Abstract
This document specifies a new YANG module update procedure in case of
non backward-compatible changes, as an alternative proposal to the
YANG 1.1 specifications. This document updates RFC 7950.
Problem statement:
Changing a YANG module name each time there is a non backward
compatible change (as RFC7950 requires) adds a lot of complexity
to automation, from an import and service composition point of
view.
Solution:
We need a different mechanism. The solution in the draft is based
on the semantic versioning YANG extension: it was proposed
openconfig in the past and is currently used by the openconfig
YANG modules
Note: there might other solutions, such as new YANG keywords, but
at this point in time, it's important to recognize that we need to
change the way we produce YANG modules at the IETF. Let's discuss
on the list and during the NETMOD meeting.
Regards, Benoit.
On 10/12/2017 3:30 PM, Benoit Claise
wrote:
Hi Lou,
So circling
back to the original question: what do we do about the
non backward-compatible module being defined in
rfc8049bis?
While being
sympathetic to many of the comments made below as well
as the "do over" concept, I find the comments about
adhering to the rules of 7950 compelling - which leads
to renaming the module in the bis to ietf-l3vpn-svc-2.
It would be
good to ensure that this is the consensus of the group
before asking the authors make this change.
Since this draft is AD sponsored, I'll evaluate the consensus on
RFC8049bis.
Moving to ietf-l3vpn-svc-2 is the easy path not to break
backward compatibility. However, since ietf-l3vpn-svc is
unimplementable (it has broken XPATH expressions, so a compliant
implementation is impossible), so technically, ietf-l3vpn-svc
does not even exist.
See my message on this topic, as the IETF LC follow up.
  Â
https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
If a follow up is required, I propose that we use a single public
email thread: the ietf@ietf.org
Regards, Benoit
What NETMOD should focus on is closing on the NMDA transition:
the ietf-routing versus ietf-routing-2 issue.
Way bigger impact in terms of dependent YANG modules
Regards, Benoit (as OPS AD)
See below.
This change
course doesn't solve the versioning issue discussed
below, but this is not a new issue it's just the first
time we'll actually executing the steps envisioned as
part of the rules laid out in yang. My personal take
away is that means that we should immediately start work
on an extension defining along the lines of ' obsolete|update'
mentioned below.
I believe that option 1 is the more pragmatic and complete
solution. option 2 is just half a step in the right direction.
I believe we should discuss this topic in Singapore.
Regards, Benoit (as individual contributor)
Lou
On October 8, 2017
10:59:15 AM Benoit Claise <bclaise@cisco.com>
wrote:
Dear all,
Focusing on draft-wu-l3sm-rfc8049bis, the big problem
is: RFC8049 is broken. The small problem is: trying to
maintain backward compatibility.
draft-wu-l3sm-rfc8049bis has rightly focused on the
big problem.
Let me extend the scope of this email thread from
"handling module incompatibility" to "handling module
incompatibility and NMDA transition".
As I mentioned in the past (see "semver.org comparison
of two YANG modules" email in NETMOD), I believe the
IETF will have to change its way of working in terms
of backward compatibility. See also the email
"ietf-routing or ietf-routing-2? module naming
convention for NMDA transition. Re: [netmod] upcoming
adoptions" in NETMOD.
However, we will have to tackle this discussion one
day or the other:
- we need an automatic way to make the link
between the YANG module in RFC8049 and the YANG module
in draft-wu-l3sm-rfc8049bis, or any non backward
compatible YANG modules.
- we need an automatic way to make the link
between the YANG module in RFC8022 and the YANG module
in draft-acee-netmod-rfc8022bis, or any new YANG
module names used for NMDA transition.
Note: actually, we face two different problems.
draft-wu-l3sm-rfc8049bis might be declared backward
incompatible with RFC8049, while RFC8022bis is
backward compatible with RFC8022. The RFC8022bis went
for a new YANG module name ietf-routing-2 to avoid to
document the -state tree (as deprecated), based on the
argument that ietf-routing is not yet implemented.
Which solutions do we have from here?
#1. We keep the same module name and express that the
YANG module in draft-wu-l3sm-rfc8049bis is not
backward compatible with the RFC8049 one. This is the
openconfig way. See draft-clacla-netmod-model-catalog
(and draft-openconfig-netmod-model-catalog before)
// extension statements
extension openconfig-version {
argument "semver" {
yin-element false;
}
description
"The OpenConfig version number for the module. This is
expressed as a semantic version number of the form:
x.y.z
where:
* x corresponds to the major version,
* y corresponds to a minor version,
* z corresponds to a patch version.
This version corresponds to the model file within which it is
defined, and does not cover the whole set of OpenConfig models.
Where several modules are used to build up a single block of
functionality, the same module version is specified across each
file that makes up the module.
A major version number of 0 indicates that this model is still
in development (whether within OpenConfig or with industry
partners), and is potentially subject to change.
Following a release of major version 1, all modules will
increment major revision number where backwards incompatible
changes to the model are made.
The minor version is changed when features are added to the
model that do not impact current clients use of the model.
The patch-level version is incremented when non-feature changes
(such as bugfixes or clarifications to human-readable
descriptions that do not impact model functionality) are made
that maintain backwards compatibility.
The version number is stored in the module meta-data.";
}
Similarly, we always keep the same YANG module name in
case of NMDA transition. So ietf-routing-2 should be
changed back to ietf-routing.
The email thread "[Rtg-dt-yang-arch] ietf-routing or
ietf-routing-2? module naming convention for NMDA
transition. Re: [netmod] upcoming adoptions" seems to
go in that direction.
#2. Or we have a different module name, let's say
ietf-l3vpn-svc-2 or ietf-routing-2 but then, how do we
make the link with the previous module?
Then ... What? We create extension that will link the
draft-wu-l3sm-rfc8049bis YANG module to the RFC8049
YANG module? Same principle as #1, but just more
complex.
Or we have a new YANG keyword (this implies YANG 2.0)
<CODE BEGINS>file "ietf-l3vpn-svc@2017-09-14.yang"
module ietf-l3vpn-svc-2 {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-l3vpn-svc";
prefix l3vpn-svc;
obsolete|update ietf-l3vpn-svc@2017-01-2
And whose responsibility is this to warn/push all
authors of ietf-routing YANG modules to move to
ietf-routing-2? (*)
The following are non solution IMO:
- Going from the draft-wu-l3sm-rfc8049bis YANG module
to the draft-wu-l3sm-rfc8049bis document to
lookup the IETF "obsolete" flag in order to understand
that the RFC8049 YANG module is obsolete is not an
automatic solution.
- Using the yangcatalog.org might be a solution as we
track the derived semantic, but this is just an
offline trick. This is not what I call "automatic way"
- Using the YANG module description field might be
interesting, but again this is not an "automatic way":
description
"This YANG module defines a generic service configuration
model for Layer 3 VPNs. This model is common across all
vendor implementations. This obsoletes the RFC8049 YANG
module, ietf-l3vpn-svc@2017-01-2";
revision 2017-09-14 {
description
"First revision of RFC8049.";
reference
"RFC xxxx: YANG Data Model for L3VPN Service Delivery";
In conclusion, I believe openconfig got this right and
that solution #1 is the solution to go ... while
waiting for a new YANG keyword in YANG 2.0
(*) If you want to change the module from ietf-routing
to ietf-routing-2, then you should follow with all
authors of dependent modules to make sure they
transition to ietf-routing-2
In the yangcatalog.org, because I needed the
information as OPS AD, we created a small script to
get that authors list for IETF drafts. For the
ietf-routing, this produces the following
{
   "output": {
       "author-email": [
           "draft-ietf-mpls-static-yang@ietf.org",
           "draft-ietf-mpls-base-yang@ietf.org",
           "draft-ietf-ospf-sr-yang@ietf.org",
           "draft-ietf-pim-yang@ietf.org",
           "draft-ietf-bier-bier-yang@ietf.org",
           "draft-zhang-bier-te-yang@ietf.org",
           "draft-ietf-isis-yang-isis-cfg@ietf.org",
           "draft-ietf-teas-yang-rsvp-te@ietf.org",
           "draft-ietf-mpls-mldp-yang@ietf.org",
           "draft-zhao-pim-igmp-mld-snooping-yang@ietf.org",
           "draft-ietf-isis-sr-yang@ietf.org",
           "draft-acee-rtgwg-yang-rib-extend@ietf.org",
           "draft-ietf-pim-igmp-mld-yang@ietf.org",
           "draft-ietf-i2rs-fb-rib-data-model@ietf.org",
           "draft-ietf-ospf-yang@ietf.org",
           "draft-ietf-rtgwg-yang-rip@ietf.org",
           "draft-ietf-spring-sr-yang@ietf.org",
           "draft-ietf-teas-yang-rsvp@ietf.org",
           "draft-ietf-i2rs-pkt-eca-data-model@ietf.org",
           "draft-ietf-mpls-ldp-yang@ietf.org",
           "draft-ietf-bfd-yang@ietf.org",
           "draft-ietf-pim-msdp-yang@ietf.org"
       ]
   }
}
Fortunately, we only deal with IETF dependent YANG
modules in case of the ietf-routing. That's an easier
case.
If we would change ietf-interfaces to
ietf-interfaces-2, we would have an cross SDO issue
... Btw, there are no automatic ways to extract the
authors of YANG modules from different SDOs: it's only
a metadata that that the different SDOs should insert
in the yangcatalog. So we would have to rely on
liaisons or direct emails, assuming we know the
authors. Time consuming, believe me.
Regards, Benoit
Hi,
   As part of the my Routing Directorate review of
draft-wu-l3sm-rfc8049bis I noted that there were several incompatible
changes being made to the ietf-l3vpn-svc module without changing the
name. I raised this with the YANG doctors and others involved with the
draft and it surfaced some topics which really should be discussed here
in NetMod.
The background (as explained off-list by others, so I hope I have it
right)Â is that one of the YANG Doctors noted that RFC8049 was broken
and could not be implemented as defined, and therefore a fix was
needed. L3SM has concluded so the fix is in the individual draft
draft-wu-l3sm-rfc8049bis. Since the rfc8049 version of ietf-l3vpn-svc
module could not be implemented, the feeling by the YANG Dr was that
even though the new module is incompatible with the original definition
the module the rule defined in Section 11 of YANG 1.1 (or section 10 of
RFC 6020) didn't have to be followed and the same name could be used.
In the subsequent discussion with the YANG Drs., the general discussion
was heading down the path of using a new module name, and thereby not
violating YANG module update rules. This lead us back to the a similar
discussion we've been having in the context of 8022bis: how best to
indicate that a whole module is being obsoleted. RFCs do this by adding
'metadata' to the headers, e.g., "Obsoletes: 8049", but this doesn't
help YANG tooling. For 8022, we have one approach - publishing an
updated rev of the original module marking all nodes as deprecated - but
that doesn't really make sense for rfc8049bis.
So the discussion for the WG is:
How do we handle incompatible module changes, notably when one module
'obsoletes' another module --Â from both the process and tooling
perspectives?
I know Benoit plans to bring in some thoughts/proposals, perhaps there
are others.
Cheers,
Lou
(as contributor/reviewer)
--------------8089E1673C08B81B6A9250AA--
From nobody Sat Nov 4 14:20:05 2017
Return-Path:
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6395913FB6C; Sat, 4 Nov 2017 14:19:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joel Halpern
To:
Cc: draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.64.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150983039829.26601.3109842491855567125@ietfa.amsl.com>
Date: Sat, 04 Nov 2017 14:19:58 -0700
Archived-At:
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sat, 04 Nov 2017 21:19:58 -0000
Reviewer: Joel Halpern
Review result: Not Ready
This is a routing directorate early review. It is intended to assist the
working group and the routing ADs in processing the advancing document.
This document is nearly ready for publication as a Proposed Standard RFC.
Isses:
Major: N/A
Moderate:
Please address the issues reported by id-nits. Specifically, repair the
abstract and add an explicit reference to RFC 2119
Please add an informative reference to draft-ietf-rtgwg-dst-src-routing
indicating the the routing policy described here aligns with the ongoing work
in the routing area for how to handle source specific routes. This could be
added in section 4.
The base Babel (bis) specification does not talk about the handling of
duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on a given
destination prefix advertisement? Please indicate what the intended /
permitted handling is in the text.
Minor:
As far as I can tell, the behavior described in section 3.1 for 0/0 source
addresses and their relationship to routes without source addresses is correct
and matches draft-ietf-rtgwg-dst-src-routing. However, the wording is
sufficiently different as to cause this reader to wonder about it. If
practical consider additional wording to make the alignment clear. This would
seem to apply to 3.2 as well. The most obvious fix is to say that a Babel node
supporting this extensions treats all advertisements received without a source
specific prefix as if they had the 0/0 source prefix? (The text in section 5.2
says this. I would like to see it in section 3.1)
From nobody Wed Nov 8 07:04:55 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058D41275C5; Wed, 8 Nov 2017 07:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8AldrNx0MXt; Wed, 8 Nov 2017 07:04:46 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3AAC126557; Wed, 8 Nov 2017 07:04:45 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA8F4hbG006905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Nov 2017 16:04:43 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA8F4hPD022175; Wed, 8 Nov 2017 16:04:43 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 49FCEEB259; Wed, 8 Nov 2017 16:04:43 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id w5A8geeJmKDr; Wed, 8 Nov 2017 16:04:37 +0100 (CET)
Received: from mac-matthieu.lan (AAubervilliers-652-1-188-235.w86-218.abo.wanadoo.fr [86.218.75.235]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id EDAD0EB216; Wed, 8 Nov 2017 16:04:36 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Matthieu Boutier
In-Reply-To: <150983039829.26601.3109842491855567125@ietfa.amsl.com>
Date: Wed, 8 Nov 2017 16:04:35 +0100
Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com>
To: Joel Halpern
X-Mailer: Apple Mail (2.3445.4.7)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Wed, 08 Nov 2017 16:04:43 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Wed, 08 Nov 2017 16:04:43 +0100 (CET)
X-Miltered: at korolev with ID 5A031D0B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A031D0B.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A031D0B.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A031D0B.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 5A031D0B.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A031D0B.002 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At:
Subject: Re: [RTG-DIR] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 08 Nov 2017 15:04:48 -0000
Hi,
Thank's a lot for this early review.
> Please address the issues reported by id-nits.
Please accept my apologizes about these nits.
> The base Babel (bis) specification does not talk about the handling of
> duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on =
a given
> destination prefix advertisement?
I believe it is clear that a Babel node MUST NOT send two Source Prefix =
sub-TLVs
in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I =
hesitate:
does a node SHOULD or MUST ignore the whole TLV?
Does the list have an opinion?
Matthieu
From nobody Wed Nov 8 16:19:28 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B956B129421; Wed, 8 Nov 2017 16:19:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eNTIK_UvKjz; Wed, 8 Nov 2017 16:19:21 -0800 (PST)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5686012778E; Wed, 8 Nov 2017 16:19:21 -0800 (PST)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1510186752; bh=y0xkGrNDrHtWAGuQnmpUWCWdoRm+uU24ZTLx12Gy1oI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MPAcVpVw45qf2BYcXx6LyBLQvbM7YguXAeZf9dYoxgL7ejk2Qiu5pii8fD0ahefZo Syzw4HcFZGmOVbLVIRTdaWoClnBvF07PHkhTOna9045yGOAKxXeDM+syKOeJA519ww wMYwpjMBYJSM+YCV4xb6GwegVPjlwnqOQwZWfZCcGrUwO7WVhmESeyPXYliA8DUYnH gAtwOShJiRxVE7fuJv88KNL4nHJmvO611AgDFfGY+7SojPU2UctG8eCNE3Kdc5ZDCB 5aLOO//5Ld+4+FRlgK3ceh1tpyDXVQNfdeFympgRZ3NIfy6IdeNkiwyT+wNN7buv7x b0myW+xkRekww==
To: Matthieu Boutier , Joel Halpern
Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
In-Reply-To: <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr>
Date: Thu, 09 Nov 2017 09:18:55 +0900
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87po8sqp74.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At:
Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Nov 2017 00:19:22 -0000
Matthieu Boutier writes:
> Hi,
>
> Thank's a lot for this early review.
>
>> Please address the issues reported by id-nits.
>
> Please accept my apologizes about these nits.
>
>> The base Babel (bis) specification does not talk about the handling of
>> duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed on a given
>> destination prefix advertisement?
>
> I believe it is clear that a Babel node MUST NOT send two Source Prefix sub-TLVs
> in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I hesitate:
> does a node SHOULD or MUST ignore the whole TLV?
>
> Does the list have an opinion?
Off the top of my head: Ignore the whole thing; better to fail
(preferably loudly) than carry on with ambiguous semantics.
-Toke
From nobody Wed Nov 8 16:44:53 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67C129478 for ; Wed, 8 Nov 2017 16:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3IkVAHNvA9U for ; Wed, 8 Nov 2017 16:44:49 -0800 (PST)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B59912941D for ; Wed, 8 Nov 2017 16:44:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1510188289; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uoHAtRgbWJpUOlYhbuEM5j8vmvFFzCvqYFzjmPssmwI=; b=KwHvz1KScC31EpXBs4qsXPNTpJd2vRSVuYICQ1I0SkW1MMugXviq4ZODPzAXG2WH yY4MO5gMjbKV77CwwDgh9V/ST56wc3GPoGMGMbkJwEWhr5Ntfz737eIiZ9r11APL cD2vLjR6XoGwIUVwbti269esjlVeTrt0qpB7w0mdZuuvHBPYTi7WKSEKv1Sue8Dl Fe5U9ftWBh3lopkKAlahHtoM5MACPIyPDapdRs3JE2w0UMGSpeO7CANW9GsUuwXP 7We+9ve4eWJ5iM43uv4ZFgpVMVXBDWsamFVtbZdY2FjsaHRshMxt2zruu0lsofyJ v6Ymrnyr2SAcuZ9AbUi4ig==;
Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id CC.80.16042.105A30A5; Wed, 8 Nov 2017 16:44:49 -0800 (PST)
X-AuditID: 11973e12-355ff70000003eaa-85-5a03a501192d
Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay3.apple.com (Apple SCV relay) with SMTP id C5.FC.23978.105A30A5; Wed, 8 Nov 2017 16:44:49 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)"
Received: from [17.226.23.83] (unknown [17.226.23.83]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OZ4004A9KQONI30@jimbu.apple.com>; Wed, 08 Nov 2017 16:44:48 -0800 (PST)
Sender: dschinazi@apple.com
From: David Schinazi
Message-id: <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com>
Date: Wed, 08 Nov 2017 16:44:48 -0800
In-reply-to: <87po8sqp74.fsf@toke.dk>
Cc: Matthieu Boutier , Joel Halpern , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?=
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk>
X-Mailer: Apple Mail (2.3445.1.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUi2FAYrMu4lDnK4PMKUYsti7pZLA5/aWSx eLbzJavFx1NvmCwWrHnKbrH1/Qp2BzaPJUt+Mnks3vKW0ePclO+MHlsOXWQLYInisklJzcks Sy3St0vgytj1ZQp7wYHYikvf5jE1MD4M7GLk5JAQMJE4t/I8WxcjF4eQwGomiUt/pjLBJBp6 DzBBJDYwSkx4vY4dJMErICjxY/I9FhCbWSBM4sfVq2C2kMBfRokZjeUgtrCAtETXhbusXYwc HGwCWhIH1hhBtNpIzD36kh2ixF/iwcupYK0sAqoS616eYwOxOYHsxVumMILsZRaYyyhxc/5q sAYRAXuJxq8XWCAO6mWUaPu9lQXiUkWJIzPnMIMkJAROsEm0HZzAPIFRaBaSY2chOXYW0FHM AuoSU6bkQoS1JZ68u8AKYatJLPy9iAlZfAEj2ypGodzEzBzdzDwTvcSCgpxUveT83E2MoEia bie0g/HUKqtDjAIcjEo8vBqKTFFCrIllxZW5hxilOViUxHlTXzFECQmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamD0DnZIWh4l+2zOJr3Pr3xu6Phbuc283D3Fduujx0f+/gx9pfou18ghWbir wX3CjCwV5XfJe6Mcn2t0hE7k6pz/yNuqM//ScTflliCx1spZFU9D/+TXNaVpH3lj9jRUtXDn 17f2lecLp7+ukP35RTr6Bdsr1akRhxjSlJ7v4p+VWPS4KIGJf64SS3FGoqEWc1FxIgBZXjj6 hQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUiON1OVZdxKXOUwY5lghZbFnWzWBz+0shi 8WznS1aLj6feMFksWPOU3WLr+xXsDmweS5b8ZPJYvOUto8e5Kd8ZPbYcusgWwBLFZZOSmpNZ llqkb5fAlbHryxT2ggOxFZe+zWNqYHwY2MXIySEhYCLR0HuAqYuRi0NIYAOjxITX69hBErwC ghI/Jt9jAbGZBcIkfly9CmYLCfxllJjRWA5iCwtIS3RduMvaxcjBwSagJXFgjRFEq43E3KMv 2SFK/CUevJwK1soioCqx7uU5NhCbE8hevGUKI8heZoG5jBI3568GaxARsJdo/HqBBeKgXkaJ tt9bWSAuVZQ4MnMO8wRG/llI7puF5L5ZQHcwC6hLTJmSCxHWlnjy7gIrhK0msfD3IiZk8QWM bKsYBYpScxIrjfUSCwpyUvWS83M3MYICv6EweAfjn2VWhxgFOBiVeHgvyDFFCbEmlhVX5h5i lOBgVhLhtc5kjhLiTUmsrEotyo8vKs1JLT7EKM3BoiTO25HBECUkkJ5YkpqdmlqQWgSTZeLg lGpg3BbLtqu28qty6YQche5I4/Pbp+ydPe9Kx/O6+SdOTNq1PWpynpBK8oE1Oa0ueY/D4+cZ nzh1dwkvw+YZnNIiCxiMVdsqG3+eXXffW3xJ8UK116dmmG+dVJ3CXSv4UGiWwe8Ll/9NbjbP 1BfK1zaY8i57X0G2u+hqrbIoxh8XZSZ+LD275rXlNiWW4oxEQy3mouJEAOE6OYh4AgAA
Archived-At:
Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Nov 2017 00:44:51 -0000
--Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: quoted-printable
$.02
Personally, if I receive something that the spec says you MUST NOT do I =
get upset at the packet.
Maybe I ignore the whole TLV, maybe the whole packet, maybe I summon the =
wrath of the Gods of the Internet.
If you expect that someone someday could find a use case for sending two =
sub-TLVs,
then I'd recommend explicitly saying MUST NOT send and on receive MUST =
drop TLV but not packet.
If you don't expect this to ever be useful, no need to specify it.
David
> On Nov 8, 2017, at 16:18, Toke H=C3=B8iland-J=C3=B8rgensen =
wrote:
>=20
> Matthieu Boutier > writes:
>=20
>> Hi,
>>=20
>> Thank's a lot for this early review.
>>=20
>>> Please address the issues reported by id-nits.
>>=20
>> Please accept my apologizes about these nits.
>>=20
>>> The base Babel (bis) specification does not talk about the handling =
of
>>> duplicate sub-TLVs. Are multiple source-specific sub-TLVs allowed =
on a given
>>> destination prefix advertisement?
>>=20
>> I believe it is clear that a Babel node MUST NOT send two Source =
Prefix sub-TLVs
>> in one TLV. But If a received TLV has two Source Prefix sub-TLVs, I =
hesitate:
>> does a node SHOULD or MUST ignore the whole TLV?
>>=20
>> Does the list have an opinion?
>=20
> Off the top of my head: Ignore the whole thing; better to fail
> (preferably loudly) than carry on with ambiguous semantics.
>=20
> -Toke
>=20
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel =
--Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: quoted-printable
$.02
Personally, if I receive something that the spec says you =
MUST NOT do I get upset at the packet.Maybe I ignore the =
whole TLV, maybe the whole packet, maybe I summon the wrath of the Gods =
of the Internet.
If you expect that =
someone someday could find a use case for sending two =
sub-TLVs,then I'd recommend explicitly saying MUST =
NOT send and on receive MUST drop TLV but not packet.If you don't expect this to ever be useful, no need to =
specify it.
David
On Nov =
8, 2017, at 16:18, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk> =
wrote:
Matthieu Boutier <boutier@irif.fr> writes:
Hi,
Thank's a lot for this early review.
Please address the =
issues reported by id-nits.
Please accept my apologizes about these nits.
The base Babel (bis) =
specification does not talk about the handling of
duplicate =
sub-TLVs. Are multiple source-specific sub-TLVs allowed on a =
given
destination prefix advertisement?
I believe it is clear that a =
Babel node MUST NOT send two Source Prefix sub-TLVs
in one =
TLV. But If a received TLV has two Source Prefix sub-TLVs, I =
hesitate:
does a node SHOULD or MUST ignore the whole =
TLV?
Does the list have an opinion?
Off the top of my head: Ignore the whole =
thing; better to fail
(preferably loudly) than carry =
on with ambiguous semantics.
-Toke
_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
=
--Boundary_(ID_nT3nJuQVj0GwWG7MLX52sg)--
From nobody Thu Nov 9 05:48:37 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC51200F1; Thu, 9 Nov 2017 05:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwyRYDTaArvB; Thu, 9 Nov 2017 05:48:29 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF963120046; Thu, 9 Nov 2017 05:48:28 -0800 (PST)
Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vA9DmLvU020057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Nov 2017 14:48:23 +0100
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/75695) with ESMTP id vA9DmKiF008352; Thu, 9 Nov 2017 14:48:20 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A56C3EB21F; Thu, 9 Nov 2017 14:48:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 9EcWhBS8LX1H; Thu, 9 Nov 2017 14:48:19 +0100 (CET)
Received: from host-37-32.sg.lan (unknown [172.23.37.32]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 7DDA6EB364; Thu, 9 Nov 2017 14:48:18 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Matthieu Boutier
In-Reply-To: <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com>
Date: Thu, 9 Nov 2017 14:48:18 +0100
Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Joel Halpern , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com>
To: David Schinazi
X-Mailer: Apple Mail (2.3445.4.7)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Thu, 09 Nov 2017 14:48:23 +0100 (CET)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Thu, 09 Nov 2017 14:48:21 +0100 (CET)
X-Miltered: at korolev with ID 5A045CA5.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-Miltered: at potemkin with ID 5A045CA4.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A045CA5.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/
X-j-chkmail-Enveloppe: 5A045CA4.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 5A045CA5.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Score: MSGID : 5A045CA4.003 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
X-j-chkmail-Status: Ham
Archived-At:
Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Nov 2017 13:48:31 -0000
> maybe I summon the wrath of the Gods of the Internet.
Hey! What's the protocol for that? :p
> If you don't expect this to ever be useful, no need to specify it.
Looks good for me, does something like the following make sense? Should =
we
recommend something?
A node does not expect to receive any TLV with two Source Prefix =
sub-TLVs or
more. Whenever that occurs, the behaviour is undefined: an =
implementation
may drop the whole packet, the whole TLV or consider only just one =
of the
sub-TLVs (this can be the case if the implementation does not check =
if
multiple sub-TLVs are sent).
Toke, would you like to see: "It is recommended to ignore the whole =
packet".
(lower case "recommended")
Matthieu
From nobody Thu Nov 9 05:54:18 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7F120046; Thu, 9 Nov 2017 05:54:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv-lpA_KlNcu; Thu, 9 Nov 2017 05:54:14 -0800 (PST)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A489126BFD; Thu, 9 Nov 2017 05:54:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 7CA74245B71; Thu, 9 Nov 2017 05:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1510235654; bh=vbukJqV+FOdoPoMCeqXBzhvbwi8aQNWnJWNRJTLAd6g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TCwlAO4sFHGRP2F/wocXyPZF4gf7dr7Cn93UV1fSfgK7xzvdMi6mnoqxPfCrnUJog Ke4LH9ZnSQ6KDobYJU6UlFNUO0YnKNJmQKIMNhZbWFf4sTtgSWzC3NJWzkkeS/Zu2O R59yULyXqm9qiX+RJQmgva6hsjB56ETRhCmW/b2w=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id E0C56240E4E; Thu, 9 Nov 2017 05:54:12 -0800 (PST)
To: Matthieu Boutier , David Schinazi
Cc: rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, =?UTF-8?Q?Toke_H=c3=b8iland-J=c3=b8rgensen?= , babel@ietf.org, Joel Halpern
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
From: "Joel M. Halpern"
Message-ID:
Date: Thu, 9 Nov 2017 08:54:12 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At:
Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Thu, 09 Nov 2017 13:54:16 -0000
Being a little bit picky here:
Could you also add a sentence in section 7.1 stating explicitly that
only one source specific prefix is permitted in a TLV? I realize this
is implied by the use of "a source prefix" in section 5.1. I think it
would help to be explicit.
If the sending side restriction is made explicit, then the text you
propose for the receiving side is acceptable, although I would
personally prefer that it used an upper case SHOULD for ignoring the
whole TLV. This preference is driven by a desire for robustness and
predictability in interoperation.
Yours,
Joel
On 11/9/17 8:48 AM, Matthieu Boutier wrote:
>> maybe I summon the wrath of the Gods of the Internet.
>
> Hey! What's the protocol for that? :p
>
>> If you don't expect this to ever be useful, no need to specify it.
>
> Looks good for me, does something like the following make sense? Should we
> recommend something?
>
> A node does not expect to receive any TLV with two Source Prefix sub-TLVs or
> more. Whenever that occurs, the behaviour is undefined: an implementation
> may drop the whole packet, the whole TLV or consider only just one of the
> sub-TLVs (this can be the case if the implementation does not check if
> multiple sub-TLVs are sent).
>
> Toke, would you like to see: "It is recommended to ignore the whole packet".
> (lower case "recommended")
>
> Matthieu
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>
From nobody Sun Nov 12 08:50:09 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3A312945D; Sun, 12 Nov 2017 08:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level:
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQneIxGAnSrj; Sun, 12 Nov 2017 08:50:06 -0800 (PST)
Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465501200F3; Sun, 12 Nov 2017 08:50:06 -0800 (PST)
Received: from [193.109.255.99] by server-9.bemta-6.messagelabs.com id BE/82-30115-CBB780A5; Sun, 12 Nov 2017 16:50:04 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUgTYRzHe+5u2xW7uGbLn0v/cBaR6TASUch ahSBY9PKHlZR2q2tbbaftZlhBLchaamX2ujKcaMNqf6QZRa2IUSPFMswkxaXhC6VI9l5mL3e7 WXZ/HJ/n9/19v8/veXhIXNUq15BskZ21cYxFK59GJMfqNyf69pE5SU5/VGrZsQWpTZXf8FS3d 0ChxzNra79jmY86L+FrsByZmTPkF22Rma69/CkvuDG7qPVSO3KgPihB00iCPoxDWSBIiAsVXY FBzWh7eNGLoG2kGitBU0k5nQ4N14JykWfSuTDW+FomMk6vhdKGywqRI2g1FA+2CEwKPRq4d3W W1K4D71gfLjJBz4WLrV9DTNGbYMhzKhSD6FnwtdmLSZGR0NVfFWKgaaj1teISq+Ft369wvwF6 BqqRVI+F868qFRLHQFtVKRLnB9qvgLqGgXCQDm6eHAkbVoG3pEsuzgl0HDS+2Sz1exB0PHTIp Z54aBnvD3t3QofzftibBW7PmEIyBGUw/vuFTBKi4en7HkISnsng81lXyK2it8Ljyo+EdEMaCL YfRRJHw5vue7JyNP/CpFNLzMGDugBxIXRLM6DJ1U9I9QRw3/0gl3gBeKqH8QluedCHTa67keI qmseztt2sLXGRzmAzG012K2O2JC5MStFZWZ5njKyFMfC6rfnWBiQ8qCnCdxs5fy33oygS06qp OR8VOarphvxte0wMb8qzFVpY3o+iSVILFLeXzFHNsLFGtmi72SK8ygkZSKV2JqXeI8gUX8BYe bNRkppRGnm9MziOkfdD/0HXsANXEVw+x2oiqXQxjxYNpkLub9zEO29DMZoICgkDqpQFrM1qtv +vD6FIEmkjqICYojRz9r+7DgkDYcJAGvEsFG9n/kkaB6pKOJG9utG1osvtSqgbKV18PvnMgXX OJ1kVK9cXLI0IeEY/LRqsziiueD6acdBV4QvuvzN4a1vSklv1afquEn/k8TW7jM5ngaUbj5zJ UPb4NsRdeZeXcpHz7lsVm5ex0lA+nK3vrXnvz526P/f0i2U7zOqRL+WHzn3wKX/ExQTqu3eWa QnexCyMx2088wcUKe+I4gMAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-12.tower-48.messagelabs.com!1510505401!80864235!1
X-Originating-IP: [52.33.64.93]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 19688 invoked from network); 12 Nov 2017 16:50:03 -0000
Received: from ec2-52-33-64-93.us-west-2.compute.amazonaws.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-12.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Nov 2017 16:50:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hxdEb7l2iTtjnkukrR/+KrW2gOjTPF91Skd5U/E7J5U=; b=XX9pW3EyWsHz/+o2eDm8e3PRpdBJQJuRL0obmVl1cjarjriGPhHDlnwLfjOHap/SGxRpR89/dQy/XSXNtooAEQ1uhNzOrBrE1nz7kc3bKx1lruAF1t8jj/QdTVo8BruU0Zb1m13y5NvFwJWz1P3k2f+2QGuX8UvA+xQAJpcSRrk=
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com (10.167.88.15) by AM4PR03MB1714.eurprd03.prod.outlook.com (10.167.88.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sun, 12 Nov 2017 16:49:59 +0000
Received: from AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216]) by AM4PR03MB1713.eurprd03.prod.outlook.com ([fe80::3dd6:85df:7ee8:2216%13]) with mapi id 15.20.0197.017; Sun, 12 Nov 2017 16:49:59 +0000
From: Alexander Vainshtein
To: "Jonathan Hardwick (Jonathan.Hardwick@metaswitch.com)"
CC: "rtg-dir@ietf.org" , "rtg-ads@ietf.org"
Thread-Topic: My vacation
Thread-Index: AdNb1eSA1mnpI1H0SDm9ty2JKsn0IQ==
Date: Sun, 12 Nov 2017 16:49:59 +0000
Message-ID:
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR03MB1714; 6:o31eBVmhj4K6wpS/I/mRrZXeb17eQZjeK/4g4EJnyexoyab5ftjX0zhreEDnn4hBwqmQrz0zD8TYCZC15u04t3YMfVFYSZ0XcM2h4LRwvcZCi8+wfBxQjic4sQ6tfZEOtrK4XT3Sgp1xuBB520G9DBSHIOaKFZRoG2pr1GX+6YpZDwXctyugcPlG38QrL5sQKglFQtXykHVeBILYIY0lJqSoFBkCoQb88cTMPHAz+hhx1XAygIrN2kcHRADOVDpdB1hpzAvUoEdpx/r2/wKQMlDZrEsdth4x92/3+Q/cHhG6KVeeEJ94F+NoSbj946ve9NuhPgqHEnb6C3KU1mYNwM3fFUd47GSkUligDLZ+bMY=; 5:I+cbyedyy1vvFlDVWhOaHmE3ImoG6bY0RZwa10PVdCkcNCYejEDuBFtHjkw6mdXgtIM9n+jpvB54Hl0KTZcnRNpvLeaWpTIey+6ox0qNL3my6Iee5JSwXq9G1tH7ViXChKnBPQP00EHH88zYRfgDtsCnvx7iSZBb6T6yUHYAnl0=; 24:PUn60VESoo8P/aX/obUXjre4ng4csSH2jo/rZHTSrGdQXuhjOzZ4Xu5+c8k8udqjlxtBqNqwPID0bhh0m3dIJf7u4bxAJ4r94qLkZAViBo4=; 7:IAg09E2k/ZWIcDr53KdL0qOdlTsxj6cO+l8CFofWuizoDgstN0BFMb2sUxl8tea8ILaXauE154Zil9vemo/0Fxtx1JDRAgumrWrsn8ldUf/zi29Z7h3snPR2srCqR8O0lY22xV72+bWnHr2tWNr58koFl7CJNmEzv4ctrY71YSYsTWd56gylCVW7dyB29IGdlLMHjcbOqhDaKh8f2z2ZOf8XxJdYVIJes1glcHYIpufYr2p7y9UtMzC3cK0Wc7Kh
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: efa1f9f8-eea9-40c8-de3a-08d529ed699f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM4PR03MB1714;
x-ms-traffictypediagnostic: AM4PR03MB1714:
x-microsoft-antispam-prvs:
x-exchange-antispam-report-test: UriScan:(21748063052155)(279101305709854);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR03MB1714; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR03MB1714;
x-forefront-prvs: 0489CFBAC9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(189002)(37984002)(199003)(252514010)(81166006)(55016002)(54906003)(81156014)(189998001)(105586002)(5250100002)(50986999)(4743002)(8676002)(33656002)(316002)(54896002)(6306002)(74316002)(4326008)(7736002)(68736007)(9686003)(106356001)(54356999)(25786009)(8936002)(53936002)(66066001)(72206003)(5660300001)(97736004)(2906002)(6436002)(3480700004)(6116002)(6506006)(790700001)(3846002)(102836003)(3280700002)(101416001)(3660700001)(86362001)(7116003)(7696004)(2900100001)(6916009)(99286004)(14454004)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR03MB1714; H:AM4PR03MB1713.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: efa1f9f8-eea9-40c8-de3a-08d529ed699f
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 16:49:59.8240 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR03MB1714
X-CFilter-Loop: Reflected
Archived-At:
Subject: [RTG-DIR] My vacation
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Sun, 12 Nov 2017 16:50:08 -0000
--_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Jonathan, and all,
I will be on vacation in the US from 17-Nov-17 and until 10.12.17 (both da=
tes inclusive).
I will have only limited access to my email during this period and will no=
t be able to do any reviews for the RTG-DIR if the deadline is within or v=
ery close to this interval.
I apologize in advance for possible inconvenience.
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266302
Email: Alexander.Vainshtein@ecitele.com
__________________________________________________________________________=
_
This e-mail message is intended for the recipient only and contains inform=
ation which is=20
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece=
ived this=20
transmission in error, please inform us by e-mail, phone or fax, and then =
delete the original=20
and all copies thereof.
__________________________________________________________________________=
_
--_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Jonathan, and all,
I will be on vacation in the US from 17-Nov-17 and =
until 10.12.17 (both dates inclusive).
I will have only limited access to my email during =
this period and will not be able to do any reviews for the RTG-DIR if the =
deadline is within or very close to this interval.
I apologize in advance for possible inconvenience.<=
o:p>
Regards,
Sasha
Office: +972-39266302
Cell: +972-549266=
302
Email: Alexander.Vainshtein@ecitele.com=
__________________________________________________________________________=
_
This e-mail message is intended for the recipient only and contains inform=
ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece=
ived this
transmission in error, please inform us by e-mail, phone or fax, and then =
delete the original
and all copies thereof.
__________________________________________________________________________=
_
--_000_AM4PR03MB171397C518F0ED52933AEA3E9D2A0AM4PR03MB1713eurp_--
From nobody Tue Nov 14 21:55:26 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5041294F0 for ; Tue, 14 Nov 2017 21:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.846
X-Spam-Level: **
X-Spam-Status: No, score=2.846 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGUAtVVwlV0w for ; Tue, 14 Nov 2017 21:55:24 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F361243F6 for ; Tue, 14 Nov 2017 21:55:24 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.139.117;
From: "Susan Hares"
To:
Cc: "'Alexander Clemm'"
Date: Wed, 15 Nov 2017 00:55:19 -0500
Message-ID: <003c01d35dd6$53041f80$f90c5e80$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D35DAC.6A2F9E20"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdNd1fkVz82/QxsEQjq8nIetK5Gbwg==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At:
Subject: Re: [RTG-DIR] [RTG-DIR} Rtgdir early revie wof draft-ietf-i2rs-yang-l3-topology-10
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Nov 2017 05:55:26 -0000
This is a multipart message in MIME format.
------=_NextPart_000_003D_01D35DAC.6A2F9E20
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Chris:
Thank you for your review of:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/
found at:
https://mailarchive.ietf.org/arch/msg/rtg-dir/2ELh2F2UObsCRaCiCSKSPj-xevU
On your comments:
#1) The draft has an normative reference to the NMDA documents.
#2) The ISIS example has been removed .
Thank you for your comments.
Sue Hares
Draft shepherd
------=_NextPart_000_003D_01D35DAC.6A2F9E20
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Chris: =
Thank you for your review of:
=
p>
https://datatracker.ietf.org/doc/draft-ietf-i2rs-=
yang-l3-topology/
found at: =
https://mailarchive.ietf.org/arch/msg/rtg-dir/2ELh2F2UObsCRaCiCSKSP=
j-xevU
On your =
comments:
#1) The draft has an =
normative reference to the NMDA documents.
#2) The ISIS example has been removed . =
Thank you for your comments.
Sue Hares =
Draft =
shepherd
------=_NextPart_000_003D_01D35DAC.6A2F9E20--
From nobody Tue Nov 14 22:05:55 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25FE1294FF; Tue, 14 Nov 2017 22:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.845
X-Spam-Level: **
X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6BBRBcl8xR1; Tue, 14 Nov 2017 22:05:54 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B7B1294F8; Tue, 14 Nov 2017 22:05:53 -0800 (PST)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.139.117;
From: "Susan Hares"
To:
Cc: , "'Alexander Clemm'"
Date: Wed, 15 Nov 2017 01:05:48 -0500
Message-ID: <004c01d35dd7$ca7603c0$5f620b40$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01D35DAD.E1A1F790"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdNd1t3SuGoaFkPpRn60MdtlcaynJg==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At:
Subject: Re: [RTG-DIR] RtgDir Early review: draft-ietf-i2rs-yang-l3-topology
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 15 Nov 2017 06:05:54 -0000
This is a multipart message in MIME format.
------=_NextPart_000_004D_01D35DAD.E1A1F790
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Matt:
Your delightful review in July 19th, 2017 went unanswered. As the shepherd,
I apologize for the delay in responding to you. Thank you for the
complements for your draft.
Great minds think alike. Originally, this draft had ISIS, OSPF, and none
of your "useless" descriptions. It is satisfying that great-minds in the
RTG-DIR Think alike. I helps me know I'm not crazy.
Great minds think alike in the OPS area, but they do not think like RTG-DIR
people. The changes in this document are due to the recommendations by
Yang Doctors and NETMOD to add things that are expected by OPS-DIR. So. in
the interest of inter-Area harmony, I2RS compromised and added the
information.
Sue Hares
------=_NextPart_000_004D_01D35DAD.E1A1F790
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Matt:
Your =
delightful review in July 19th, 2017 went unanswered. =
As the shepherd, I apologize for the delay in responding to you. =
Thank you for the complements for your draft. =
Great minds think alike. Originally, this =
draft had ISIS, OSPF, and none of your “useless” =
descriptions. It is satisfying that great-minds in the =
RTG-DIR Think alike. I helps me know I’m not crazy. =
Great minds think alike in the OPS area, but they do =
not think like RTG-DIR people. The changes in this document =
are due to the recommendations by Yang Doctors and NETMOD to add things =
that are expected by OPS-DIR. So… in the interest of =
inter-Area harmony, I2RS compromised and added the information. =
Sue Hares
------=_NextPart_000_004D_01D35DAD.E1A1F790--
From nobody Tue Nov 21 00:16:56 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66E212773A; Tue, 21 Nov 2017 00:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxqxkaGYcexk; Tue, 21 Nov 2017 00:16:47 -0800 (PST)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1961293E0; Tue, 21 Nov 2017 00:16:47 -0800 (PST)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/75695) with ESMTP id vAL8GfDd011541; Tue, 21 Nov 2017 09:16:41 +0100
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 3C547EB217; Tue, 21 Nov 2017 09:16:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 6dVSJjskP84K; Tue, 21 Nov 2017 09:16:39 +0100 (CET)
Received: from mac-matthieu.lan (AAubervilliers-652-1-169-162.w86-218.abo.wanadoo.fr [86.218.8.162]) (Authenticated sender: boutier) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id A87FAEB216; Tue, 21 Nov 2017 09:16:37 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
From: Matthieu Boutier
In-Reply-To:
Date: Tue, 21 Nov 2017 09:16:36 +0100
Cc: David Schinazi , rtg-dir@ietf.org, draft-ietf-babel-source-specific.all@ietf.org, =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , babel@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id:
References: <150983039829.26601.3109842491855567125@ietfa.amsl.com> <5FA8E8AC-6BBB-45D0-BDF6-2241179A5477@irif.fr> <87po8sqp74.fsf@toke.dk> <804D8548-4A08-4A6E-84B8-6512DF29D402@apple.com> <59C08DBA-7C1E-4325-A0CC-82D7C89B28BC@irif.fr>
To: "Joel M. Halpern"
X-Mailer: Apple Mail (2.3445.4.7)
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Tue, 21 Nov 2017 09:16:42 +0100 (CET)
X-Miltered: at korolev with ID 5A13E0E9.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 5A13E0E9.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/
X-j-chkmail-Score: MSGID : 5A13E0E9.001 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At:
Subject: Re: [RTG-DIR] [babel] Rtgdir early review of draft-ietf-babel-source-specific-01
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 21 Nov 2017 08:16:50 -0000
> Being a little bit picky here:
All improvements are welcome! Thanks for the advices and explanations.
> Could you also add a sentence in section 7.1 stating explicitly that =
only one source specific prefix is permitted in a TLV?
I also rewrite the introduction of 7 to precise the behaviour when =
multiple or malformed sub-TLV are received.
Thanks for the feedback. This is pushed on the git =
(https://github.com/jech/babel-drafts).
Matthieu=
From nobody Wed Nov 22 01:12:44 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFAE120726; Wed, 22 Nov 2017 01:12:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level:
X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=metaswitch.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYxAN1fzkEeu; Wed, 22 Nov 2017 01:12:35 -0800 (PST)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0097.outbound.protection.outlook.com [104.47.38.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9315D124B09; Wed, 22 Nov 2017 01:12:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaswitch.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OpDO22C6nAa6f0dIrxTQ6hx8SXuXyc2qfNlPgXCdDb4=; b=ZViEnYfXqShKm66QYGk779+edLZHFjdel82qJsq4qWa3t5bhb6A2Zw/OhTsnE5A5CxcieAgHmcgHAq8hfCqoqGkxyCkaP+3WhJO4uS/4W23s72LtfgVssRhU2u316D0WRXxQ05YYFLby6PQFyBnDuNMDZr4aP0Ej72XThI94FW8=
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com (52.132.99.21) by CY4PR0201MB3604.namprd02.prod.outlook.com (52.132.99.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 22 Nov 2017 09:12:32 +0000
Received: from CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b]) by CY4PR0201MB3603.namprd02.prod.outlook.com ([fe80::2475:224a:642f:a02b%13]) with mapi id 15.20.0239.009; Wed, 22 Nov 2017 09:12:32 +0000
From: Jonathan Hardwick
To: "routing-discussion@ietf.org" , "rtg-chairs@ietf.org" , "rtg-dir@ietf.org" , "rtg-ads@ietf.org"
Thread-Topic: Routing area draft minutes available
Thread-Index: AdNjce2Dujszsli0T6WRrXLK1zsDGA==
Date: Wed, 22 Nov 2017 09:12:31 +0000
Message-ID:
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jonathan.Hardwick@metaswitch.com;
x-originating-ip: [86.132.73.252]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR0201MB3604; 6:CQpYr8YL/OL4ZZ1E0kTPwDob0YAzUsKoUU93b/+SIL0W+8gHLhw/65Jk28iKfhv9gd3AxsnZwvYAIU04nt2c6yy2IG0N+zD/s7k/o3GkMYG18OQT0sCOiKZP2T5+kVpTz53RdyC1Uq1LSOVef1udVQ737yjWROI984pCqrC6KPhO8pS7UqgwKYUYbn3XUMaMeKp4W7XCSY3UjMwoIqzuYk3VzX/Vi80OHeQFzxTTKtpBvFNk0eKIaAwXRIyEvNTkXZF9O7pUCY8Sz9gDNy7ga20apeJEVCTT69siDp4n14UvrNyUKneQtLPfbmAekDjhl6KkCqXdaefbRzK07m6k9hOYAdQylmAleFr45gRQs3Q=; 5:WTDBMcXG1MKJd1DlWlL1vKcf4VlDRXCGHkcBS843JgqMkdZMEaHrKnGsUB8Y0/o4wTgf0riH8lxlWMH1F35Xn62yYCkeoXmof5bNMiEZUBY6MPyX3Z66JQj19yswuslvVcfr1xphSlbOEsKJXTpP6G5MeaeNVBLg76gBHr/AN2w=; 24:Xy4+iXEphq8AwWZxduKAc1t1kC+OS7ICwEHV5tetd59lGGafxcMiol0BIq3KcMqzair91vNYCNWJ/9dsP3B52i/RJ47GatLEIacXc3rDW7I=; 7:2klxoGjlziJ6bFi4hEFKpxwHs3Mey/O3/Pk2VFHeZ4zUIa9noT1BO5mEG1IRImDkanEzYqyd03dtlD71pHzMzhgCVKHS1WHYfIj/hLmQEG/F/DbvLdjRoiJrD8i43xX6LEwQirrw/ta69vgq7x3XbZhgTUWQYw0vnVNtCiuJKncUUbCGdlUeE7dbmtHdxl22zQbfznhNu1LHQqhYjJooPjYBM4vyiEcifYDXdvj66tFnx95uEY/o6XMi5KtFjWlY
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 86dad48d-6594-4f66-4836-08d531892998
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR0201MB3604;
x-ms-traffictypediagnostic: CY4PR0201MB3604:
x-microsoft-antispam-prvs:
x-exchange-antispam-report-test: UriScan:(120809045254105)(227612066756510)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR0201MB3604; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR0201MB3604;
x-forefront-prvs: 0499DAF22A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(376002)(346002)(199003)(189002)(316002)(33656002)(110136005)(14454004)(86362001)(8936002)(97736004)(25786009)(6506006)(5660300001)(189998001)(106356001)(105586002)(966005)(7696004)(54896002)(53936002)(236005)(55016002)(68736007)(6306002)(6436002)(2900100001)(450100002)(72206003)(5250100002)(9686003)(478600001)(74316002)(3280700002)(99286004)(7736002)(790700001)(3846002)(6116002)(2201001)(102836003)(54356999)(50986999)(606006)(2906002)(101416001)(66066001)(81166006)(558084003)(81156014)(2501003)(8676002)(3660700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0201MB3604; H:CY4PR0201MB3603.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_"
MIME-Version: 1.0
X-OriginatorOrg: metaswitch.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 86dad48d-6594-4f66-4836-08d531892998
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 09:12:31.9982 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0201MB3604
Archived-At:
Subject: [RTG-DIR] Routing area draft minutes available
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Wed, 22 Nov 2017 09:12:37 -0000
--_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The draft minutes for the RTGAREA meeting at IETF 100 are now available. P=
lease let me know if you have any comments.
https://datatracker.ietf.org/doc/minutes-100-rtgarea/
Best regards
Jon
--_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The draft minutes for the RTGAREA meeting at IETF=
100 are now available. Please let me know if you have any comments.<=
o:p>
https://datatracker.ietf.org/doc/minutes-100-rtgarea/
Best regards
Jon
--_000_CY4PR0201MB360388C6F8C8693070E1181884200CY4PR0201MB3603_--
From nobody Tue Nov 28 03:10:33 2017
Return-Path:
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9BE127369; Tue, 28 Nov 2017 03:10:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Niven-Jenkins
To:
Cc: pce@ietf.org, draft-ietf-pce-pcep-exp-codepoints.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.66.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151186742816.13409.4274999012117883106@ietfa.amsl.com>
Date: Tue, 28 Nov 2017 03:10:28 -0800
Archived-At:
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Routing Area Directorate
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Tue, 28 Nov 2017 11:10:28 -0000
Reviewer: Ben Niven-Jenkins
Review result: Ready
RtgDir review: draft-ietf-pce-pcep-exp-codepoints-04
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to the Routing ADs.
For more information about the Routing Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
updating the draft.
Document: draft-ietf-pce-pcep-exp-codepoints-04
Reviewer: Ben Niven-Jenkins
Review Date: 28th November 2017
IETF LC End Date: Not known
Intended Status: Proposed Standard
Summary: No issues found. This document is ready for publication.
Comments: The document is well written and readable with clear guidance to IANA.
Major Issues: No major issues found.
Minor Issues: No minor issues found.
Regards
Ben
From nobody Tue Nov 28 03:12:15 2017
Return-Path:
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5466D126BF0; Tue, 28 Nov 2017 03:12:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88WJhJZ5OgZs; Tue, 28 Nov 2017 03:12:11 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BE81200F3; Tue, 28 Nov 2017 03:12:11 -0800 (PST)
Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 17CA8EDB53E4E; Tue, 28 Nov 2017 11:12:08 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 11:12:09 +0000
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.219]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 16:41:56 +0530
From: Dhruv Dhody
To: Ben Niven-Jenkins , "rtg-dir@ietf.org"
CC: "pce@ietf.org" , "draft-ietf-pce-pcep-exp-codepoints.all@ietf.org"
Thread-Topic: [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04
Thread-Index: AQHTaDmPNCdRCbcL3EqacLHp06r5saMpoi1A
Date: Tue, 28 Nov 2017 11:11:55 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8D5E5874@BLREML503-MBX.china.huawei.com>
References: <151186742816.13409.4274999012117883106@ietfa.amsl.com>
In-Reply-To: <151186742816.13409.4274999012117883106@ietfa.amsl.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At:
Subject: Re: [RTG-DIR] [Pce] Rtgdir last call review of draft-ietf-pce-pcep-exp-codepoints-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate