Gottlieb, Jordan J | 19 Dec 22:44 2014

[Softwires] Last Call: <draft-ietf-softwire-map-t-08.txt> (Mapping of Address and Port using Translation (MAP-T)) to Experimental RFC

To whom it may concern,

 

Please consider my comments in support of draft-ietf-softwire-map-t-08.txt as part of your deliberation process.  The characteristics of interest to me and my organization are as follows:

 

Desirable characteristics of MAP-T that are common with MAP-E and in some cases other softwire technologies:

 

-The ability to support asymmetrical routing through the Border Relays

 

-The ability to support  full or shared IPv4 address allocation

 

-The ability to retain NAPT functionality at the customer edge

 

-The compatibility with existing facilities for customer edge provisioning

 

-The elimination of overhead associated with maintaining state at the Border Relays

 

-Does not require significant augmentation of existing logging facilities for the purpose of complying with existing lawful intercept requests 

 

 

Desirable Characteristics unique to MAP-T (and 4RD) and not supported by MAP-E

 

-The ability to deploy IPv4-mapped IPv6 addressed servers/services that support IPv4 customer endpoints

 

-The ability to deploy access control and classifiers at layer-4

 

-The ability to use existing Deep Packet Inspection facilities

 

-Other forwarding capabilities inherent to the use of a BR prefix as opposed to a BR address

 

 

Our reservations with 4RD which shares many of the characteristics of MAP-T revolve around the additional complexity involved with this technology.  We believe that the benefits gained from the added level of IPv4 transparency are not outweighed by the implementation and operational overhead.

 

Sincerely,

 

Jordan

 

Jordan Gottlieb | Principal Engineer |  303 323 6081

8100 East Maplewood Ave., Suite 150 | Greenwood Village, CO 80111

 

Roni Even | 21 Dec 14:57 2014
Picon

Gen-ART LC review of draft-ietf-sfc-problem-statement-10

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document:  draft-ietf-sfc-problem-statement-10

Reviewer: Roni Even

Review Date:2014–12-21

IETF LC End Date: 2014–12-25

IESG Telechat date:

 

Summary: This draft is ready for publication as an Informational RFC.

 

 

Major issues:

 

Minor issues:

 

 

Nits/editorial comments:

 

Benoit Claise | 19 Dec 17:19 2014
Picon

YANG advice and editing session on the next IETF"

Dear all,

Building on the previous positive experiences, we will hosting another 
"YANG advice and editing session" at this coming IETF meeting, on Sunday 
March 22nd, in the afternoon.
Something similar to 
http://www.ietf.org/meeting/91/tutorials/yang-session.html
I wanted to let you know, in case you plan your trip now....

Regards, Benoit

Thomas Narten | 19 Dec 06:53 2014
Picon

Weekly posting summary for ietf <at> ietf.org

Total of 117 messages in the last 7 days.

script run at: Fri Dec 19 00:53:03 EST 2014

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
  5.98% |    7 | 12.14% |   134499 | jan.pechanec <at> oracle.com
  7.69% |    9 |  7.41% |    82099 | jari.arkko <at> piuha.net
  5.98% |    7 |  4.92% |    54493 | nico <at> cryptonector.com
  5.13% |    6 |  3.81% |    42231 | john-ietf <at> jck.com
  3.42% |    4 |  3.77% |    41789 | lear <at> cisco.com
  2.56% |    3 |  4.29% |    47493 | david.black <at> emc.com
  2.56% |    3 |  3.21% |    35611 | acee <at> cisco.com
  2.56% |    3 |  2.52% |    27910 | mustapha.aissaoui <at> alcatel-lucent.com
  2.56% |    3 |  2.10% |    23221 | marka <at> isc.org
  2.56% |    3 |  2.05% |    22755 | mark.tinka <at> seacom.mu
  2.56% |    3 |  1.91% |    21136 | brian.e.carpenter <at> gmail.com
  2.56% |    3 |  1.81% |    20050 | heas <at> shrubbery.net
  2.56% |    3 |  1.68% |    18568 | mohta <at> necom830.hpcl.titech.ac.jp
  2.56% |    3 |  1.64% |    18195 | cowan <at> mercury.ccil.org
  2.56% |    3 |  1.58% |    17524 | johnl <at> taugh.com
  1.71% |    2 |  2.29% |    25338 | julian.reschke <at> gmx.de
  1.71% |    2 |  2.15% |    23851 | spencerdawkins.ietf <at> gmail.com
  1.71% |    2 |  2.15% |    23779 | jaroslav.imrich <at> gmail.com
  1.71% |    2 |  2.06% |    22844 | daedulus <at> btconnect.com
  1.71% |    2 |  1.81% |    20006 | adrian <at> olddog.co.uk
  1.71% |    2 |  1.64% |    18212 | turners <at> ieca.com
  1.71% |    2 |  1.58% |    17455 | huitema <at> microsoft.com
  1.71% |    2 |  1.52% |    16840 | dwing <at> cisco.com
  0.85% |    1 |  2.36% |    26153 | pranjal.dutta <at> alcatel-lucent.com
  1.71% |    2 |  1.47% |    16341 | cdl_forward <at> cdl.asgaard.org
  1.71% |    2 |  1.34% |    14800 | darren.moffat <at> oracle.com
  1.71% |    2 |  1.33% |    14772 | ted.lemon <at> nominum.com
  1.71% |    2 |  1.31% |    14558 | ned+ietf <at> mauve.mrochek.com
  1.71% |    2 |  1.29% |    14249 | mcr+ietf <at> sandelman.ca
  1.71% |    2 |  1.25% |    13876 | stbryant <at> cisco.com
  0.85% |    1 |  1.71% |    18956 | julian.reschke <at> greenbytes.de
  0.85% |    1 |  1.41% |    15615 | phill <at> hallambaker.com
  0.85% |    1 |  1.08% |    11945 | jhw <at> nestlabs.com
  0.85% |    1 |  0.99% |    10937 | narten <at> us.ibm.com
  0.85% |    1 |  0.90% |     9950 | lberger <at> labn.net
  0.85% |    1 |  0.88% |     9753 | rjsparks <at> nostrum.com
  0.85% |    1 |  0.86% |     9494 | lee <at> asgard.org
  0.85% |    1 |  0.85% |     9470 | mstjohns <at> comcast.net
  0.85% |    1 |  0.80% |     8854 | agmalis <at> gmail.com
  0.85% |    1 |  0.77% |     8532 | zhangfatai <at> huawei.com
  0.85% |    1 |  0.76% |     8380 | d3e3e3 <at> gmail.com
  0.85% |    1 |  0.75% |     8296 | paf <at> frobbit.se
  0.85% |    1 |  0.71% |     7818 | doug.mtview <at> gmail.com
  0.85% |    1 |  0.69% |     7598 | nmav <at> gnutls.org
  0.85% |    1 |  0.67% |     7467 | wesley.george <at> twcable.com
  0.85% |    1 |  0.63% |     6954 | jmh <at> joelhalpern.com
  0.85% |    1 |  0.62% |     6886 | chair <at> ietf.org
  0.85% |    1 |  0.61% |     6812 | ietf-secretariat <at> ietf.org
  0.85% |    1 |  0.60% |     6696 | dhc <at> dcrocker.net
  0.85% |    1 |  0.60% |     6649 | randy_presuhn <at> mindspring.com
  0.85% |    1 |  0.58% |     6391 | ajs <at> anvilwalrusden.com
  0.85% |    1 |  0.58% |     6389 | stephen.farrell <at> cs.tcd.ie
  0.85% |    1 |  0.55% |     6114 | cabo <at> tzi.org
  0.85% |    1 |  0.51% |     5659 | paul.hoffman <at> vpnc.org
  0.85% |    1 |  0.51% |     5607 | iad <at> ietf.org
--------+------+--------+----------+------------------------
100.00% |  117 |100.00% |  1107870 | Total

Donald Eastlake | 19 Dec 02:58 2014
Picon

Fwd: Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice

On Thu, Dec 18, 2014 at 5:47 PM, Spencer Dawkins at IETF
<spencerdawkins.ietf <at> gmail.com> wrote:
> There's really nothing as awesome as sending Last Call comments on your own
> draft. You should try it some time ... or not.
>
> But please see below.
>
> ...
>
> I had a chat with Scott Bradner today, and Scott asked me to explain some
> history in a different way. The text he questioned was this:
>
> OLD
>
>    In the distant past, all IETF Areas had a single Area Director.  The
>    movement from single Area Directors in an Area to pairs of Area
>    Directors in most Areas happened over a period of years (for
>    reference, see http://www.ietf.org/iesg/past-members.html), as part
>    of the IESG organizing itself to do the work the IESG is chartered to
>    do.
>
> END
>
> Scott said that changes in the number of Area Directors assigned to a given
> Area during "the modern era", post Kobe, wasn't quite the linear progression
> I described, and suggested (my words, trying to capture his thoughts),
> something more like this:
>
> NEW
>
> While it's true that recent IESGs have had two Area Directors in each Area
> except for the General Area, the number of Area Directors in each Area has
> varied since https://www.ietf.org/rfc/rfc1396.txt (for reference, see
> http://www.ietf.org/iesg/past-members.html).
>
> This variation was due to a number of factors, including workload and
> personal preferences, and happened as a natural part of the IESG organizing
> itself to do the work the IESG is chartered to do.
>
> At one point, the IESG placed three Area Directors in a single Area (Scott
> Bradner, Deirdre Kostick, and Michael O'Dell, in the Operational &
> Management Requirements Area, between IETF 36 and IETF 37 in 1996).

I think it is a good change to the text. It grounds the change to the
limit on the number of ADs in real events.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 <at> gmail.com

> END
>
> I wouldn't mind hearing people's opinions about making this change as part
> of Last Call, and I don't think the rest of the IESG would mind, either ...
>
> Thanks!
> Spencer
>
>> Abstract
>>
>>
>>    This document removes a limit on the number of Area Directors who
>>    manage an Area in the definition of "IETF Area".  This document
>>    updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25).
>>
>>...

Spencer Dawkins at IETF | 19 Dec 01:10 2014
Picon

Re: Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice


On Dec 18, 2014 6:02 PM, "Michael StJohns" <mstjohns <at> comcast.net> wrote:
>
> At 05:47 PM 12/18/2014, Spencer Dawkins at IETF wrote:
>
>
>> NEW
>>
>> While it's true that recent IESGs have had two Area Directors in each Area except for the General Area, the number of Area Directors in each Area has varied since https://www.ietf.org/rfc/rfc1396.txt (for reference, see http://www.ietf.org/iesg/past-members.html).Â
>>
>> This variation was due to a number of factors, including workload and personal preferences, and happened as a natural part of the IESG organizing itself to do the work the IESG is chartered to do.Â
>>
>> At one point, the IESG placed three Area Directors in a single Area (Scott Bradner, Deirdre Kostick, and Michael O'Dell, in the Operational & Management Requirements Area, between IETF 36 and IETF 37 in 1996).
>
>
> I don't think I have any real problems with the original language.
>
> The particular case that Scott cites though was due to the combining of two different areas - Operations (which had 2 ADs) and Network Management (which had 1).  That happened midway through the cycle and not (AIRC) as part of the Nomcom placing three people as ADs for Ops and Management.
>
> So it was transitional, and reflected in the next Nomcom results which brought the O&M AD count down to two.   Operationally, I don't think it affected which groups the ADs had had before the merge.
>
> Mike

Hi, Mike,

Right - that's what I think I'm pointing to - that there's not a natural law that says all areas are exactly two ADs wide, and things can move around, and IESGs can work out specifics with Nomcoms.

Thanks for the extra background - it's helpful.

Spencer

Michael StJohns | 19 Dec 01:02 2014
Picon
Picon

Re: Last Call: <draft-dawkins-iesg-one-or-more-04.txt> (Increasing the Number of Area Directors in an IETF Area) to Best Current Practice

At 05:47 PM 12/18/2014, Spencer Dawkins at IETF wrote:


NEW

While it's true that recent IESGs have had two Area Directors in each Area except for the General Area, the number of Area Directors in each Area has varied since https://www.ietf.org/rfc/rfc1396.txt (for reference, see http://www.ietf.org/iesg/past-members.html).Â

This variation was due to a number of factors, including workload and personal preferences, and happened as a natural part of the IESG organizing itself to do the work the IESG is chartered to do.Â

At one point, the IESG placed three Area Directors in a single Area (Scott Bradner, Deirdre Kostick, and Michael O'Dell, in the Operational & Management Requirements Area, between IETF 36 and IETF 37 in 1996).

I don't think I have any real problems with the original language.

The particular case that Scott cites though was due to the combining of two different areas - Operations (which had 2 ADs) and Network Management (which had 1).  That happened midway through the cycle and not (AIRC) as part of the Nomcom placing three people as ADs for Ops and Management.

So it was transitional, and reflected in the next Nomcom results which brought the O&M AD count down to two.   Operationally, I don't think it affected which groups the ADs had had before the merge.

Mike



Robert Sparks | 18 Dec 22:09 2014

Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-holmberg-dispatch-iotl-03
Reviewer: Robert Sparks
Review Date: 18-Dec-2014
IETF LC End Date: 8-Jan-2015
IESG Telechat date: Not on an upcoming telechat agenda

Summary: Almost ready for publication as a Proposed Standard but has 
issues that need to be addressed

There are only a few issues to address:

Major Issue 1: It makes no sense to publish a standards track RFC that 
says behavior on general networks is undefined. I've reviewed all of the 
list traffic about this document, and I understand how the text that's 
currently in the document got there, but it's not the best way to deal 
with the concern that caused it to be introduced. The original concern 
was that the document didn't provide enough detail to tell what the 
presence or absence of the values meant, and whether there was an 
associate d change to the semantics of the protocol. While the 
description is thin, I think there has been enough shown to know that 
the semantics of the protocol are not being changed.

So, instead, the document should just recognize that devices that don't 
implement this specification will do what RFC 3261 requires them to do 
with unknown URI parameters: ignore them. This document sufficiently 
describes what the values it defines means to elements that _do_ 
implement this specification. They provide additional information to 
upper layers (ultimately, transaction users as 3261 defines them), and 
those upper layers might make forwarding decisions using it, just like 
they can use _anything_ at their disposal. The basic semantics of the 
SIP protocol are unaffected.

To resolve this issue, I suggest removing the text that occurs in 
several places saying that this is applicable only to 3gpp networks, and 
add a short sentence reminding the reader that RFC3261 expects new URI 
parameters to be standardized and defines how unknown URI parameters are 
handled.

Major Issue 2: The document suggests that implementations violate what 
RFC3261 requires them to do. Specifically, it says "An entity that 
understands the 'iotl' parameter MUST NOT, from a SIP request, remove 
'iotl' parameters from SIP URIs associated with other entities, unless 
the entity has means to determine that the 'iotl' parameter does not 
represent a valid traffic leg." RFC3261 requires that MUST NOT, and it 
does not allow the "unless" clause. It is not ok for an entity to change 
some other entities URIs in, say, Route, Service-Route, Path, and 
similar places under any circumstances.

My suggested resolution is to remove the unless clause, and change the 
first part of the sentence to note that this is what 3261 requires.

Major issue 3: The Security considerations section is incomplete. Please 
discuss the ramifications of something maliciously providing an 
incorrect value in the parameter. What are the ramifications if someone 
does violate protocol and changes or removes a value in transit?

Minor issue 1: It is unclear where you expect these URIs to occur. I 
have a good feel only after reading the list traffic. I suggest you be 
explicit in 5.1 that you expect these to be placed in Service-Route and 
Path header field values, hence to occur in Route header field values, 
and Request-URIs.

Minor issue 2: Why do you say "This document does not specify the usage 
of the 'iotl' parameter within a SIP URI of a Record-Route header field. 
Would it create an interoperability problem if someone put one there? 
Because if they do, it will end up in Route header fields later. If 
that's ok, please strike the sentence. If it's not, then you need to say 
MUST NOT place the parameter in URIs in Record-Route header field values.

Nits/editorial comments:

Since you are providing an extension point for other values, someone 
will ask if you need a registry for those values. I suggest explicitly 
saying we are not creating a registry at this time but expect to do so 
if the extension point is ever used to head that conversation off.

"dialogue" appears in a couple of places. Since we're talking about the 
3261 term, I suggest using "dialog" consistently.

The sentence (which occurs in the abstract and introduction) "The 
directionality in traffic legs relates to a SIP request creating a 
dialogue and stand-alone SIP request." does not parse. What is it trying 
to say, and why is it important?

Jari Arkko | 18 Dec 19:53 2014
Picon

last call and IESG processing summary for draft-ietf-ianaplan-icg-response

This is a summary of the last call and conclusion from the IESG processing of this draft.

This document has attained rough consensus of the IETF Working Group and of the IETF community as a whole, as
judged first by the chairs and then by the sponsoring Area Director, and then by the IESG in accordance with
RFC 2026 in the December 18 IESG telechat. The IESG has approved the draft, although the formal approval
will be a few days away to make sure the new version did not miss anything. If you see an issue that has been
missed or change that is not correctly implemented, please report it to us by Dec 29, 2014.

Over the course of the development of the document, several suggestions were raised that did not enjoy
sufficient support to be included. Two main ones worth mentioning include

	• A suggestion for a stronger statement over what terms the IAOC should negotiate.  

	• A suggestion that "iana.org" and other associated marks be transferred to the IETF trust.

At the end of the working group process, although there was not unanimous support for the results, the
working group chairs concluded that rough consensus existed in the working group. The document
shepherd’s summary of the WG consensus for this document can be found here: 

  https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/shepherdwriteup/

During IETF last call, additional people voiced support for the document. There were several editorial
comments that resulted in changes, as well as some discussion of more substantial comments some of which
resulted in text changes. There was some discussion of comments already discussed earlier in the
process, and but no new objections were raised during the IETF last call. A summary of the last call
comments can be found from the end of this e-mail.

A new draft version has been prepared by the editors per discussions on the mailing list and with the
sponsoring AD. The new draft version and associated changes can be found here:

 https://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-07
 https://tools.ietf.org/rfcdiff?url2=draft-ietf-ianaplan-icg-response-07.txt

However, a further version will be soon forthcoming with also (a) suggested text from IAB added to Section 5
and (b) description of how and what level of consensus the draft reached.

During the IETF last call and IESG evaluation, the following points were made:

	• Positive evaluation from Christer Holmberg, Melinda Shore, Alissa Cooper, Richard Barnes, and Ted
Lemon. Currently, there is a Yes position from 12 Area Directors.

	• Editorial comments from Brian Carpenter, Sean Turner, Pete Resnick, Adrian Farrell, Spencer
Dawkins, Alissa Cooper, Alia Atlas, Richard Barnes, and Christer Holmberg. These have resulted in text changes.

	• A comment from Pete Resnick around the use of full text from IETF mission statement RFC. This has
resulted in a text change.

	• A comment from Sean Turner about some missing parts in the response. This has resulted in text changes.

	• Agreement with the general message, but a question and a concern from John Levine around roles in
policy disputes, and contracts in case of changes in who is the IANA operator. These were resolved through
discussion with Eliot Leor, Brian Carpenter, and Jari Arkko. This resulted in text changes.

	• Discussion on the availability of text for Section 5 and how that can be handled process-wise, started
by Adrian Farrell. Suggested resolution is to use the text that IAB wants to indicate, "The IAB supports
the response in this document". The text is now out in the working group list, which it was not before. A new
document version is needed to add this text.

	• Discussion on the role of the document after IESG approval, and whether the goal was to get IESG review
or approval. The sponsoring AD believes that it is important to use our normal approval process, and
ensure that the IESG agrees with the consensus assessments in this case. Whether the document gets
published as an RFC or not is somewhat immaterial, because the main purpose of providing an IETF view on the
matter is to collect several views together from different organisations to gather a complete
transition proposal.

	• Discussion of the rationale for concluding rough consensus from Richard Hill (responses from Marc
Blanchet, Andrew Sullivan, Milton Muller, Jari Arkko, Brian Carpenter, John Curran, and Jefsey).
Richard was requesting a rationale for why the conclusion was what it was, or perhaps rather disagreeing
with the rationale that was provided.

	• Recommendation to the IAOC to create stronger supplemental or replacement agreements between the
IETF and ICANN, by Milton Muller and the Internet Governance Project. The recommendation recognises the
rough consensus behind the current proposal that specifies requirements but does not call out explicit
agreement mechanisms, but suggests that the stronger agreements would be extremely significant. The
recommendation goes on to "provide information to the IETF's leadership regarding what the unresolved
issues were, why it is important to resolve them, and how it might respond to them with supplemental
agreements". The recommendation also states that the advocated actions are in line with the current
IANAPLAN draft. The IAOC has taken this input for consideration. It should be noted that these
recommendations were discussed as part of the WG deliberations, however. The WG consensus did not agree
with the recommendations.

	• Jefsey has noted that he intends to file a future appeal on this topic, around the responsibilities of
the IETF and RFC 6852. Jefsey notes "My point will not be to change it, but to make sure that the IESG, and IAB,
and ISOC, fully and publicly declare that they understand, accept and decide that this is what they mean."
It is not clear that there is anything to do about this at the moment, particularly when at least the
sponsoring AD does not understand the provided feedback; this is an IETF document that will, as it gains
approval, will have been processed by the IESG and will explicitly note that the IAB supports the
described transition. Response by Andrew Sullivan on December 15 indicates that he does not believe any
changes to the document or the summaries produced by the WG officials were necessary.

	• The IAOC has indicated that they are comfortable with the direction the document gives for the IAOC.

Jari Arkko, the sponsoring Area Director for draft-ietf-ianaplan-icg-response
John C Klensin | 18 Dec 16:48 2014

Redundant email floods

Hi.

I hope this won't set off a long discussion, but, especially
when I'm traveling and need to check email quickly during short
breaks or equivalent, I'm becoming increasingly irritated with a
side-effect of what is certainly well-intentioned increased
communications.  Support I'm subscribed to a WG list, a document
has gone into Last Call, and a new version is posted.  I get:

(1) A new I-D announcement on i-d-announce
(2) A copy of that announcement on the WG mailing list
(3) A "New Version notification" for the I-D
(4) An IETF Secretariat ID Tracker State update notice
     and, if I'm really lucky,
(5) A note from the author, editor, or WG Chair that is
basically a copy of the first and second, maybe with a change
summary.

If the document has not going into Last Call or some other "the
IESG to paying sufficient attention" state, only one of these is
eliminated.

Is this bothering anyone else?  Can something be done about it?

Yes, I can filter most of it out, but such filters either
require careful design, perhaps on a per-WG basis, or risk
losing follow-up comments or important stuff from other WGs or
individuals.  Taking (4) as an example, I may want to see
critical status changes or AD reviews from the tracker, but
don't need to know that an I-D has been updated when I've
already been told that three times.

     john

IETF Chair | 17 Dec 23:56 2014
Picon

IESG YANG Model Work Redistribution

The IESG plans on redistributing workload in order to allow for
resources to be  focused on YANG model coordination. Discussion on
how to do so  based on demand has been going on for some time.

https://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/

Primary oversight responsibility and coordination of this work across
areas (AD document ownership) becomes the responsibility of Benoit Claise.

Working groups with YANG model work remain the responsibility of the
currently responsible AD.

A YANG Model Coordination group (a RFC2418 directorate) will be
created by the IESG to assist the AD and complement the work of the,
YANG Doctors, Operations and Management Directorate and Routing area
directorate and IAB liaison managers. The YANG doctor's responsibility
to validate models remains unchanged.  The YANG Model Coordination group
will consist of  up to three members initially and report to the
Operations and Management AD assuming the YANG Model work.

The responsible AD for some Operations and Management working groups
will be shifted to in order to distribute the workload. For now the area
associated with the working-group doesn't change.

The Title of Operations and Management AD remains associated with the
current responsibilities. New BOFs or working groups created to support
YANG model work will be assigned to the appropriate area. As with SNMP
MIBs the preference is for work to occur in the working group where the
expertise exists for each data model.

The IESG thinks about organizational effectiveness on an ongoing basis
both tactically and strategically; When newly seated ADs are installed
in March It is likely that the distribution of working groups will be
revisited, as it typically is in a more limited fashion.

Jari Arkko for the IESG


Gmane