Re: Basic ietf process question ...

[ned+ietf]

> On 03/08/2012, at 5:59 PM, Ned Freed  wrote:

> >> Specifically, it's very common for people to try to use schema to inform
> >> "binding" tools into specific languages. However, the underlying metamodel 
> >> of
> >> XML, the Infoset, is both complex and a poor fit for most languages, so
> >> bindings take "shortcuts" and expose a profile of XML's range of 
> >> expression,
> >> encouraging some patterns of use, while discouraging (or disallowing) 
> >> others.
> >> Since the bindings often make different decisions (based upon the language 
> >> of
> >> use), interoperability is difficult (sometimes, impossible).
> >
> > It very much depends on what you're doing and how you're doing it. If what
> > you want is for your data to manifest directly as a data structure, XML is
> > a lousy fit for that for a bunch of different reasons. Json is the clear 
> > choice
> > in such cases. But there are other uses where the more complex Infoset of
> > XML can be an asset.

> Very much; when it becomes a "document" (e.g., mixed markup), XML is a much
> better choice.

The other interesting case is where large amounts of data arrive in a stream.
SAX and SAX-like libraries makes this easy to implement with XML. I hope
there's an equivalent for Json; if not there needs to be.

> >
> > Really, it's all about how you use the available tools.
> >
> >> Furthermore, designing a schema that is extensible is incredibly convoluted
> >> in XML Schema 1.0. Schema 1.1 was designed to address this failure, but it
> >> hasn't been broadly adopted; most people I know in the field consider it a
> >> failure.
> >
> > Yes, XML Schema makes this a lot harder to do than it should be, but in a 
> > lot
> > of designs I've seen it also has to do with how XML is actually used. A bad
> > design is a bad design, regardless of what schema language you use.
> >
> >> What surprises me and many others is that people are still using it and
> >> promoting it, when it's well-understood by almost EVERYONE who was 
> >> involved in
> >> using XML for protocols in the past ten years agrees that it's a mistake.
> >
> > See above. I certainly wouldn't use XML Schema for anything new, but there's
> > a lot of legacy stuff out there.

> That's the rub, isn't it?

Yeah, and it sure is rubbing me the wrong way every time I look at our usage.
I know it was the right choice at the time, and now that it's done it's not
cost effective to change unless we need additional capabilities, but that
all so ... unsatisfying.

Ned

Re: Basic ietf process question ...

[Mark Nottingham]

On 03/08/2012, at 5:59 PM, Ned Freed  wrote:

>> Specifically, it's very common for people to try to use schema to inform
>> "binding" tools into specific languages. However, the underlying metamodel of
>> XML, the Infoset, is both complex and a poor fit for most languages, so
>> bindings take "shortcuts" and expose a profile of XML's range of expression,
>> encouraging some patterns of use, while discouraging (or disallowing) others.
>> Since the bindings often make different decisions (based upon the language of
>> use), interoperability is difficult (sometimes, impossible).
> 
> It very much depends on what you're doing and how you're doing it. If what
> you want is for your data to manifest directly as a data structure, XML is
> a lousy fit for that for a bunch of different reasons. Json is the clear 
> choice
> in such cases. But there are other uses where the more complex Infoset of
> XML can be an asset.

Very much; when it becomes a "document" (e.g., mixed markup), XML is a much 
better choice.

> 
> Really, it's all about how you use the available tools.
> 
>> Furthermore, designing a schema that is extensible is incredibly convoluted
>> in XML Schema 1.0. Schema 1.1 was designed to address this failure, but it
>> hasn't been broadly adopted; most people I know in the field consider it a
>> failure.
> 
> Yes, XML Schema makes this a lot harder to do than it should be, but in a lot
> of designs I've seen it also has to do with how XML is actually used. A bad
> design is a bad design, regardless of what schema language you use.
> 
>> What surprises me and many others is that people are still using it and
>> promoting it, when it's well-understood by almost EVERYONE who was involved 
>> in
>> using XML for protocols in the past ten years agrees that it's a mistake.
> 
> See above. I certainly wouldn't use XML Schema for anything new, but there's
> a lot of legacy stuff out there.

That's the rub, isn't it?

--
Mark Nottingham
http://www.mnot.net/

Re: Basic ietf process question ...

[ned+ietf]

> XML Schema is grossly over-engineered for its purpose; being the subject of
> requirements from not only the document markup field, but also databases and
> object models, it's a twisted monstrosity that tries to do many things, and
> fails at most.

Agreed, and I would add that it is seriously lacking in flexibility. (I would
like to have words with whoever thought the "unique particle attribution rule"
was a good idea.)

That said, there's a timing issue in play here. A variety of tools supporting
other validation systems, e.g., RelaxNG or Schematron are available now, but a
few years back alternatives to XML Schema were much more limited. Despite our
dislike we've used XML Schema in a couple of places for precisely this reason.

> Specifically, it's very common for people to try to use schema to inform
> "binding" tools into specific languages. However, the underlying metamodel of
> XML, the Infoset, is both complex and a poor fit for most languages, so
> bindings take "shortcuts" and expose a profile of XML's range of expression,
> encouraging some patterns of use, while discouraging (or disallowing) others.
> Since the bindings often make different decisions (based upon the language of
> use), interoperability is difficult (sometimes, impossible).

It very much depends on what you're doing and how you're doing it. If what
you want is for your data to manifest directly as a data structure, XML is
a lousy fit for that for a bunch of different reasons. Json is the clear choice
in such cases. But there are other uses where the more complex Infoset of
XML can be an asset.

Really, it's all about how you use the available tools.

> Furthermore, designing a schema that is extensible is incredibly convoluted
> in XML Schema 1.0. Schema 1.1 was designed to address this failure, but it
> hasn't been broadly adopted; most people I know in the field consider it a
> failure.

Yes, XML Schema makes this a lot harder to do than it should be, but in a lot
of designs I've seen it also has to do with how XML is actually used. A bad
design is a bad design, regardless of what schema language you use.

> What surprises me and many others is that people are still using it and
> promoting it, when it's well-understood by almost EVERYONE who was involved in
> using XML for protocols in the past ten years agrees that it's a mistake.

See above. I certainly wouldn't use XML Schema for anything new, but there's
a lot of legacy stuff out there.

Ned

Re: Last Call: (Updated Specification of the IPv4 ID Field) to Proposed Standard

[Joe Touch]

On 8/3/2012 4:19 PM, Masataka Ohta wrote:
> Joe Touch wrote:
> 
>> Translators violate RFC791. They cannot merely copy the
>> low-order bits of the field, since that is insufficiently
>> unique, and isn't specified as being generated at the
>> IPv6 source in compliance with IPv4 requirements.
> 
> RFC2765 specifies that translators can merely copy the
> low-order bits of the field.

Yes, but this is not compatible with RFC791.

> Moreover, RFC2460 specifies:
> 
> In that case, the IPv6 node
> is not required to reduce the size of subsequent packets to less than
> 1280, but must include a Fragment header in those packets so that the
> IPv6-to-IPv4 translating router can obtain a suitable Identification
> value to use in resulting IPv4 fragments.
> 
> That is, RFC2460 guarantees that translators can obtain "a
> suitable Identification value" from IPv6 "Fragment header".

The case above occurs only when the source gets back a "packet too big"
message with a desired MTU less than 1280. Note that this might never
happen, in which case there would never be any Fragment header.

However, even when it does happen, there is no instruction above about
how to construct the header that is compliant with RFC791.

Further, the source might already be inserting the fragmentation header
(e.g., on a 2KB packet). There's no instruction in how fragment headers
are constructed in general that complies with RFC791.

Simply using the low 16 bits is not correct. In particular, RFC2460
suggests that its 32-bit counter can wrap once a minute, and that only
one such counter might be needed for an endpoint for all connections. In
that case, the entire number space wraps twice as fast as RFC791/RFC1122
require for IPv4, and it's half the bit-width, so the low-order bits
alone wrap 120,000x faster.

> Or, are you saying RFC2460 and RFC2765 violate RFC791?

Yes.

> I'm afraid you must say so, if you insist on "existing systems
> violate the current specification" (quote from abstract of your
> draft).
> 
>> It quotes IPv6 examples, but does not propose to change
>> IPv6 processing. That may be needed, but that would be
>> outside the scope of this doc.
> 
> It is inside the scope because RFC2765 specifies how IPv4
> ID is generated from RFC2460 fragment header, which is,
> according to your draft, a violation of RFC791.

This document updates RFC791, but does not fix either RFC2460 or
RFC2765. This document does not make any statements about how IPv6
generates its IDs.

>>> Finally, the IPv6 ID field is
>>> 32 bits, but lower 16 bits are required unique per
>>> source/destination address pair for
>>> IPv6,
>>
>> That's incorrect as per RFC2460. Other RFCs may violate that
>> original spec, but that needs to be cleaned up separately.
> 
> As I stated above, RFC2460 guarantees "a suitable Identification
> value" for IPv4 ID is there in IPv6 fragmentation ID.

Not the way I interpret the text, especially because there are other
ways to generate IDs in RFC2460 that could be translated to IPv4 that
might not result from ICMP errors, or that might never have
Fragmentation headers anyway.

> Or, if you think RFC2460 does not mind ID uniqueness (of IPv4,
> at least) so much, RFC791 should not either.

I think there are a lot of IETF documents that are not reviewed in the
correct context of existing standards. I don't think that applies to
this draft, though.

Joe

Re: Meeting "lounges" at IETF meetings

[Tim Chown]

On 3 Aug 2012, at 23:38, James Polk  wrote:
> 
> To me the exceptional aspects far outweighed the bad things - so I'm chalking 
> this venue up as one of the best in 13 years of attending IETFs, and a 
> *serious* contrast to the Paris venue (which I believe was one of the worst - 
> each time we were there, though the city was nice).

+1

Would be fun to get access to an API for the lifts for next time ;)

Tim

Re: Meeting "lounges" at IETF meetings

[Tim Chown]

On 3 Aug 2012, at 22:56, Mary Barnes  wrote:

> The issue that I experienced (and why I'm fussing)  is that if you were 
> attending many sessions in the Regency rooms (and moving rooms between 
> sessions), it was extremely difficult to weave your way through the corridor 
> as many people were having their discussion directly in the middle of the 
> corridor.  There just was not room in that corridor for side conversations.  
> The situation was made worse as that corridor was where they served the 
> refreshments.   And trying to ask people politely to move generally had no 
> impact in my experience as people were too engaged in their conversations.  

The corridor congestion when food was served was the only minor nit in an 
otherwise excellent meeting.  The wireless, the facilities etc were all top 
notch.

Tim

Re: Last Call: (Updated Specification of the IPv4 ID Field) to Proposed Standard

[Masataka Ohta]

Joe Touch wrote:

> Translators violate RFC791. They cannot merely copy the
> low-order bits of the field, since that is insufficiently
> unique, and isn't specified as being generated at the
> IPv6 source in compliance with IPv4 requirements.

RFC2765 specifies that translators can merely copy the
low-order bits of the field.

Moreover, RFC2460 specifies:

   In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.

That is, RFC2460 guarantees that translators can obtain "a
suitable Identification value" from IPv6 "Fragment header".

Or, are you saying RFC2460 and RFC2765 violate RFC791?

I'm afraid you must say so, if you insist on "existing systems
violate the current specification" (quote from abstract of your
draft).

> It quotes IPv6 examples, but does not propose to change
> IPv6 processing. That may be needed, but that would be
> outside the scope of this doc.

It is inside the scope because RFC2765 specifies how IPv4
ID is generated from RFC2460 fragment header, which is,
according to your draft, a violation of RFC791.

>>Finally, the IPv6 ID field is
>>32 bits, but lower 16 bits are required unique per
>>source/destination address pair for
>>IPv6,
> 
> That's incorrect as per RFC2460. Other RFCs may violate that
> original spec, but that needs to be cleaned up separately.

As I stated above, RFC2460 gurantees "a suitable Identification
value" for IPv4 ID is there in IPv6 fragmentation ID.

Or, if you think RFC2460 does not mind ID uniqueness (of IPv4,
at least) so much, RFC791 should not either.

Masataka Ohta

Re: Meeting "lounges" at IETF meetings

[James Polk]

Having missed only 2 meetings in 13 years, I can say that no venue 
was perfect, but some were very good. It becomes a case of which 
venues have the fewest "bad" things. I believe this venue was 
exceptional at many things, very good at nearly all others, with the 
bad things being food/snacks served in the crowded hallway and that 
sucky elevator algorithm (which was by far the worst think here).


The crowded hallway we can't change.

We can change where the snacks are served, and I have read that will 
happen for our next meeting in Vancouver here in 15 months.


To me the exceptional aspects far outweighed the bad things - so I'm 
chalking this venue up as one of the best in 13 years of attending 
IETFs, and a *serious* contrast to the Paris venue (which I believe 
was one of the worst - each time we were there, though the city was nice).


However, YMMV

James

At 05:10 PM 8/3/2012, Ole Jacobsen wrote:


The narrowness of the corridoors, placement of food/drink and all that
was discussed in our wrap-up meeting this morning, and indeed the
issues you have raised were indentified as areas for improvement.
Since we are coming back to THIS hotel, there are certainly things
that can be done better, and will be done better, next time.

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
Skype: organdemo


On Fri, 3 Aug 2012, Mary Barnes wrote:

> The issue that I experienced (and why I'm fussing)  is that if you were
> attending many sessions in the Regency rooms (and moving rooms between
> sessions), it was extremely difficult to weave your way through the
> corridor as many people were having their discussion directly in the middle
> of the corridor.  There just was not room in that corridor for side
> conversations.  The situation was made worse as that corridor was where
> they served the refreshments.   And trying to ask people politely to move
> generally had no impact in my experience as people were too engaged in
> their conversations.
>
> Mary.
>
> On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau 
wrote:

>
> > I agree with randy. I've never had an issue finding a place to 
huddle/meet
> > when necessary at an ietf meeting venue. between the hallways, 
bar, etc I'm

> > not sure what the fuss is all about.
> >
> > Tom
> >
> >
> >
> > On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:
> >
> > >>> i have no need to micro-manage the secretariat.
> > >> seems to happen a lot around here...
> > >
> > > symptom of too much free time on hands
> > >
> > > randy
> > >
> >
>

Re: Meeting "lounges" at IETF meetings

[Stephen Farrell]

On 08/03/2012 11:10 PM, Ole Jacobsen wrote:
> 
> The narrowness of the corridoors, placement of food/drink and all that 
> was discussed in our wrap-up meeting this morning, and indeed the 
> issues you have raised were indentified as areas for improvement. 
> Since we are coming back to THIS hotel, there are certainly things 
> that can be done better, and will be done better, next time. 

That gives the NOC folks time to figure out how to take
over the elevator system for next time too:-)

S

> 
> Ole
> 
> 
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
> E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
> Skype: organdemo
> 
> 
> On Fri, 3 Aug 2012, Mary Barnes wrote:
> 
>> The issue that I experienced (and why I'm fussing)  is that if you were
>> attending many sessions in the Regency rooms (and moving rooms between
>> sessions), it was extremely difficult to weave your way through the
>> corridor as many people were having their discussion directly in the middle
>> of the corridor.  There just was not room in that corridor for side
>> conversations.  The situation was made worse as that corridor was where
>> they served the refreshments.   And trying to ask people politely to move
>> generally had no impact in my experience as people were too engaged in
>> their conversations.
>>
>> Mary.
>>
>> On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau wrote:
>>
>>> I agree with randy. I've never had an issue finding a place to huddle/meet
>>> when necessary at an ietf meeting venue. between the hallways, bar, etc I'm
>>> not sure what the fuss is all about.
>>>
>>> Tom
>>>
>>>
>>>
>>> On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:
>>>
>> i have no need to micro-manage the secretariat.
> seems to happen a lot around here...

 symptom of too much free time on hands

 randy

>>>
>>

Re: Meeting "lounges" at IETF meetings

[Mary Barnes]

Thanks!

On Fri, Aug 3, 2012 at 5:10 PM, Ole Jacobsen  wrote:

>
> The narrowness of the corridoors, placement of food/drink and all that
> was discussed in our wrap-up meeting this morning, and indeed the
> issues you have raised were indentified as areas for improvement.
> Since we are coming back to THIS hotel, there are certainly things
> that can be done better, and will be done better, next time.
>
> Ole
>
>
> Ole J. Jacobsen
> Editor and Publisher,  The Internet Protocol Journal
> Cisco Systems
> Tel: +1 408-527-8972   Mobile: +1 415-370-4628
> E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
> Skype: organdemo
>
>
> On Fri, 3 Aug 2012, Mary Barnes wrote:
>
> > The issue that I experienced (and why I'm fussing)  is that if you were
> > attending many sessions in the Regency rooms (and moving rooms between
> > sessions), it was extremely difficult to weave your way through the
> > corridor as many people were having their discussion directly in the
> middle
> > of the corridor.  There just was not room in that corridor for side
> > conversations.  The situation was made worse as that corridor was where
> > they served the refreshments.   And trying to ask people politely to move
> > generally had no impact in my experience as people were too engaged in
> > their conversations.
> >
> > Mary.
> >
> > On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau  >wrote:
> >
> > > I agree with randy. I've never had an issue finding a place to
> huddle/meet
> > > when necessary at an ietf meeting venue. between the hallways, bar,
> etc I'm
> > > not sure what the fuss is all about.
> > >
> > > Tom
> > >
> > >
> > >
> > > On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:
> > >
> > > >>> i have no need to micro-manage the secretariat.
> > > >> seems to happen a lot around here...
> > > >
> > > > symptom of too much free time on hands
> > > >
> > > > randy
> > > >
> > >
> >
>

Re: Meeting "lounges" at IETF meetings

[Ole Jacobsen]

The narrowness of the corridoors, placement of food/drink and all that 
was discussed in our wrap-up meeting this morning, and indeed the 
issues you have raised were indentified as areas for improvement. 
Since we are coming back to THIS hotel, there are certainly things 
that can be done better, and will be done better, next time. 

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
Skype: organdemo


On Fri, 3 Aug 2012, Mary Barnes wrote:

> The issue that I experienced (and why I'm fussing)  is that if you were
> attending many sessions in the Regency rooms (and moving rooms between
> sessions), it was extremely difficult to weave your way through the
> corridor as many people were having their discussion directly in the middle
> of the corridor.  There just was not room in that corridor for side
> conversations.  The situation was made worse as that corridor was where
> they served the refreshments.   And trying to ask people politely to move
> generally had no impact in my experience as people were too engaged in
> their conversations.
> 
> Mary.
> 
> On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau wrote:
> 
> > I agree with randy. I've never had an issue finding a place to huddle/meet
> > when necessary at an ietf meeting venue. between the hallways, bar, etc I'm
> > not sure what the fuss is all about.
> >
> > Tom
> >
> >
> >
> > On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:
> >
> > >>> i have no need to micro-manage the secretariat.
> > >> seems to happen a lot around here...
> > >
> > > symptom of too much free time on hands
> > >
> > > randy
> > >
> >
> 

Re: Meeting "lounges" at IETF meetings

[Alexa Morris]

Yes, the hallway congestion was a real issue at this meeting, and we are 
already working on ways to make sure that we manage it differently when we 
return next year. The refreshments will not be served in those same corridors, 
as a start. 

We are also working to address the desire for additional lounge areas. It is 
not always possible, given that our space varies considerably from meeting to 
meeting, but we are hoping to make it a more permanent fixture moving forward.

Alexa


On Aug 3, 2012, at 2:56 PM, Mary Barnes wrote:

> The issue that I experienced (and why I'm fussing)  is that if you were 
> attending many sessions in the Regency rooms (and moving rooms between 
> sessions), it was extremely difficult to weave your way through the corridor 
> as many people were having their discussion directly in the middle of the 
> corridor.  There just was not room in that corridor for side conversations.  
> The situation was made worse as that corridor was where they served the 
> refreshments.   And trying to ask people politely to move generally had no 
> impact in my experience as people were too engaged in their conversations.  
> 
> Mary. 
> 
> On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau  wrote:
> I agree with randy. I've never had an issue finding a place to huddle/meet 
> when necessary at an ietf meeting venue. between the hallways, bar, etc I'm 
> not sure what the fuss is all about.
> 
> Tom
> 
> 
> 
> On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:
> 
> >>> i have no need to micro-manage the secretariat.
> >> seems to happen a lot around here...
> >
> > symptom of too much free time on hands
> >
> > randy
> >
> 

--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

Re: Meeting "lounges" at IETF meetings

[Mary Barnes]

The issue that I experienced (and why I'm fussing)  is that if you were
attending many sessions in the Regency rooms (and moving rooms between
sessions), it was extremely difficult to weave your way through the
corridor as many people were having their discussion directly in the middle
of the corridor.  There just was not room in that corridor for side
conversations.  The situation was made worse as that corridor was where
they served the refreshments.   And trying to ask people politely to move
generally had no impact in my experience as people were too engaged in
their conversations.

Mary.

On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau wrote:

> I agree with randy. I've never had an issue finding a place to huddle/meet
> when necessary at an ietf meeting venue. between the hallways, bar, etc I'm
> not sure what the fuss is all about.
>
> Tom
>
>
>
> On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:
>
> >>> i have no need to micro-manage the secretariat.
> >> seems to happen a lot around here...
> >
> > symptom of too much free time on hands
> >
> > randy
> >
>

Re: Meeting "lounges" at IETF meetings

[Thomas Nadeau]

I agree with randy. I've never had an issue finding a place to huddle/meet when 
necessary at an ietf meeting venue. between the hallways, bar, etc I'm not sure 
what the fuss is all about.

Tom 



On Aug 3, 2012, at 3:27 PM, Randy Bush  wrote:

>>> i have no need to micro-manage the secretariat.
>> seems to happen a lot around here...
> 
> symptom of too much free time on hands
> 
> randy
> 

RE: Proposed IETF 95 Date Change

[Ronald Bonica]

+1

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Perala, Timo (NSN - FI/Espoo)
> Sent: Friday, August 03, 2012 4:05 PM
> To: IETF Discussion
> Subject: RE: Proposed IETF 95 Date Change
> 
> +1
> 
> Timo
> 
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> ext Philip Matthews
> Sent: Thursday, August 02, 2012 8:10 PM
> 
> I would personally prefer if the meeting was rescheduled for the week
> of April 3 - 8.
> - Philip
> 
> On 2012-08-02, at 9:45 , IETF Administrative Director wrote:
> 
> > The IAOC is seeking community feedback on a proposed date change for
> IETF 95
> > scheduled for March 2016.
> >
> > Currently IETF 95 is scheduled for 27 March to 1 April 2016.  27
> March
> is Easter.
> >
> > The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016
> and would like
> > feedback on those dates before making a decision.  Comments
> appreciated to ietf@ietf.org
> > by 6 August 2012.

Re: ITU-T Dubai Meeting

[SM]

At 12:18 AM 8/3/2012, Brian E Carpenter wrote:

Exactly. It is intended to defeat the Internet's historical growth model
of independence from national administrations and monopolies, by imposing
a geographical addressing scheme. Since the Internet actually works with
a topological addressing scheme, the effect is to force the topology
to be congruent with the geography. If you want central control, that's


Yes.  However that message is not reaching the 
people who are part of national administrations.


At 12:25 AM 8/3/2012, Patrik Fältström wrote:

The key here is control.


SAAG [1] might consider working on that Worst 
Common Practice document to explain to countries 
how they should "cut off" the Internet ( 
http://www.ietf.org/proceedings/84/slides/slides-84-irtfopen-1.pdf ). :-)


If I am not mistaken the control points are 
already in place in one or more countries.  The 
key may be control.  It may also be a desire to 
address a problem which people consider as important.


Regards,
-sm

1. There is generally one of more interesting 
presentations at SAAG.  I don't know how the Security ADs make that happen. 

Re: Meeting "lounges" at IETF meetings

[Mary Barnes]

Yeah, I have tons of free time at these meetings.And, my response was
absolutely an attempt to micro-manage rather than provide suggestions on
how the situation could be better handled (as I don't think taking over the
terminal room is a good idea).

Mary.

On Fri, Aug 3, 2012 at 3:27 PM, Randy Bush  wrote:

> >> i have no need to micro-manage the secretariat.
> > seems to happen a lot around here...
>
> symptom of too much free time on hands
>
> randy
>

Re: Meeting "lounges" at IETF meetings

[Mary Barnes]

Either one - I'll direct a donation to the Open Internet Endowment for
meeting rooms.  Or, we can increase the fees for legal requests as others
have been suggesting.

If you read the thread, I was responding to the takeover of the terminal
room as a meeting place.  I was trying to be constructive with my
suggestions.  You can interpret them however you want.

Mary.

On Fri, Aug 3, 2012 at 3:20 PM, Glen Zorn  wrote:

> **
> On Fri, 2012-08-03 at 14:13 -0500, Mary Barnes wrote:
>
>
>
>  On Fri, Aug 3, 2012 at 1:42 PM, Paul Hoffman 
> wrote:
>
>  On Aug 3, 2012, at 11:22 AM, Mary Barnes wrote:
>
> > Instead, I think we should ensure that future venues have adequate space
> for both circulating between meeting rooms and for side conversations.
>
>
>   Just to be clear: you would rather that we pay higher meeting fees in
> exchange for that adequate space?
>
>  [MB] Yes. [/MB]
>
>
> Just to be even clearer, are you offering to pay those higher fees out of
> your own pocket or just to type a larger number into your expense report?
>
>
>
> > I suggest that you could cut the cookie budget if funds really are the
> only reason this wouldn't be done.
>
>
>   That is one way to pay for the extra space; it might not be so popular
> in this particular crowd.
>
>  [MB]  Yes, I know it's not at all a popular idea (to reduce cookies),
> BUT we have had adequate space at previous meetings for which we paid the
> same meeting fee, so it seems possible to get space without increasing
> meeting fees (and I thought Vancouver was selected as it was deemed a very
> moderately priced venue for meetings).   Note, that we did get additional
> space on the 34th floor during the week (which I assumed we paid for).
> Also, there was a block of rooms on the 2nd floor that we did not use for
> our meetings.  [/MB]
>
>
>
>
>
>
> --Paul Hoffman
>
>
>
>

Re: Meeting "lounges" at IETF meetings

[Randy Bush]

>> i have no need to micro-manage the secretariat.
> seems to happen a lot around here...

symptom of too much free time on hands

randy

Re: Meeting "lounges" at IETF meetings

[Glen Zorn]

On Fri, 2012-08-03 at 14:13 -0500, Mary Barnes wrote:

> 
> 
> 
> On Fri, Aug 3, 2012 at 1:42 PM, Paul Hoffman 
> wrote:
> 
> On Aug 3, 2012, at 11:22 AM, Mary Barnes wrote:
> 
> > Instead, I think we should ensure that future venues have
> adequate space for both circulating between meeting rooms and
> for side conversations.
> 
> 
> 
> Just to be clear: you would rather that we pay higher meeting
> fees in exchange for that adequate space?
> 
> [MB] Yes. [/MB] 


Just to be even clearer, are you offering to pay those higher fees out
of your own pocket or just to type a larger number into your expense
report?

> 
> > I suggest that you could cut the cookie budget if funds
> really are the only reason this wouldn't be done.
> 
> 
> 
> That is one way to pay for the extra space; it might not be so
> popular in this particular crowd.
> 
> [MB]  Yes, I know it's not at all a popular idea (to reduce cookies),
> BUT we have had adequate space at previous meetings for which we paid
> the same meeting fee, so it seems possible to get space without
> increasing meeting fees (and I thought Vancouver was selected as it
> was deemed a very moderately priced venue for meetings).   Note, that
> we did get additional space on the 34th floor during the week (which I
> assumed we paid for). Also, there was a block of rooms on the 2nd
> floor that we did not use for our meetings.  [/MB]
> 
> 
>  
> 
> 
> --Paul Hoffman
> 
> 

RE: Proposed IETF 95 Date Change

[Glen Zorn]

> I would personally prefer if the meeting was rescheduled for the week of
> April 3 - 8.


Strongly opposed.

...

Re: Meeting "lounges" at IETF meetings

[Mark Nottingham]

On 03/08/2012, at 2:39 PM, Randy Bush  wrote:

> i have no need to micro-manage the secretariat.

+1

seems to happen a lot around here...


--
Mark Nottingham
http://www.mnot.net/

RE: Proposed IETF 95 Date Change

[Perala, Timo (NSN - FI/Espoo)]

+1

Timo

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
ext Philip Matthews
Sent: Thursday, August 02, 2012 8:10 PM

I would personally prefer if the meeting was rescheduled for the week of
April 3 - 8.
- Philip

On 2012-08-02, at 9:45 , IETF Administrative Director wrote:

> The IAOC is seeking community feedback on a proposed date change for
IETF 95
> scheduled for March 2016.
> 
> Currently IETF 95 is scheduled for 27 March to 1 April 2016.  27 March
is Easter.
> 
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016
and would like 
> feedback on those dates before making a decision.  Comments
appreciated to ietf@ietf.org 
> by 6 August 2012.

Re: Meeting "lounges" at IETF meetings

[Randy Bush]

i have no need to micro-manage the secretariat.  and i greatly
appreciate the meeting space the secretariat provided on 34f.
and i think they got the message and will sort it out.

randy

Re: Basic ietf process question ...

[Martin Rex]

Robert Raszuk wrote:
> 
> I understand that historically we had/still have SNMP however I have 
> never seen this being mandatory section of any standards track document. 
> Usually SNMP comes 5 years behind (if at all) making it obsolete by design.
> 
> NETCONF is great and very flexible communication channel for 
> provisioning. However it is sufficient to just look at number of ops 
> lists to see that those who tried to use it quickly abandoned their 
> efforts due to complete lack of XML schema from each vendor they happen 
> to use or complete mismatch of vendor to vendor XML interpretation.

There seems to be a network management protocol in active use
for CPE networking gear:

  http://en.wikipedia.org/wiki/TR-069

that is based on SOAP (ie WebService using XML).

-Martin

Re: Meeting "lounges" at IETF meetings

[Mary Barnes]

On Fri, Aug 3, 2012 at 1:42 PM, Paul Hoffman  wrote:

> On Aug 3, 2012, at 11:22 AM, Mary Barnes wrote:
>
> > Instead, I think we should ensure that future venues have adequate space
> for both circulating between meeting rooms and for side conversations.
>
> Just to be clear: you would rather that we pay higher meeting fees in
> exchange for that adequate space?
>
[MB] Yes. [/MB]

>
> > I suggest that you could cut the cookie budget if funds really are the
> only reason this wouldn't be done.
>
> That is one way to pay for the extra space; it might not be so popular in
> this particular crowd.
>
[MB]  Yes, I know it's not at all a popular idea (to reduce cookies), BUT
we have had adequate space at previous meetings for which we paid the same
meeting fee, so it seems possible to get space without increasing meeting
fees (and I thought Vancouver was selected as it was deemed a very
moderately priced venue for meetings).   Note, that we did get additional
space on the 34th floor during the week (which I assumed we paid for).
Also, there was a block of rooms on the 2nd floor that we did not use for
our meetings.  [/MB]



>
> --Paul Hoffman

Re: Progress with Open Internet endowment

[Russ Housley]

Thank you!   We made it.  We received $26,255 from 90 donors.

Thanks agin,
  Russ

On Aug 3, 2012, at 12:59 PM, Russ Housley wrote:

> As of Friday morning, we are very close to the goal.  As of 9:00 AM this 
> morning, we have $24,905 from 80 donors.  Please help if you can.
> 
> Thanks,
>  Russ
> 
> 
> On Aug 2, 2012, at 4:27 PM, Russ Housley wrote:
> 
>> Our current totals as of noon today, the Open Internet Endowment has 
>> received $19,245 from 54 donors.  Thanks to all.
>> 
>> It would be great to reach $25,000 (or more) from 75 donors (or more) by 
>> lunch tomorrow.  Please help if you can.
>> 
>> There will be a table at the Bits-N-Bites tonight.  People will be at the 
>> table to answer any questions you might have.
>> 
>> Thanks,
>> Russ
>> 
> 

Re: ITU-T Dubai Meeting

[Dmitry Burkov]

Mark,
I really enjoyed your professional remarks for the years and your deep and 
intrinsic mind,
but it seems that now it is not a time to discuss the issue that ipv4 is scarce 
resource :)


My opinion that IPv6 was done in the worst manner and we should simply 
recognize that we have no other way to satisfy industry needs in such short 
time. 

Nothing personal - as a lot of my friends spent significant part of their life 
on it.

Dima

On Aug 3, 2012, at 10:25 PM, Mark Andrews wrote:

> 
> In message , Daniel Karrenberg 
> w
> rites:
>> 
>> On 02.08.2012, at 22:41, Phillip Hallam-Baker wrote:
>> 
>>> ... That depends on whether the registry in question is dealing with a
>>> scarce resource or a plentiful one. Having two registries handing out
>>> IPv4 addresses at this point would be very very bad. Having more than
>>> one place you can get an IPv6 from would not worry me at all. ...
>> 
>> IPv4 addresses used to be regarded as non-scarce not so long ago.
> 
> I don't know what planet you have been living on but it was clear
> IPv4 addresses were a scarce resource 2+ decades ago longer than
> some IETF attendees have been alive.  IPv6 was started because they
> were a scarce resource that would run out in the foreseeable future.
> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Meeting "lounges" at IETF meetings

[Paul Hoffman]

On Aug 3, 2012, at 11:22 AM, Mary Barnes wrote:

> Instead, I think we should ensure that future venues have adequate space for 
> both circulating between meeting rooms and for side conversations.

Just to be clear: you would rather that we pay higher meeting fees in exchange 
for that adequate space?

> I suggest that you could cut the cookie budget if funds really are the only 
> reason this wouldn't be done. 

That is one way to pay for the extra space; it might not be so popular in this 
particular crowd.

--Paul Hoffman

Re: ITU-T Dubai Meeting

[Mark Andrews]

In message , Daniel Karrenberg w
rites:
> 
> On 02.08.2012, at 22:41, Phillip Hallam-Baker wrote:
> 
> > ... That depends on whether the registry in question is dealing with a
> > scarce resource or a plentiful one. Having two registries handing out
> > IPv4 addresses at this point would be very very bad. Having more than
> > one place you can get an IPv6 from would not worry me at all. ...
> 
> IPv4 addresses used to be regarded as non-scarce not so long ago.

I don't know what planet you have been living on but it was clear
IPv4 addresses were a scarce resource 2+ decades ago longer than
some IETF attendees have been alive.  IPv6 was started because they
were a scarce resource that would run out in the foreseeable future.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Meeting "lounges" at IETF meetings

[Mary Barnes]

I don't like this idea at all.  For people that aren't staying at the
meeting hotel, the terminal room is often the only place where it is quiet.
 Ear plugs only partially address the problem for those of us with really
sensitive hearing and some folks cannot use those ear plugs (e.g., when you
have an ear infection, which I often get from the air conditioning in these
venues).

Instead, I think we should ensure that future venues have adequate space
for both circulating between meeting rooms and for side conversations.
 This hotel was really bad in that respect.  The corridor outside the
Regency rooms was always packed between sessions and getting from B to E
was impossible without bumping into people.  One problem was that people
stopped in the corridor for discussions, which is a normal thing to do at
IETF meetings, but it totally clogged up the hallways and often blocked the
access to the coffee.  This makes me wonder if the folks that choose the
venue discuss the nature of our meetings - i.e., almost everyone is moving
between meeting rooms multiple times a day.  Also, at least half the people
have backpacks and the majority are men.  Thus, the footprint for each of
us is larger than the average conference attendee.   I would suggest for
this next meeting at this hotel to put the refreshments in the open space
on the 3rd floor and put some chairs or tables in the alcoves and along the
wall where they put the refreshments.  Or better yet, reserve one of the
rooms for the refreshments and/or meeting space.  We had that at one of the
recent meetings and it worked extremely well.I suggest that you could
cut the cookie budget if funds really are the only reason this wouldn't be
done.

Mary.


On Fri, Aug 3, 2012 at 12:18 PM, Paul Hoffman  wrote:

> Greetings again. Some meeting venues have had insufficient places where
> five or so people could comfortably gather for informal meetings, while
> other venues did this just fine. One proposal has been that the Secretariat
> reserve large rooms for this. Unfortunately, that adds significant cost to
> the meetings.
>
> Instead, I propose that we simply designate the terminal room (which is
> already reserved for future meetings) be designated as meeting areas where
> talking is allowed / encouraged. Earplugs could be provided for people who
> really want a quiet Ethernet connection; the cost of those for the
> Secretariat will be about $25/meeting.
>
> --Paul Hoffman

Re: Basic ietf process question ...

[Mark Nottingham]

On 02/08/2012, at 1:11 PM, Brian E Carpenter  
wrote:

> I think anyone with intimate experience of the Web Services standards

I do, unfortunately.

Specifically: contributor to SOAP, WS-Addressing, WS-Policy, MTOM, lead editor 
of the WS-I Basic Profile, etc. (ad nauseum).


> experiment (trying to use XML as if it was a Turing machine) would have
> extreme doubts about any proposal to impose such a requirement.
> 
> It was not for no reason that many people came to refer to the Web
> Services family of standards as "WS-splat". The words "small" and
> "xml schema" don't really belong together,

+1

XML Schema is grossly over-engineered for its purpose; being the subject of 
requirements from not only the document markup field, but also databases and 
object models, it's a twisted monstrosity that tries to do many things, and 
fails at most.

Specifically, it's very common for people to try to use schema to inform 
"binding" tools into specific languages. However, the underlying metamodel of 
XML, the Infoset, is both complex and a poor fit for most languages, so 
bindings take "shortcuts" and expose a profile of XML's range of expression, 
encouraging some patterns of use, while discouraging (or disallowing) others. 
Since the bindings often make different decisions (based upon the language of 
use), interoperability is difficult (sometimes, impossible).

Furthermore, designing a schema that is extensible is incredibly convoluted in 
XML Schema 1.0. Schema 1.1 was designed to address this failure, but it hasn't 
been broadly adopted; most people I know in the field consider it a failure. 

What surprises me and many others is that people are still using it and 
promoting it, when it's well-understood by almost EVERYONE who was involved in 
using XML for protocols in the past ten years agrees that it's a mistake.

Cheers,


> 
> Regards
>   Brian Carpenter
> 
> On 02/08/2012 18:12, Robert Raszuk wrote:
>> Hi Dan,
>> 
>>> We should be talking
>>> nowadays about a toolset rather than one tool that fits all.
>> 
>> Just to clarify what I asked about .. I am not looking for a single tool
>> or single protocol to be used to configure everything.
>> 
>> I am asking for small building block like xml schema (or something
>> similar) to be part of each new IETF proposal or protocol change. IMHO
>> only that can allow any further more fancy abstractions and tools to be
>> build and used in practice.
>> 
>> Best regards,
>> R.
>> 
>> 
>> 
>>> Hi,
>>> 
>>> The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
>>> concerning the revision of RFC1052 and discussing a new architecture for
>>> management protocols.
>>> 
>>> 
>>> My personal take is that no one protocol, or one data modeling language
>>> can match the operational requirements to configure and manage the wide
>>> and wider range of hosts, routers and other network devices that are
>>> used to implement IP networks and protocols. We should be talking
>>> nowadays about a toolset rather than one tool that fits all. However,
>>> this is a discussion that just starts.
>>> 
>>> Regards,
>>> 
>>> Dan
>>> 
>>> 
>>> 
>>> 
 -Original Message-
 From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
>>> Of
 Robert Raszuk
 Sent: Thursday, August 02, 2012 7:25 PM
 Cc: ietf@ietf.org
 Subject: Basic ietf process question ...
 
 All,
 
 IETF documents have number of mandatory sections .. IANA Actions,
 Security Considerations, Refs, etc ...
 
 Does anyone have a good reason why any new protocol definition or
 enhancement does not have a build in mandatory "XML schema" section
 which would allow to actually use such standards based enhancement in
 vendor agnostic way ?
 
 There is a lot of talk about reinventing APIs, building network wide
>>> OS
 platform, delivering SDNs (whatever it means at any point of time for
 one) ... but how about we start with something very basic yet IMHO
 necessary to slowly begin thinking of network as one plane.
 
 I understand that historically we had/still have SNMP however I have
 never seen this being mandatory section of any standards track
>>> document.
 Usually SNMP comes 5 years behind (if at all) making it obsolete by
 design.
 
 NETCONF is great and very flexible communication channel for
 provisioning. However it is sufficient to just look at number of ops
 lists to see that those who tried to use it quickly abandoned their
 efforts due to complete lack of XML schema from each vendor they
>>> happen
 to use or complete mismatch of vendor to vendor XML interpretation.
 
 And while perhaps this is obvious I do not think that any new single
 effort will address this. This has to be an atomic and integral part
>>> of
 each WG's document.
 
 Looking forward for insightful comments ...
 
 Best,
 R.
 
>>> 
>>> 
>>> 
>> 
>> 

--
Mark 

Re: Meeting "lounges" at IETF meetings

[Scott Brim]

On Fri, Aug 3, 2012 at 10:18 AM, Paul Hoffman  wrote:
> Greetings again. Some meeting venues have had insufficient places where five 
> or so people could comfortably gather for informal meetings, while other 
> venues did this just fine. One proposal has been that the Secretariat reserve 
> large rooms for this. Unfortunately, that adds significant cost to the 
> meetings.
>
> Instead, I propose that we simply designate the terminal room (which is 
> already reserved for future meetings) be designated as meeting areas where 
> talking is allowed / encouraged. Earplugs could be provided for people who 
> really want a quiet Ethernet connection; the cost of those for the 
> Secretariat will be about $25/meeting.

Sounds good.

I volunteer to collect free headsets from airplanes and put them out
for people to take.

Meeting "lounges" at IETF meetings

[Paul Hoffman]

Greetings again. Some meeting venues have had insufficient places where five or 
so people could comfortably gather for informal meetings, while other venues 
did this just fine. One proposal has been that the Secretariat reserve large 
rooms for this. Unfortunately, that adds significant cost to the meetings.

Instead, I propose that we simply designate the terminal room (which is already 
reserved for future meetings) be designated as meeting areas where talking is 
allowed / encouraged. Earplugs could be provided for people who really want a 
quiet Ethernet connection; the cost of those for the Secretariat will be about 
$25/meeting.

--Paul Hoffman

Re: Progress with Open Internet endowment

[Russ Housley]

As of Friday morning, we are very close to the goal.  As of 9:00 AM this 
morning, we have $24,905 from 80 donors.  Please help if you can.

Thanks,
  Russ


On Aug 2, 2012, at 4:27 PM, Russ Housley wrote:

> Our current totals as of noon today, the Open Internet Endowment has received 
> $19,245 from 54 donors.  Thanks to all.
> 
> It would be great to reach $25,000 (or more) from 75 donors (or more) by 
> lunch tomorrow.  Please help if you can.
> 
> There will be a table at the Bits-N-Bites tonight.  People will be at the 
> table to answer any questions you might have.
> 
> Thanks,
>  Russ
> 

Re: [OPSAWG] Basic ietf process question ...

[Randy Presuhn]

Hi -

> From: "Andy Bierman" 
> To: "Romascanu, Dan (Dan)" 
> Cc: ; 
> Sent: Thursday, August 02, 2012 10:13 AM
> Subject: Re: [OPSAWG] Basic ietf process question ...
...
> NMS developers need to spend too many resources on translating
> naming and other data-modeling specific details so they can be
> usable within the application.  So if 1 data modeling language
> is not used, then deterministic, loss-less, round-trip translation
> between data modeling languages is needed.  Multiple
> protocols are not the problem -- incompatible data from multiple
> protocols is the problem.
...

Picking a single language or set of round-trip translatable languages
also isn't enough.  Its a fact of life that vendors will produce
models and implementations that are slightly, or even radically different.
The differences aren't necessarily even intentional, but nonetheless
introduce the need to talk about "similar" models and "operationally
equivalent" configurations, where the transformations needed to go
from what will do the job on one piece of equipment to what will
work on another may be substantial.  (From an implementation perspective
it might be better to think in terms of transformations necessary to go
from a common model of desired operational characteristics to the
dial tweaks and button pokes necessary to get a device to do the right
thing.)  Since great minds often think alike, even in the absence
of standards, there is not necessarily a formal "derived from" or
"subclass" or "common aspect" relationship between the definitions.
This may be an obvious use case for XSLT, but as far as I know nothing
has been done about *standardizing* such usage, other than discussions at the
IAB workshop oh-so-many years ago, and some ISO/ITU discussions in
the 1990s about eventual applications of the General Relationship
Model and the management domain/policy stuff in GDMO land.

Randy

Re: ITU-T Dubai Meeting

[Dmitry Burkov]

I hope too as they still ignore the procedures

Sent from my iPhone

On 03.08.2012, at 19:37, David Conrad  wrote:

> On Aug 2, 2012, at 12:55 PM, SM  wrote:
>> If the ITU-T wants a /16 it is simply a matter of asking the IETF for it.
> 
> And, unless the reason the ITU-T was requesting the /16 was for some protocol 
> that came up with that has global applicability that needed a /16 of IPv6 
> space, they'd be redirected to an RIR.
> 
> Regards,
> -drc
> 

Re: [OPSAWG] Basic ietf process question ...

[Juergen Schoenwaelder]

On Fri, Aug 03, 2012 at 04:31:42PM +0200, Robert Raszuk wrote:
> 
> But if we are at this phase I think creating a network elements
> abstraction layer and be able to configure/monitor any protocol and
> service at the unified way is one of the building blocks we should
> start with. And of course I think this is very clear to everyone if
> it is not made mandatory in each draft as new section or appendix it
> is just not going to happen in practice.
> 

Writing data models that are implementable on multiple platforms is
non trivial. We started working on your "building block" but it will
take time. And after all, a data model is only worth something if it
gets implemented.  A mandatory section does not help much with all of
this. What helps is people who commit time to work on it, who review
stuff, producing good and hopefully widely implementable models.

/js

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

Re: [OPSAWG] Basic ietf process question ...

[Juergen Schoenwaelder]

On Fri, Aug 03, 2012 at 09:22:10AM +0200, Robert Raszuk wrote:
> 
> Aha .. so you are saying that MIBs are not mandatory  Very
> interesting. So I guess SSH to the routers and box by box cli
> provisioning is here to stay for a while I think :(
> 

Robert,

you may want to take a closer look at the data models currently being
defined in the NETMOD working group. Please review them and send any
comments.

/js

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

Re: Proposed IETF 95 Date Change

[Kuor-Hsin . Chang]

I am fine with the date change but please coordinate with IEEE802 to make 
sure there is no conflict.

Best,

Kuor Hsin Chang



From:
IETF Administrative Director 
To:
IETF Announcement List , 
Cc:
i...@ietf.org, i...@iab.org, ietf@ietf.org, wgcha...@ietf.org, 
i...@ietf.org
Date:
08/02/2012 09:48 AM
Subject:
Proposed IETF 95 Date Change
Sent by:
ietf-announce-boun...@ietf.org



A reminder of the 6 August deadline for input.
Thanks

The IAOC is seeking community feedback on a proposed date change for IETF 
95
scheduled for March 2016.

Currently IETF 95 is scheduled for 27 March to 1 April 2016.  27 March is 
Easter.

The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and 
would like 
feedback on those dates before making a decision.  Comments appreciated to 
ietf@ietf.org 
by 6 August 2012.

Ray Pelletier
IETF Administrative Director

__
This email has been spam and virus checked by Elster IT Services.

Re: Basic ietf process question ...

[Joe Hildebrand (jhildebr)]

On 8/2/12 9:25 AM, "Robert Raszuk"  wrote:

>Does anyone have a good reason why any new protocol definition or
>enhancement does not have a build in mandatory "XML schema" section
>which would allow to actually use such standards based enhancement in
>vendor agnostic way ?

For docs that use XML, requiring some form of schema makes sense.
However, what we're finding at the application layer is that often times
using JSON (see RFC 4627) ends up with better interoperability more
quickly than using XML, except in the case of human-readable content like
marked-up text.  See RFC 6120, Appendix A (http://goo.gl/CBv8G) for
another example.

For those that insist on XML, RelaxNG (http://goo.gl/MYnB1) is another
language you can use to describe your XML, which is a little easier to
learn than XSD.

However, for implementors, if you start with the schema and blindly use it
for conformance checking of real-world traffic, you are likely to have
both performance and extensibility issues in practice.

If folks at other layers in the stack would like input from Apps folks,
I'm sure that we would be happy to share our lessons learned.  Join
apps-discuss (http://goo.gl/0Otjv) and ask for help.

-- 
Joe Hildebrand

Proposed IETF 95 date change

[John William Atwood]

It's not clear to me which is less desirable, starting on Easter day, or
finishing on Good Friday.  Both are important from the Christian
perspective.  However, for a significant part of the IETF membership,
neither Easter nor Good Friday is important.  My vote would be to leave
it where it is.

  Bill Atwood

-- 
Dr. J.W. Atwood, Eng. tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185 email:william.atw...@concordia.ca
1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

Re: [OPSAWG] Basic ietf process question ...

[David Harrington]

+1

--
David Harrington
ietf...@comcast.net
+1-603-828-1401





On 8/2/12 12:59 PM, "Romascanu, Dan (Dan)"  wrote:

>Hi,
>
>The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
>concerning the revision of RFC1052 and discussing a new architecture for
>management protocols.
>
>
>My personal take is that no one protocol, or one data modeling language
>can match the operational requirements to configure and manage the wide
>and wider range of hosts, routers and other network devices that are
>used to implement IP networks and protocols. We should be talking
>nowadays about a toolset rather than one tool that fits all. However,
>this is a discussion that just starts.
>
>Regards,
>
>Dan
>
>
>
>
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
>Of
>> Robert Raszuk
>> Sent: Thursday, August 02, 2012 7:25 PM
>> Cc: ietf@ietf.org
>> Subject: Basic ietf process question ...
>> 
>> All,
>> 
>> IETF documents have number of mandatory sections .. IANA Actions,
>> Security Considerations, Refs, etc ...
>> 
>> Does anyone have a good reason why any new protocol definition or
>> enhancement does not have a build in mandatory "XML schema" section
>> which would allow to actually use such standards based enhancement in
>> vendor agnostic way ?
>> 
>> There is a lot of talk about reinventing APIs, building network wide
>OS
>> platform, delivering SDNs (whatever it means at any point of time for
>> one) ... but how about we start with something very basic yet IMHO
>> necessary to slowly begin thinking of network as one plane.
>> 
>> I understand that historically we had/still have SNMP however I have
>> never seen this being mandatory section of any standards track
>document.
>> Usually SNMP comes 5 years behind (if at all) making it obsolete by
>> design.
>> 
>> NETCONF is great and very flexible communication channel for
>> provisioning. However it is sufficient to just look at number of ops
>> lists to see that those who tried to use it quickly abandoned their
>> efforts due to complete lack of XML schema from each vendor they
>happen
>> to use or complete mismatch of vendor to vendor XML interpretation.
>> 
>> And while perhaps this is obvious I do not think that any new single
>> effort will address this. This has to be an atomic and integral part
>of
>> each WG's document.
>> 
>> Looking forward for insightful comments ...
>> 
>> Best,
>> R.
>> 
>
>___
>OPSAWG mailing list
>ops...@ietf.org
>https://www.ietf.org/mailman/listinfo/opsawg

Re: Proposed IETF 95 Date Change

[Philip Matthews]

I would personally prefer if the meeting was rescheduled for the week of April 
3 - 8.
- Philip

On 2012-08-02, at 9:45 , IETF Administrative Director wrote:

> The IAOC is seeking community feedback on a proposed date change for IETF 95
> scheduled for March 2016.
> 
> Currently IETF 95 is scheduled for 27 March to 1 April 2016.  27 March is 
> Easter.
> 
> The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would 
> like 
> feedback on those dates before making a decision.  Comments appreciated to 
> ietf@ietf.org 
> by 6 August 2012.

Re: [OPSAWG] Basic ietf process question ...

[Andy Bierman]

On Thu, Aug 2, 2012 at 9:59 AM, Romascanu, Dan (Dan)  wrote:
> Hi,
>
> The OPSAWG/OPSAREA open meeting this afternoon has an item on the agenda
> concerning the revision of RFC1052 and discussing a new architecture for
> management protocols.
>
>
> My personal take is that no one protocol, or one data modeling language
> can match the operational requirements to configure and manage the wide
> and wider range of hosts, routers and other network devices that are
> used to implement IP networks and protocols. We should be talking
> nowadays about a toolset rather than one tool that fits all. However,
> this is a discussion that just starts.

NMS developers need to spend too many resources on translating
naming and other data-modeling specific details so they can be
usable within the application.  So if 1 data modeling language
is not used, then deterministic, loss-less, round-trip translation
between data modeling languages is needed.  Multiple
protocols are not the problem -- incompatible data from multiple
protocols is the problem.

>
> Regards,
>
> Dan
>

Andy

>
>
>
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf
> Of
>> Robert Raszuk
>> Sent: Thursday, August 02, 2012 7:25 PM
>> Cc: ietf@ietf.org
>> Subject: Basic ietf process question ...
>>
>> All,
>>
>> IETF documents have number of mandatory sections .. IANA Actions,
>> Security Considerations, Refs, etc ...
>>
>> Does anyone have a good reason why any new protocol definition or
>> enhancement does not have a build in mandatory "XML schema" section
>> which would allow to actually use such standards based enhancement in
>> vendor agnostic way ?
>>
>> There is a lot of talk about reinventing APIs, building network wide
> OS
>> platform, delivering SDNs (whatever it means at any point of time for
>> one) ... but how about we start with something very basic yet IMHO
>> necessary to slowly begin thinking of network as one plane.
>>
>> I understand that historically we had/still have SNMP however I have
>> never seen this being mandatory section of any standards track
> document.
>> Usually SNMP comes 5 years behind (if at all) making it obsolete by
>> design.
>>
>> NETCONF is great and very flexible communication channel for
>> provisioning. However it is sufficient to just look at number of ops
>> lists to see that those who tried to use it quickly abandoned their
>> efforts due to complete lack of XML schema from each vendor they
> happen
>> to use or complete mismatch of vendor to vendor XML interpretation.
>>
>> And while perhaps this is obvious I do not think that any new single
>> effort will address this. This has to be an atomic and integral part
> of
>> each WG's document.
>>
>> Looking forward for insightful comments ...
>>
>> Best,
>> R.
>>
>
> ___
> OPSAWG mailing list
> ops...@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg

RE: New Version Notification for: draft-baryun-rfc2119-update-00.txt

[Adrian Farrel]

> A Change to the interpretation of normative language does not
> retroactively apply to existing documents.

Shucks! Really?

I was hoping I could automatically change the behavior of deployed routers by
updating the meaning of some words in published RFCs. You mean I can't do that?

A

Re: RFC Errata: when to file, and when not to

[Barry Leiba]

>
> > Of course we have mailing lists, issue trackers, and wikis, but the
> > problem is that none of them are for RFCs.
>
> In addition, those tools seem to be intended rather for IETF internal
> use than for general public.


I would say that "IETF internal use" would refer to chairs, ADs, the RFC
Editor (which is not a function that's part of the IETF, by the way), and
so on.  It's very easy for anyone, including my mother, should she want to,
to get a login to the IETF tools system.  We could perhaps make it more
obvious that one is needed, and how to do it, but I don't know that it's
any more of a hurdle than any of the 17,000 other web things that require a
"free one-time signup".

Anyway, as I said, we haven't sorted out how we would do this, and it might
be that something even easier than what we have now would be in order.


> It is /not difficult/ to find errata.  "Easy" would mean that people
> usually find them even if they're not purposely looking for them.  For
> example, the existence of an approved errata could be signaled by
> coloring the margin near the relevant text.
>

I like this idea.  Not colour, maybe -- despite the errata tool's format,
not all errata nicely fit into OLD/NEW text, and one often needs the
explanation even for those that do -- but perhaps an "errata" icon in the
margin next to the relevant text.  One could click the icon and be sent
straight to that erratum.

The trouble is that I can't see how we could do that automatically, so it
would require significant extra manual processing.  I don't have stats on
how many errata are "Verified" (and we'd only do this sort of thing for
those, I imagine), nor any real idea of how much extra work it would be for
someone to add the erratum links.  But no argument at all about how useful
it would likely be.

Barry

Re: ITU-T Dubai Meeting

[David Conrad]

On Aug 2, 2012, at 12:55 PM, SM  wrote:
> If the ITU-T wants a /16 it is simply a matter of asking the IETF for it.

And, unless the reason the ITU-T was requesting the /16 was for some protocol 
that came up with that has global applicability that needed a /16 of IPv6 
space, they'd be redirected to an RIR.

Regards,
-drc

Re: RFC Errata: when to file, and when not to

[Alessandro Vesely]

On Thu 02/Aug/2012 03:28:38 -0700 Martin J. Dürst wrote:
> 
>> In particular, the errata system is NOT meant to be used as an issue
>> tracker;
> 
> Of course we have mailing lists, issue trackers, and wikis, but the
> problem is that none of them are for RFCs.

In addition, those tools seem to be intended rather for IETF internal
use than for general public.

> The question then comes up on whether we can do better. And my guess
> is that in this day and age of linked information, we should be able
> to do better. With the tools version of an RFC, which is quickly
> becoming the preferred version of many, it's already easy to find errata.

It is /not difficult/ to find errata.  "Easy" would mean that people
usually find them even if they're not purposely looking for them.  For
example, the existence of an approved errata could be signaled by
coloring the margin near the relevant text.

Re: [OPSAWG] Basic ietf process question ...

[Robert Raszuk]

Hi Juergen,

Many thx for the great suggestion !

However perhaps you are much more knowledgeable in that area and could 
recommend which model fit the best the requirement to standardize 
configuration of any new protocol or protocol extension at least in the 
space of routing and routing protocols or services being based on them ?


As you know the current IRS framework driven by junisco is trying to 
come with common API to the routing system agreed across vendors. This 
is great as attempts never happened in the past.


But if we are at this phase I think creating a network elements 
abstraction layer and be able to configure/monitor any protocol and 
service at the unified way is one of the building blocks we should start 
with. And of course I think this is very clear to everyone if it is not 
made mandatory in each draft as new section or appendix it is just not 
going to happen in practice.


Best regards,
R.


On Fri, Aug 03, 2012 at 09:22:10AM +0200, Robert Raszuk wrote:


Aha .. so you are saying that MIBs are not mandatory  Very
interesting. So I guess SSH to the routers and box by box cli
provisioning is here to stay for a while I think :(



Robert,

you may want to take a closer look at the data models currently being
defined in the NETMOD working group. Please review them and send any
comments.

/js

Re: ITU-T Dubai Meeting

[Ole Jacobsen]

Plug:

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_15-2/ipj_15-2.pdf

Read the article "December in Dubai," I think you will find it 
interesting.

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj
Skype: organdemo

Re: Proposed IETF 95 Date Change

[t . p .]

- Original Message -
From: "Andrew G. Malis" 
To: "IETF Administrative Director" 
Cc: "IETF Discussion" 
Sent: Thursday, August 02, 2012 10:42 PM
Subject: Re: Proposed IETF 95 Date Change

>
On the
> other hand, travel on 27 March should be relatively easy.

Precisely, which makes the original dates better for travel than the
proposed alteration.  This is a relatively early (Easter) holiday, which
makes the run up to it frantic, so trying to get home on the
24th/25th/26th
I would expect to be a nightmare, whereas the following week will be
relatively quiet.

Stay with the original dates.

Tom Petch

>
> Cheers,
> Andy
>
> On Thu, Aug 2, 2012 at 9:45 AM, IETF Administrative Director
>  wrote:
> > A reminder of the 6 August deadline for input.
> > Thanks
> >
> > The IAOC is seeking community feedback on a proposed date change for
IETF 95
> > scheduled for March 2016.
> >
> > Currently IETF 95 is scheduled for 27 March to 1 April 2016.  27
March is Easter.
> >
> > The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016
and would like
> > feedback on those dates before making a decision.  Comments
appreciated to ietf@ietf.org
> > by 6 August 2012.
> >
> > Ray Pelletier
> > IETF Administrative Director
>

Re: ITU-T Dubai Meeting

[Patrik Fältström]

3 aug 2012 kl. 09:18 skrev Brian E Carpenter :

> Exactly. It is intended to defeat the Internet's historical growth model
> of independence from national administrations and monopolies, by imposing
> a geographical addressing scheme. Since the Internet actually works with
> a topological addressing scheme, the effect is to force the topology
> to be congruent with the geography. If you want central control, that's
> a desirable result.

The key here is control.

Innovation in the core, or at the edge.

License/politically based or need based allocation.

The rest is implementation.

   Patrik

Re: Basic ietf process question ...

[Robert Raszuk]

Hello Brian,


That's an enormous leap that I just don't understand. Most protocols don't
need that sort of configuration complexity.


H I am of the opinion that most protocols requires configuration. I 
am also of the opinion that each vendor chooses an original way to 
configure their network elements.


Therefor if you do not define up front a standard based of configuring 
given routing protocol you will end up with exactly what we have today 
.. zoo of various different CLI commands to enable the exact same 
protocol across more then one vendor box.


Are you saying that this is ok ?

Or are you saying that there is simpler way to enable netconf based 
unified way to configure protocols and services on your network other 
then providing per component "xml schema" with subsequent schema 
extensions as part of IETF standardization process ?


To make it a bit more explicit ... do you really need to study 5 user 
manuals or google 5 times to enable IGP or BGP or even configure NTP 
across 5 different router OS running in your network ???


> Again: no problem with creating XML schemata where they are useful.
> But making them mandatory would be just as bad as making MIB modules
> mandatory, IMHO.

Aha .. so you are saying that MIBs are not mandatory  Very 
interesting. So I guess SSH to the routers and box by box cli 
provisioning is here to stay for a while I think :(


Best regards,
R.

Re: ITU-T Dubai Meeting

[Brian E Carpenter]

On 02/08/2012 21:30, Steven Bellovin wrote:
> On Aug 2, 2012, at 1:24 PM, David Conrad wrote:
> 
>> On Aug 2, 2012, at 11:44 AM, j...@mercury.lcs.mit.edu (Noel Chiappa) wrote:
 we should instead focus on the ways that the technical architecture of
 the Internet creates control points that are vulnerable to capture and
 consider ways in which those control points can be made capture-proof.
>>> Agreed.
>> The challenge of course is that one of the simple/efficient mechanisms to 
>> implement desirable features (e.g., security, scalability, manageability) is 
>> to create hierarchies, but those very hierarchies provide control points 
>> that can (at least in theory) be captured.  The DNS root is one such, the 
>> proposed RPKI root is another.  Perhaps a variation of the Software 
>> Engineering Dilemma ("fast, good, cheap: pick two") applies to Internet 
>> architecture: secure, scalable, manageable: pick two?
>>
 If the ITU-T wants to also be in the business of handing out IPv6
 address names then give then a /21 or a /16 and tell them to go
 party.
>> I don't think this is what the ITU is after.  My impression is that the ITU 
>> is arguing that member states should get the / directly.
>>
>>> I basically agree. It could have negative impacts on the routing, by 
>>> impacting
>>> route aggregatability, but it can hardly be worse that those bletcherous PI
>>> addresses, so if it makes them happy to be in charge of a large /N, why not?
>> I believe the routing scalability risk lies not in the allocation body, but 
>> rather the policies imposed around the allocations.  That is, imagine a 
>> world of 200+ National Internet Registries instead of 5 Regional Internet 
>> registries.  If the government behind an NIR then decides that to use the 
>> Internet in their country, you must use addresses allocated by the NIR of 
>> that country, you then run the risk of having 200+ prefixes for each entity 
>> that operates globally.  This risk could be addressed if it didn't matter 
>> where you get your addresses, however that isn't true with the existing 
>> model and there are political pressures that would likely ensure that it 
>> would not be true in the NIR model.
> 
> 
> It also implies entry into a country through a few official gateways/exchange 
> points -- that way, there are only ~200 entries plus your own country's that 
> you need in your RIB...  (Telecom used to be that way -- PTTs and other 
> monopolies (e.g., AT&T) loved it.)

Exactly. It is intended to defeat the Internet's historical growth model
of independence from national administrations and monopolies, by imposing
a geographical addressing scheme. Since the Internet actually works with
a topological addressing scheme, the effect is to force the topology
to be congruent with the geography. If you want central control, that's
a desirable result.

It isn't a harmless concession. We've been playing whack-a-mole against
this for a number of years now.

   Brian Carpenter