RE: Proposed IETF 95 Date Change

[Yaakov Stein]

> By cutting the sunrise-to-sunset fasting period of the day to a much shorter 
> period.

Actually, the first day of this IETF (and the last of IETF54) were very 
interesting 
for those fasting on the 9th of Av fast day and having to travel westwards.

Flying west during the fast increases its duration,
for example from Jerusalem to Vancouver there is a 10 hour time zone difference,
so instead of 25 hours the fast increases to 35 hours without food or water.

Y(J)S

RE: RFC 2119 terms, ALL CAPS vs lower case

[Yaakov Stein]

> And of course if we had a slightly richer publication format we could 
> use, oh, say, underline, bold, italics and maybe even a special font 
> for normative terms, but I guess I am dreaming decades ahead...

I was waiting to see if someone was going to bring this up.

In Roman law, the way you capitalized something in a document could have 
significant consequences,
for example, incorrect use of Capitis Diminutio could change you from a free 
person into a slave!

OTOH, the Uniform Commercial Code requires certain terms be rendered 
"conspicuous",
which may be accomplished though capitalization, or using bold face, or a 
larger font, or contrasting color, etc.

The intervening 2000 years enabled the UCC to exploit more modern typesetting 
technologies.

But the IETF is still living in Roman times.

Y(J)S

RE: Gender diversity in engineering

[Yaakov Stein]

> Around 30%-40%. I don't have hard numbers, 
> but I have a feeling that it has gone down a bit in the last 10 years. 

Yoav, 

Your feelings are quite accurate as to the range,
but less so regarding the trend.
According to a recent study, 35.6% of high-tech employees in Israel are women,
and this percentage has been relatively stable for the past 10 years.

Women make up 47.5% of all employees with academic credentials (as of 2010) in 
all sectors,
so high-tech is actually comparatively under-represented.
On the other hand, only 32.9% of managerial positions (in all sectors)
are occupied by women.

Y(J)S

RE: 'Geek' image scares women away from tech industry ? The Register

[Yaakov Stein]

> What if teachers were measured on a survey at the end of a semester or a year 
> that asked "does teacher <> make <> interesting to you?".

Feynman recollected that when he returned from school his mother never asked 
him if he answered the teacher's questions correctly,
rather if he asked any interesting questions.

Y(J)S

RE: Protocol Definition

[Yaakov Stein]

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

RE: Protocol Definition

[Yaakov Stein]

X.200 - ITU's version of the OSI model - defines an "association" as peering at 
any layer of the OSI stack.
Thus an association at layer 3 is a pair of IP addresses, while an association 
at layer 4 is a pair of socket IDs.
If the association is requested then it becomes a "connection".
A "session" is an association at layer 5.

A process in computation is defined as an entity that is independent 
in the sense that it can request and own resources (e.g., CPU time and memory).
Many processes can exist side by side, and can even communicate via IPC,
but processes do not have a hierarchy such as we have in communications.
The closest thing is the fact that processes can own tasks or threads as 
sub-entities
(tasks are not indendent - their memory and CPU time are taken from their 
father process).

Just as an association runs protocols at different layers, a single process 
frequently runs multiple algorithms.
But these algorithms are usually not layered.

A protocol between two entities often involves algorithms on both sides,
but an association does not necessarily link two processes on the communicating 
sides.

Y(J)S


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave 
CROCKER
Sent: Friday, January 06, 2012 05:03
To: Dave Cridland
Cc: IETF-Discussion
Subject: Re: Protocol Definition



On 1/5/2012 1:41 PM, Dave Cridland wrote:
> Association, to my mind, means a transport layer connection, hence it's usage 
> in
> SNMP and other OSI-related things.
>
> Session isn't much less damaged, as a term, I admit, but it is in common 
> usage.
> And like algorithms, and protocols, you can open up a session to find other
> sessions inside.


Actually, my recollection is that 'association' was an application-level 
construct from OSI.

But I came to the same conclusion as you:  "session" is an established term in 
IETF parlance and has the basic reality of describing a protocol in operation 
between two (or more?) hosts/endsystems/endpoints/...

Does this resonate with others?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Protocol Definition

[Yaakov Stein]

A protocol is to communications what an algorithm is to computation.

Y(J)S

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ole 
Jacobsen
Sent: Wednesday, January 04, 2012 03:59
To: Kaushal Shriyan
Cc: ietf@ietf.org
Subject: Re: Protocol Definition


In very simple terms: A protocol is a set of rules for interaction. In 
this case the interaction is between computers. This can involve both 
hardware and software and protocols define the interactions as well as 
the "formats" (bits on the wire etc).

For a much more comprehensive definition, see:

http://en.wikipedia.org/wiki/Communications_protocol

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 Wed, 4 Jan 2012, Kaushal Shriyan wrote:

> Hi,
> 
> Can someone please explain me the term "Protocol". Does it also mean it has
> some software code underlying beneath it. Please help me understand.
> 
> Regards,
> 
> Kaushal
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: discouraged by .docx was Re: Plagued by PPTX again

[Yaakov Stein]

> Perhaps because no one actually reads RFC's on these small devices,
> and so we've been trolled by a master into worrying about a use case
> which isn't really a problem.

I, for one, regularly (attempt to) read RFCs and other standards on small 
devices.

I do this because I have stopped shlepping a laptop to short meetings.
(I still take a laptop to week-long conferences like the IETF,
 but that is because I can't afford not working on day-job tasks.)

Frequently I am sitting in a lecture or discussion and something comes up that 
I want to check. 
Of course epubs and similar screen-size-aware formats are optimal,
but doc, docx, ppt, pptx, and most HTML are very reasonable.
PDF is workable but requires a lot of pan/zoom effort.
Text RFCs are completely impossible to read.

I have experimented with TeX and LaTeX (source text), 
and can get it to work very well on A5 format pads,
and reasonably well on smaller devices. 
The main problem with the smaller devices derives figures that
are not in native TeX or eps, but rather imported from gif or jpg.
(I haven't tried SVG, but assume that it would work similarly to embedded 
postscript.)

BTW, there is a great algorithm for shrinking relatively sparse images
that conserves structure even if the text becomes too small to read;
but even it breaks down at some point.

I was thinking about hacking around with our xml format,
but realized that the ASCII art problem is a show-stopper.
It would be easy to detect the special cases, but what would I do about them ?
The obvious answer - simply treating them as fixed length 
and reducing the size, doesn't produce useful figures.
Unlike native TeX diagrams where the graphic elements are in markup language,
here multiple special visual characters (like > for an arrow head) effectively 
disappear.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: reading on small devices, was discouraged by .docx

[Yaakov Stein]

The time interval between ASCII text threads seems to be decreasing over time.

Perhaps when half of the traffic on the discussion list is related to this 
question
something will finally be done.

Y(J)S

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
Christian Huitema
Sent: Monday, November 28, 2011 08:00
To: Richard Shockey; 'John Levine'; ietf@ietf.org
Cc: ty...@mit.edu
Subject: RE: reading on small devices, was discouraged by .docx

Do we have an official web page listing the timings of the "ASCII text RFC" 
discussions? It ought to tell us something about the state of the IETF...

-- Christian Huitema




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]

[Yaakov Stein]

> That would work too.  I added a third URL that returns
> text/plain;format=fixed;line-length=72

> http://ietf.implementers.org/fixed/rfc5928.txt

That is the worst option for my two devices. 
On both devices the line wraps distort the tables beyond recognition.

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]

[Yaakov Stein]

Marc

I opened the link on two different devices,
to see how the tables rendered.

On one (iPod touch with Safari), it worked reasonably. 
The only problem was that the table columns were skewed
due to browser not using monospace fonts. Were the table more complex
or were there some truly wacky ASCII art it probably wouldn't have worked.

On a second device (running a different browser, unnamed to protect the guilty)
I received a continuous stream of characters with no line breaks at all.
When viewing the txt version on www.rfc-editor.org that same browser 
does a fairly good job, assuming that I rotate the device to fit the
table into the width.

However, these 2 tables were small and relatively simple.
Why don't you try Figure 3 of RFC 5087 or Figure 2 or 15 of RFC 5905 ?


Y(J)S


-Original Message-
From: Marc Petit-Huguenin [mailto:petit...@acm.org] 
Sent: Sunday, November 27, 2011 18:20
To: Yaakov Stein
Cc: Dave Aronson; IETF Discussion
Subject: text/lp [was Re: discouraged by .docx was Re: Plagued by PPTX again]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The problem here is that RFC and Internet-Drafts are not plain ASCII.  They are
technically in a special format that I would call "line-printer ready text
file", and ASCII is the encoding, not the format.  What is needed is:

- - A mime-type for line-printer ready text (say text/lp)
- - An heuristic to recognize text/lp files (it's too late for a specific
extension).  Apache HTTP server can use the AddType directive for these 
files[1].
- - A program to display text/lp files, one at least for each platform.  If
someone take care of the mime-type, I'll write the program to display correctly
text/lp files on the Android platform.


[1] Try this link: http://ietf.implementers.org/rfc5928.txt.  The mime type
should be text/lp.

On 11/27/2011 12:20 AM, Yaakov Stein wrote:
> Dave
> 
> I agree that we are thinking as "content creators", and that is the problem.
> 
> The requirement is not that we will be able to write a new document in 50 
> years in the same format. 
> The requirement is that we should be able to read the documents written 50 
> years before.
> 
> The problem about ASCII art is not simply the monospacing.
> The main problem is the line wrapping.
> 
> I have tried many times to look at ASCII art on iPhones, iPods, and even 
> small pads. 
> Once you zoom down sufficiently to get the lines not to break, 
> the characters are no longer readable.
> For a screen size of about 60 mm, 80 character lines means that the 
> characters are only 0.75mm in width.
> Even assuming a "short" figure that could be viewed rotated (width 110 mm)
> each character width would be only slightly more than the 1 mm needed for 
> viewing,
> and less than the 1.5 mm needed for actual reading.
>  
> Put in another way, high-end cellphone screens presently have 640 pixel 
> widths.
> For 80 character layouts, this translates to 8 pixels per character plus 
> inter-character spacing,
> or about 6 pixel character widths. 
> Even were they visible (and each pixel is less than 1/10 of a mm!)
> this would mean very low quality fonts - 5*7 was the lowest quality used by 
> old dot-matrix printers.
> And modern software is not optimized for readability at that font resolution.
> 
> So, if we expect people to be able to read our documents in 5 years, let 
> alone 50,
> we need to stop using ASCII art.
> 
> Y(J)S
> 
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave 
> Aronson
> Sent: Sunday, November 27, 2011 00:10
> To: IETF Discussion
> Subject: Re: discouraged by .docx was Re: Plagued by PPTX again
> 
> On Sat, Nov 26, 2011 at 15:52, Yaakov Stein  wrote:
> 
>> ASCII is already unreadable on many popular devices
> 
> Oh?  For what reason?  Sorry, I'm still using an incredibly stupid
> phone, so I may be behind the curve on such changes.  As far as I've
> seen in my limited exposure, any difficulty is usually because it's
> often not linewrapped well (or at all), forcing a lot of horizontal
> scrolling, especially after being forced to be big enough to be
> legible on tiny screens not held right up to the face.  That's rather
> inconvenient, but still a far cry from "unreadable" -- plus it's a
> problem with the reader program (being too "featureless" to rewrap the
> text), not anything inherent in the format.
> 
> ASCII *artwork*, yes, that often gets ruined by the refusal of many
> programs to allow the user  to display content in a monospaced font.
> But that's not because it's in plain ASCII; you could say the same
> thing of a Word or PDF document that incorporates "ASCII" art.
> 
>&g

RE: discouraged by .docx was Re: Plagued by PPTX again

[Yaakov Stein]

Dave

I agree that we are thinking as "content creators", and that is the problem.

The requirement is not that we will be able to write a new document in 50 years 
in the same format. 
The requirement is that we should be able to read the documents written 50 
years before.

The problem about ASCII art is not simply the monospacing.
The main problem is the line wrapping.

I have tried many times to look at ASCII art on iPhones, iPods, and even small 
pads. 
Once you zoom down sufficiently to get the lines not to break, 
the characters are no longer readable.
For a screen size of about 60 mm, 80 character lines means that the characters 
are only 0.75mm in width.
Even assuming a "short" figure that could be viewed rotated (width 110 mm)
each character width would be only slightly more than the 1 mm needed for 
viewing,
and less than the 1.5 mm needed for actual reading.
 
Put in another way, high-end cellphone screens presently have 640 pixel widths.
For 80 character layouts, this translates to 8 pixels per character plus 
inter-character spacing,
or about 6 pixel character widths. 
Even were they visible (and each pixel is less than 1/10 of a mm!)
this would mean very low quality fonts - 5*7 was the lowest quality used by old 
dot-matrix printers.
And modern software is not optimized for readability at that font resolution.

So, if we expect people to be able to read our documents in 5 years, let alone 
50,
we need to stop using ASCII art.

Y(J)S

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave 
Aronson
Sent: Sunday, November 27, 2011 00:10
To: IETF Discussion
Subject: Re: discouraged by .docx was Re: Plagued by PPTX again

On Sat, Nov 26, 2011 at 15:52, Yaakov Stein  wrote:

> ASCII is already unreadable on many popular devices

Oh?  For what reason?  Sorry, I'm still using an incredibly stupid
phone, so I may be behind the curve on such changes.  As far as I've
seen in my limited exposure, any difficulty is usually because it's
often not linewrapped well (or at all), forcing a lot of horizontal
scrolling, especially after being forced to be big enough to be
legible on tiny screens not held right up to the face.  That's rather
inconvenient, but still a far cry from "unreadable" -- plus it's a
problem with the reader program (being too "featureless" to rewrap the
text), not anything inherent in the format.

ASCII *artwork*, yes, that often gets ruined by the refusal of many
programs to allow the user  to display content in a monospaced font.
But that's not because it's in plain ASCII; you could say the same
thing of a Word or PDF document that incorporates "ASCII" art.

> I am referring to the fact that more and more people are reading
> documents on cell-phones and other small devices.
> According to analysts, this will be the most popular platform for reading
> material from the Internet within a few years.

But among what audience?  End-users at large, yes, I can certainly
believe that.  But techies, especially of sufficient caliber to even
*want* to read the IETF's output, let alone participate in creating
it?  Very doubtful.  I don't think we'll be giving up our laptops,
never mind large monitors, any time soon.

Phones and tablets are for content *consumption*.  We are content
*creators*, be it programs, documents, or whatever.  That's an
entirely different set of hardware requirements.  When was the last
time you saw a program or document or anything else of significant
size, written using a phone, or even a tablet?

-Dave

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: discouraged by .docx was Re: Plagued by PPTX again

[Yaakov Stein]

> That leaves ASCII, a few forms of PDF, and RFC 5198-conforming UTF-8.   
> That wouldn't bother me much, but be careful what you wish form.

What we have been told is that the rationale behind the use of ASCII and 
several other formats
is that they will remain readable on devices that will be used X years hence.

ASCII is already unreadable on many popular devices
and in a few years will be no better than old versions of word.

I am referring to the fact that more and more people are reading
documents on cell-phones and other small devices.
According to analysts, this will be the most popular platform for reading
material from the Internet within a few years.

The ASCII art used in RFCs becomes hopelessly mangled and unreadable,
while the rest of the text is merely hard to read.

On the other hand, were the figures to be in any format that preserves their 
integrity, 
one would see a small depiction that could be enlarged as necessary.

So I suggest removing ASCII from the list,
as ASCII art will not be readable on mainstream devices in the near future.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Plagued by PPTX again

[Yaakov Stein]

If we are deposed we may need to deliver up everything we have, as we have it.

We are under no obligation to deliver blue sheets in ASCII readable form
(in fact, I doubt we could reliably read all the email addresses),
or transcribe audio recordings,
or to translate digital presentations into particular formats.

And in any case, were we to be requested to produce a particular format,
the legal types would want a Microsoft format, not xml or ASCII art.

Y(J)S

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Spencer 
Dawkins
Sent: Thursday, November 17, 2011 16:39
To: ietf@ietf.org
Subject: Re: Plagued by PPTX again

Hi, Yaakov,

I'm not the right guy to answer this, but I believe the right guy would 
say that when we are asked for evidence about prior art, it would be 
more helpful if you could actually read the presentations from the 
working group meeting where somebody's invention was discussed by other 
people three years before the data of the "invention".

I'm not defending that POV, only repeating what I believe the answer to be.

Spencer

On 11/17/2011 8:06 AM, Yaakov Stein wrote:
> Martin
>
> Where does the "note well" say that any contribution needs to be readable 10 
> years hence ?
>
> It says that if you submit/say something that it is under the IPR 
> stipulations,
> and it says that the participant is deemed to have accepted rules of practice
> including that what is said/submitted may be made public.
>
> It does not say that everything that I say in a session must be transcribed 
> and saved in ASCII,
> and what I present in slides is no different from what I say.
>
> Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Plagued by PPTX again

[Yaakov Stein]

Martin

Where does the "note well" say that any contribution needs to be readable 10 
years hence ?

It says that if you submit/say something that it is under the IPR stipulations,
and it says that the participant is deemed to have accepted rules of practice
including that what is said/submitted may be made public.

It does not say that everything that I say in a session must be transcribed and 
saved in ASCII, 
and what I present in slides is no different from what I say.

Y(J)S

-Original Message-
From: Martin Rex [mailto:m...@sap.com] 
Sent: Wednesday, November 16, 2011 18:32
To: Yaakov Stein
Cc: bishop.robin...@gmail.com; ietf@ietf.org
Subject: Re: Plagued by PPTX again

Yaakov Stein wrote:
> 
> > In the interest of
> > 1) Facilitating work
> > 2) Making its work available to as wide an audience as possible, and
> > 3) Lowering barriers to participation...
> 
> Right. We are talking about presentation slides,
> not about something that absolutely has to readable years hence.


You seem to not understand this:
http://www.ietf.org/about/note-well.html

It definitely *IS* highly important that this information
is readable in 10+ years.


I do know that there are folks whose primary purpose is to produce
pretty slides to impress bigwigs during a short span of attention,
and where it a regular custom that the slides become entirely
useless after the meeting.  In the IETF, however, there is an
important difference with information being published, going
on public record, and becoming an IETF contribution.



-Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Plagued by PPTX again

[Yaakov Stein]

> Just saying, but if we want to ensure that presentations are readable 50 
> years from now, 
> and do not embed some kind of malicious code, we might stick to ASCII text, 
> right? 

There are countless attacks on programs and devices that display ASCII code
(I once heard a talk on bricking vintage cellphones by sending specific SMS 
messages).

I think we really should limit ourselves to permanent markers on transparencies
after fingerprinting the presenters.

Y(J)S
 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF 82 Audio Streaming - Updated

[Yaakov Stein]

I want to somewhat retract my earlier statement on how good the audio quality 
has been.

After being very impressed with the quality on many sessions,
this morning I attempted to be (inter)active in a session.

I discovered that the delay was intolerably long,
over 5 seconds one-way delay between seeing a jabber update and hearing the 
associated audio.
And the jabber typing presumably took some time too, so the real delay was even 
higher.
By the time I heard the chair ask for questions, I typed in a question and the 
jabber scribe saw it,
the next speaker was already talking.

It is conventional in speech quality metrics to distinguish between whether the 
application is one-way or interactive. 
When interactive, if the delay is too long for the application to properly 
function, 
the subjective quality is effectively zero.

So, for plenary presentations and sessions where one just wants to listen the 
audio is great.
For sessions where one is used to playing an active role, the quality is 
completely unacceptable.

I captured a few packets and discovered that the audio is MPEG sampled at 22050 
over http over tcp.
Perhaps we could have a parallel RTSP 8K flow for people desiring it.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Plagued by PPTX again

[Yaakov Stein]

> In the interest of
> 1) Facilitating work
> 2) Making its work available to as wide an audience as possible, and
> 3) Lowering barriers to participation...

Right. We are talking about presentation slides,
not about something that absolutely has to readable years hence.

So the slides need to be in a format that
1) the chairs can display on their computers
2) the great majority of people who may be remotely participating can read on 
whatever up-to-date device they have
3) is relatively compact so that remote participants can download on-the-fly

Sounds like pptx to me...

and please do NOT consider another XML markup scheme and special IETF tools to 
create slides !!!

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF 82 Audio Streaming - Updated

[Yaakov Stein]

As someone listening in remotely, and with a background in audio quality 
measurement, 
the audio quality was consistently very good.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Yaakov Stein]

> The IETF has a very long history of pushing back on multiple redundant 
> solutions to the same problem. 
> There are a great many cases of ADs, working group chairs, and others pushing 
> quite hard 
> to prevent multiple solutions when one would work fine. 

I haven't seen this in the OAM work so far.

PWE's VCCV has 3 or 4 different channels (code named CC types)
and 3 or 4 different OAM mechanisms (code named CV types).
And each of these has several variants and most have several possible 
encapsulations.

Similarly in the MPLS-TP work we have a large number of options.
For example, draft-ietf-mpls-tp-on-demand-cv has 3 different encapsulations
(LSP-ping UDP/IP packet in MPLS, LSP-ping packet in UDP/IP in GACh, 
and "raw" LSP-ping packet in GACh with a new channel type).

Why is it that no-one seems to object to a plethora of possible options for 
anything
except the inner-most payload format?

 
Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Yaakov Stein]

> I have very strong doubts about all the issues mentioned in sections 4 and 5

I have comments on 
  4.2 TDM PWs, 
  4.3 Codecs, and 
  4.4 MPLS signaling protocols.

For TDM PWs the IETF followed its tao of requiring one MUST mode (RFC 4553)
and allowing 2 MAY modes (RFCs 5086 and 5087). However, far from being a 
resounding
triumph, this meant that a method considered inadequate by all who really 
understood the issues 
was mandated, while too equally adequate alternatives became optional.
So this example actually shows a negative aspect of the procedure.

Regarding the Code issue, multiple proposals were submitted,
and the resolution was to mold two of them into a new combined codec with 
pieces of each.
So this example is not relevant at all.

Regarding CR-LDP vs. RSVP, once again there were two pre-existing solutions,
and it was decided not to do any new work on one of them.
But this left us with 2 mandatory to implement protocols (LDP and RSVP-TE)
rather than a decision for CR-LDP which would have left a single mandatory 
protocol.
So this actually a counter-example to the tao of having a single mandatory mode.

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Yaakov Stein]

> I think Brian makes an excellent point here. 
> RFC 1958 already contains exactly the same basic message (just with far less 
> (unnecessary) words). 
> I don't think we need this document as it doesn't really add anything to what 
> RFC 1958 says. 

I too object to having too many politically motivated process drafts
(in addition to having questions about the specific examples in the present 
draft).

However, I am not sure that RFC 1958 helps to much here.

The relevant part of 1958 is :
   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

That is fine, but what if there are already two solutions (which is the case 
here) ?

It don't see it in 1958, but the IETF tao has generally been to have one MUST 
mode
and perhaps one or more MAY modes. RFC 4835 is a good example of how this is 
done.

So I believe that this draft is stating something stronger than RFC 1958,
and indeed stronger than the IETF tao usually requires.

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[Yaakov Stein]

>> In transport networks we *never* have peer-2-peer OAM interworking.
>> If it was required it would have explicitly been mentioned in
>> the MPLS-TP requirements RFC.

>Indeed, to have any peer to peer OAM simply removes the ability of the OAM to 
>do its job.

Neither of these statements is completely accurate.

For example, the ITU produced Y.1712 that details the peer-peer interworking 
of ATM OAM per I.610 with the MPLS OAM described in Y.171.

I think that the accurate statement is that OAM interworking is perhaps 
undesirable
but trivial when the OAM semantics matches so that the interworking is 
syntactic translation,
but very challenging (and perhaps sometimes impossible) when the semantics are 
different.
(For "semantics to be different" it is enough for timer values to be different,
 let alone different fault states.)

However, there are many cases where several OAM types co-exist in a single 
deployment.
Perhaps the most relevant case is the widespread use of both EFM OAM (802.3 
Section 57) with Y.1731 OAM.

Y(J)S
 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Hyatt Taipei cancellation policy?

[Yaakov Stein]

In the past the IETF provided a shuttle service from the overflow hotel(s).

It would be nice to know if one is planned for Taiwan.

Y(J)S

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
Christer Holmberg
Sent: Wednesday, August 31, 2011 21:06
To: Ole Jacobsen; Dean Willis
Cc: ietf@ietf.org
Subject: RE: Hyatt Taipei cancellation policy?


Hi,

Also note that, according to Google maps, it is possible to take a bus from the 
overflow hotel to the meeting. It requires a 400 meters walk from the hotel to 
the bus stop, but that should be managble even for an IETF attendee... 

The total travel (walking+bus) is 13 minutes.

Regards,

Christer

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Re: FW: [PWE3] Last Call: (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard

[Yaakov Stein]

Stewart

I will answer your specific questions below.

I have no specific objection to the new text that you proposed on the PWE3 list 
:

   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

   LSPs, Concatenated Segments of LSPs, and with Sections, and

   MAY be used with PWs. The presence of a GAL indicates that

   an ACH immediately follows the MPLS label stack.
as it has become so generic (does not explain where the GAL is placed) as to be 
noncontroversial.
However, please be aware that this simply postpones the true discussion.

I would still like the wording

   According to the MPLS-TP requirement document [RFC5654], it is

   necessary that MPLS-TP mechanisms and capabilities be able to

   interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3

   [RFC3985] architectures appropriate.
to be removed, as I believe that it does not correctly describe the purpose of 
this draft.
It should be replaced with the text that appears further on

   The inconsistency between the usage of the GAL with MPLS PWs and

   MPLS-TP PWs may cause unnecessary implementation differences and is

   in disagreement with the MPLS-TP requirements.

Please see a few more remarks interleaved below.

Y(J)S


 Original Message 
Subject:

Re: FW: [PWE3] Last Call: (Using the Generic Associated Channel Label for 
Pseudowire in MPLS-TP) to Proposed Standard

Date:

Thu, 01 Sep 2011 16:40:16 +0100

From:

Stewart Bryant <mailto:stbry...@cisco.com>

Reply-To:

stbry...@cisco.com<mailto:stbry...@cisco.com>

To:

Yaakov Stein <mailto:yaako...@rad.com>

CC:

ietf@ietf.org<mailto:ietf@ietf.org> <mailto:ietf@ietf.org>

...
However, you did not address my other final comment that a PW that starts in an 
MPLS-TP domain,
can easily leak into a non-TP domain.
What does one do then ?
That is a general issue rather than a TP issue.
When you get to the PW label and you would find that it was not BOS.
If you you are not running FAT that that is a detectable.
If you are running FAT the presence of the GAL (which is not an
allowed FAT label) is also a detectable.

[YJS] I believe the simultaneous use of FAT and GAL is ruled out by the TP 
framework document.
...

You say:

"Bottom of stack has been the label position of the PW label for many years,

and this position is mandated by multiple RFCs, e.g. 3985 and 4447

   Note that the PW label must always

   be at the bottom of the packet's label stack."



That is no longer true with the introduction of FAT.



[YJS]

As you know I proposed an alternative mechanism,

however, in any case the FAT case is different from the GAL.



Each load balanced flow label is actually a "partial-PW' and thus the flow 
label is a type of PW label,

albeit a PW carrying only a subset of the user flows that exist in the original 
PW.



On the other hand the GAL is a modifier, meaning that the rest of the payload 
has a different format.


Then you say:


"Present PW implementations receiving the PW label with stack bit cleared,

and a GAL at the bottom position will choke and, at best, discard the packet.

At worst, the GAL may coincide with a legitimate PW label, and the customer 
will be

flooded with garbage."



Your first case is sort of correct - the packet should be silently

discarded as it was clearly not intended for that PW - but it had

better not choke as this would be an attack vector.



[YJS] By "choke" I meant either discard or flood the impersonated PW with what 
it believes to be VCCV packets.



You second case cannot happen because a GAL is a reserved label and

a reserved label can never be a legitimate PW label.



[YJS]

My second case CAN happen (I expected this question).

Please remember that before MS-PWs were proposed, PW labels were never 
considered "real" MPLS labels,

and many implementations did not religiously apply the MPLS restrictions to 
them.



Stewart



[YJS]



I DO have a proposal that is completely consistent with the goals of this draft 
AND the PWE RFCs.

The GAL can be placed in one of 2 positions

1)  ABOVE the PW label (just as the router alert is placed above the PW 
label in VCCV Type 2)

2)  INSTEAD of the PW label (thus making a single "OAM PW", reducing the 
OAM load)

Note 1 - this is essentially the same as using the GAL for the MPLS tunnel into 
which the PWs are placed.

Note 2 - this is close to my original proposal for PW OAM, that was abandoned 
when VCCV "per-PW OAM" won out.




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: 2119bis

[Yaakov Stein]

I agree with several who have already voiced objections to obsoleting 2119.

On the other hand, a BCP on conformance keyword usage could be useful.

In addition to the clarification of the use of SHOULD 
(that is being discussed at length),
I would like to see a clarification of the difference between MUST and metaMUST
(or supportMUST or interopMUST) and regular/meta similar terms for SHOULD, MAY, 
etc.
and examples of their use.

By that I mean the difference between
 MUST:   When sending a foo message you MUST include the bar TLV
 metaMUST:   All implementations MUST support the bar TLV
the latter meaning that bar is not always sent, 
but if sent it must be properly processed.

There is an (AFAIK unwritten) rule about metaMUST, 
that I believe SHOULD be documented.
If the protocol allows several options for doing something,
precisely one MUST be a metaMUST, and the others metaMAYs.

Note that the MUST in the previous sentence is MUST about
the use of a metaMUST, and is this a metametaMUST.
I am not sure if the previous SHOULD is a meta^2SHOULD or a meta^3SHOULD.

Y(J)S


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Peter 
Saint-Andre
Sent: Tuesday, August 30, 2011 00:37
To: IETF discussion list
Subject: 2119bis

After staring at http://www.rfc-editor.org/errata_search.php?eid=499 for
long enough, I finally decided to submit an I-D that is intended to
obsolete RFC 2119. I hope that I've been able to update and clarify the
text in a way that is respectful of the original. Feedback is welcome.

http://www.ietf.org/id/draft-saintandre-2119bis-01.txt

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw

[Yaakov Stein]

Stewart

Was this email meant to address my email to the IETF discussion list (from Tues 
16 Aug)
or just the discussion on MPLS and PWE lists ?

It does to SOME extent, as it leaves open the possibility of the GAL not being 
at BoS;
but it does not rule out that possibility either.

However, you did not address my other final comment that a PW that starts in an 
MPLS-TP domain,
can easily leak into a non-TP domain.
What does one do then ?

(My email also identified a wording issue and what I consider to be a 
completely inaccurate
explanation of what the draft is trying to accomplish.)

Y(J)S



From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of Stewart 
Bryant
Sent: Tuesday, August 30, 2011 15:05
To: Luca Martini; IETF Discussion
Cc: ietf@ietf.org; Vladimir Kleiner; m...@ietf.org; Idan Kaspit; Mishael 
Wexler; pwe3; i...@ietf.org; Oren Gal; John Shirron; 
pwe3-cha...@tools.ietf.org; Rotem Cohen
Subject: Re: [PWE3] [mpls] IETF Last Call comment on draft-ietf-pwe3-gal-in-pw


Reviewing this discussion there are three components.

1) The update of RFC5586 to allow PW to use the GAL.
2) The PW OAM application that is to use the GAL.
3) The label stack structure when  teh GAL is used with a PW

This draft is only concerned with point 1 above. Points
2 and 3 need to be resolved in any PWE3 draft that describes
the use of the GAL.

To that end the text in draft-ietf-pwe3-mpls-tp-gal-in-pw-01



 -  Section 
4.2.
 (GAL Applicability and Usage) in 
[RFC5586], the

  original text:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MUST NOT be used with PWs. It MUST always be at the bottom of

  the label stack (i.e., S bit set to 1). However, in other MPLS

  environments, this document places no restrictions on where

  the GAL may appear within the label stack or its use with PWs.



  is replaced by:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MAY be used with PWs. It MUST always be at the bottom of the

  label stack (i.e., S bit set to 1). However, in other MPLS

  environments, this document places no restrictions on where

  the GAL may appear within the label stack.
=

should be replaced by

=

 -  Section 
4.2.
 (GAL Applicability and Usage) in 
[RFC5586], the

  original text:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MUST NOT be used with PWs. It MUST always be at the bottom of

  the label stack (i.e., S bit set to 1). However, in other MPLS

  environments, this document places no restrictions on where

  the GAL may appear within the label stack or its use with PWs.



  is replaced by:



  In MPLS-TP, the GAL MUST be used with packets on a G-ACh on

  LSPs, Concatenated Segments of LSPs, and with Sections, and

  MAY be used with PWs. The presence of a GAL indicates that

  an ACH immediately follows the MPLS label stack.
==

- Stewart
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Questionnaire to survey opinion concerning a possible redefinition of UTC

[Yaakov Stein]

On the one hand, abolishing leap seconds would help us with the problem of 
conversion
from the UTC-based NTP timescale and the TAI-based IEEE-1588 and GPS timescales.
On the other hand, it will require updating all software that computes
local sunrise and sunset times (e.g., for radio propagation).

However, the real problem is not related to communications or software.
The real problem is that local time is based on UTC since it needs to be 
astronomically meaningful. 
If leap seconds are abolished and local time starts drifting away from "earth 
time"
then in a few hundred years we will accumulate an hour of error,
and in a few thousand years it will be dark during much of the working day.

This is similar to the draft of the months of the Islamic calendar,
where a particular month may appear in the winter or summer.

I know that most of us don't worry about what is going to happen hundreds of 
years hence,
but think of the Y2K-like fixes that will have to be made for leap-hours !

Y(J)S


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
Stephane Bortzmeyer
Sent: Thursday, August 25, 2011 13:24
To: ietf@ietf.org
Subject: Questionnaire to survey opinion concerning a possible redefinition of 
UTC

Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905, etc), this 
questionnaire may be of interest for some persons [the Web page mentions two 
articles, if you are in a hurry, the first one is the PRO and the second one 
the CON]. One more week to comment.

http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire


QUESTIONNAIRE TO SURVEY OPINION CONCERNING A POSSIBLE REDEFINITION OF UTC

Universal Time, the conventional measure of Earth rotation is the traditional 
basis for civil timekeeping. Clocks worldwide are synchronized via Coordinated 
Universal Time (UTC), an atomic time scale recommended by the 
Radiocommunications Sector of the International Telecommunications Union 
(ITU-R) and calculated by the Bureau International des Poids et Mesures (BIPM) 
on the basis of atomic clock data from around the world.

UTC is computed from TAI by the introduction of leap seconds such that UTC is 
maintained within 1 second of UT1. Since 1972, these leap seconds have been 
added on December 31 or June 30, at the rate of about one every 18 months. 
Since 1 January 2009, 0:00 UTC, UTC-TAI= -34s.

After years of discussions within the scientific community, a proposal to 
fundamentally redefine UTC will come to a conclusive vote in January 2012 at 
the ITU-R in Geneva. If this proposal is approved, it would be effective five 
years later. It would halt the intercalary adjustments known as leap seconds 
that maintain UTC as a form of Universal Time.
Then, UTC would not keep pace with Earth rotation and the value of DUT1 would 
become unconstrained.Therefore UTC would no longer be directly useful for 
various technical applications which rely on it being less than 1 second from 
UT1. Such applications would require a separate access to UT1, such as through 
the publication of DUT1 by other means.

The objective of the survey is to find out the strength of opinion for 
maintaining or changing the present system.

Your response is appreciated before 31 August 2011
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

FW: [PWE3] Last Call: (Using the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed Standard

[Yaakov Stein]

I am not sure how this document moved so quickly from its status as contentious 
WG document 
to being laid before the IESG for consideration,
but I don't believe we ever received answers to serious questions regarding 
backwards compatibility.

The draft claims to solve the following problem :
   According to the MPLS-TP requirement document [RFC5654], it is 
   necessary that MPLS-TP mechanisms and capabilities be able to 
   interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3 
   [RFC3985] architectures appropriate.

Whatever "architectures appropriate" means ...
(another sign of the haste with which this was prepared.)

However, it accomplishes exactly the opposite. 
It breaks interoperability with existing PW implementations.

The true goal of the draft appears a bit later on :
   The inconsistency between the usage of the GAL with MPLS PWs and 
   MPLS-TP PWs may cause unnecessary implementation differences and is 
   in disagreement with the MPLS-TP requirements.

Accordingly, the draft allows PWs to indicate the associated channel by using 
the GAL,
(i.e., making it a generic associated channel, rather than a PW associated 
channel).
This indeed enhances interoperability with all the (presently nonexistent) 
MPLS-TP implementations,
but completely breaks interoperability with the very broad installed base of PW 
implementations.

Why is this the case ?
The draft mandates the GAL appearing at the bottom of stack
   In MPLS-TP, the GAL MUST be used with packets on a G-ACh on 
   LSPs, Concatenated Segments of LSPs, and with Sections, and 
   MAY be used with PWs. It MUST always be at the bottom of the 
   label stack (i.e., S bit set to 1).

Bottom of stack has been the label position of the PW label for many years,
and this position is mandated by multiple RFCs, e.g. 3985 and 4447
   Note that the PW label must always
   be at the bottom of the packet's label stack.

Present PW implementations receiving the PW label with stack bit cleared,
and a GAL at the bottom position will choke and, at best, discard the packet.
At worst, the GAL may coincide with a legitimate PW label, and the customer 
will be
flooded with garbage.

This issue can not be avoided by limiting the use of this technique to "new" 
MPLS-TP
based scenarios, since PWs can be set up to cross from MPLS-TP domains into 
traditional ones.


Y(J)S



-Original Message-
From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of The IESG
Sent: Friday, August 12, 2011 22:24
To: IETF-Announce
Cc: p...@ietf.org
Subject: [PWE3] Last Call:  (Using 
the Generic Associated Channel Label for Pseudowire in MPLS-TP) to Proposed 
Standard


The IESG has received a request from the Pseudowire Emulation Edge to
Edge WG (pwe3) to consider the following document:
- 'Using the Generic Associated Channel Label for Pseudowire in MPLS-TP'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-08-26. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document describes the requirements for using the Generic
   Associated Channel Label (GAL) in Pseudowires (PWs) in MPLS-TP
   networks, and provides an update to the description of GAL usage in
   [RFC5586] by removing the restriction that is imposed on using GAL
   for PWs especially in MPLS-TP environments.

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: How to pay $47 for a copy of RFC 793

[Yaakov Stein]

> This reminds me of what a colleague once said about government-run lotteries: 
> "A tax on people who are bad at math". 
> In this case the fools don't seem to be throwing all that many dollars away 
> (at least not per document). 

What worries me is what they intend doing with the copy of RFC 793.

If some rule requires taking all references and placing them in a booklet that 
no-one looks at,
then it is OK for them to pay reasonable copying and distribution costs to 
someone willing to print the RFC for them.

However, what if they send the RFC to some programmer who has never heard of 
TCP/IP
and ask him to implement solely based on this referenced document ?

In that case the costs may be somewhat larger ...

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: How to pay $47 for a copy of RFC 793

[Yaakov Stein]

> In IEEE Xplore, I can't find any RFCs at all, no matter how I search
> for them.  Search for "Transmission Control Protocol" and you'll find
> lots of articles but no RFCs.

Not surprising.

To quote from the site :
   The IEEE Xplore digital library is a powerful resource for discovery and 
access to scientific and technical content published by IEEE 
   (Institute of Electrical and Electronics Engineers) and its publishing 
partners.

Unless I am mistaken, RFCs aren't IEEE publications.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Gen-ART LC review of draft-ietf-pwe3-oam-msg-map-14

[Yaakov Stein]

Roni

Thanks for the nit-catching.

I assume  you RFC5087 not as a reference means you quote RFC5087 not as a 
reference.

Due to Adrian's DISCUSS we are going to have to respin after the LC;
I will fix all the nits you mention (and Russ' nit as well) at that time.

Y(J)S

From: Roni Even [mailto:even.r...@huawei.com]
Sent: Sunday, January 23, 2011 09:17
To: draft-ietf-pwe3-oam-msg-map@tools.ietf.org; gen-...@ietf.org
Cc: 'IETF-Discussion list'
Subject: Gen-ART LC review of draft-ietf-pwe3-oam-msg-map-14

Hi,
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at .
Please resolve these comments along with any other Last Call comments you may 
receive.



Document: draft-ietf-pwe3-oam-msg-map-14

Reviewer: Roni Even

Review Date:2011-1-23

IETF LC End Date: 2011-1-24

IESG Telechat date:



Summary: This draft is ready for publication as a Standard track RFC.



Major issues:





Minor issues:





Nits/editorial comments:



1.  The document starts with Contributors and acknowledgments section. I think 
that this is not the major reason for the document and suggest moving these two 
sections to the end of the document.

2.  In the Abbreviations and Conventions section which includes the terminology 
it may be good to reference the terminology from RFC3985.

3.  Towards the end of section 7 and in the beginning of section 11 you RFC5087 
not as a reference while in other places you have it as a reference. I think it 
should be written as a reference.





___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: text versions of ID and RFCs

[Yaakov Stein]

Sure I can ftp. But usually I search for the draft I want using my browser,
and it would be clumsier to have to shift to ftp instead of clicking.

It is easier to retrieve them from any of the mirror sites
that download them via my browser in CR-LF format.
Only the official site gives me in "Unix" format.

It would be great to enable choosing the format desired by right-clicking.

Y(J)S

From: Tony Hansen [mailto:t...@att.com]
Sent: Thursday, November 11, 2010 07:05
To: Yaakov Stein
Cc: ietf@ietf.org
Subject: Re: text versions of ID and RFCs

Use ftp to retrieve them. Set ASCII mode. Your line ending problems will be 
solved.

Tony

On 11/10/2010 10:26 PM, Yaakov Stein wrote:
When retrieving IDs or RFC from the tools.ietf.org or datatracker.ietf.org the 
file has only LFs
rather than CR+LF.

Yes, it is easy enough to convert this for simple reading on Windows machines,
but it is inconvenient to have to do this every time.

Could it be possible to change the default here ?
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

text versions of ID and RFCs

[Yaakov Stein]

When retrieving IDs or RFC from the tools.ietf.org or datatracker.ietf.org the 
file has only LFs
rather than CR+LF.

Yes, it is easy enough to convert this for simple reading on Windows machines,
but it is inconvenient to have to do this every time.

Could it be possible to change the default here ?

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

BOF scheduling

[Yaakov Stein]

We heard at the mike and at the IESG table this evening that BOFs shouldn't be 
scheduled
simultaneously with area open meetings.

So why don't we reserve one room for all of the afternoon sessions for either a 
BOF or an area meeting ?

This should leave enough spiel to play with at the last moment.

And that way anyone who wants to see what is presently going on and what is 
going to start happening
can stay in the same room all afternoon.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12

[Yaakov Stein]

In the IETF meta-discussions on the idea of discussing IPR are more liable to 
become ratholes than the IPR discussion itself.
Even worse is the meta-meta discussion on whether to restrict ourselves to 
using ASCII in the meta-discussion :)

IPR SHOULD be discussed by the WG, and this discussion is especially 
appropriate during the LC period of a standards track draft 
( we asked for a 2nd LC on this draft ) in order to understand any possible 
issues before passing on to the IESG.

In some WGs (e.g. codec) IPR issues are more important than others as their 
mission is to create technology
which is as IPR-free as possible. In codec's case they have even appointed 
someone specifically to check into IPR
(from a technical point of view - to make sure that disclosures have been made 
- not to "rule" on IPR). 

In PWE there have been a plethora of patents from the start, but everything has 
always been disclosed and discussed.
It would be unfortunate for things to become confused due to technical errors 
of disclosing with respect to the wrong drafts.

Y(J)S

-Original Message-
From: Donald Eastlake [mailto:d3e...@gmail.com] 
Sent: Thursday, April 15, 2010 21:57
To: Trowbridge, Stephen J (Steve)
Cc: Yaakov Stein; mmor...@cisco.com; lmart...@cisco.com; tom.nad...@bt.com; 
Aissaoui, Mustapha (Mustapha); david.i.al...@ericsson.com; Busschbach, Peter B 
(Peter); Secretariat; p...@ietf.org; adrian.far...@huawei.com; 
i...@core3.amsl.com; andrew.g.ma...@verizon.com; stbry...@cisco.com
Subject: Re: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of 
IPR relating to draft-ietf-pwe3-oam-msg-map-12

There is no such rule in the IETF, although perhaps patent discussions
need some moderation to avoid becoming ratholes. To quote some pieces
of text from RFC 3669 (which I recommend you read in full):

"It's all right, and sometimes beneficial, to discuss IPR claims
  and gather information about possible prior art on the [working]
group list.
  The results of such discussion can be considered when deciding
  whether to develop a technology (but remember that neither the
  IETF nor any working group takes a stand on such claims as a body,
  and the group is not the best place to get legal advice)."

and

"Working group participants can evaluate IPR claims not only for
  their possible validity, but also for the risk of misjudging that
  validity."

Donald
=
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA

On Wed, Apr 14, 2010 at 8:47 AM, Trowbridge, Stephen J (Steve)
 wrote:
> Hi all,
> In IEEE we are admonished to never discuss the essentiality or validity of 
> patent claims. I cannot believe this is considered an appropriate discussion 
> in IETF.
> Regards,
> Steve
>
> -Original Message-
> From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf Of 
> Yaakov Stein
> Sent: Wednesday, April 14, 2010 1:44 AM
> To: mmor...@cisco.com; lmart...@cisco.com; tom.nad...@bt.com; Aissaoui, 
> Mustapha (Mustapha); david.i.al...@ericsson.com; Busschbach, Peter B (Peter)
> Cc: i...@core3.amsl.com; Secretariat; p...@ietf.org; 
> adrian.far...@huawei.com; andrew.g.ma...@verizon.com; stbry...@cisco.com
> Subject: Re: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of 
> IPR relating to draft-ietf-pwe3-oam-msg-map-12
>
>
> This disclosure (1311) quotes application US20080089227A1: Protecting 
> multi-segment pseudowires which may impact draft-ietf-pwe3-redundancy, and 
> perhaps ICCP, MS-PW architecture, and MS-PW setup.
> There is no apparent connection with oam-msg-map - in fact the claims stress 
> that the triggers are failures of PSN elements (e.g. S-PEs) and are NOT from 
> the ACs, making any connection untenable.
>
> A previous disclosure by the same company (863) refers to
>    20080285466 : Interworking between MPLS/IP and Ethernet OAM mechanisms 
> which may impact mpls-eth-oam-iwk, but not oam-msg-map, unless one interprets 
> the first claim and its dependents much more broadly than supported by the 
> background and description.
>
> Can someone from the company claiming this IPR fix the information in these 
> disclosures ?
> At very least that company is required to disclose IPR is holds with respect 
> to the appropriate drafts (unless it is willing to risk forfeiting its rights 
> with respect to these ...).
>
> However, with respect to oam-msg-map I would like to request that it consider 
> removing inappropriate disclosures.
> Of course, if after consideration it believes that these disclosures ARE 
> appropriate, I would love to hear the reasoning.
>
> Y(J)S
>
>
> -Original Message-
> From: IETF Secretariat [mailto:ietf-...@ietf.org]
> Sent: Tuesday, April 13, 2010 18:46
> To

RE: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12

[Yaakov Stein]

Todd, 

My email to the PWE list and to my co-authors was neither about scope nor 
validity.

The trigger was an email from the IETF Secretariat informing the co-authors of 
draft-ietf-pwe3-oam-msg-map 
of a new IPR disclosure.
I had recently finished extensive editorial work in this draft, and in Anaheim 
I requested a second WG LC;
so the timing for a discussion of IPR issues related to this draft could not 
have been better. 

I certainly did not study the application sufficiently to be able to express an 
opinion as to patentability. 
I merely noted that as an co-author of the draft,
and as someone with experience in patent prosecution, 
that the disclosure was prima facie directed towards the wrong draft.

I sent the email purely as draft co-author and long-time PWE3 participant.
My employer has no direct interest in the issue.

Y(J)S 


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of todd 
glassey
Sent: Thursday, April 15, 2010 22:00
To: ietf@ietf.org
Subject: Re: [PWE3] Posting of IPR Disclosure related to Cisco's Statement of 
IPR relating to draft-ietf-pwe3-oam-msg-map-12

On 4/14/2010 9:20 PM, Dean Willis wrote:
> This was more a discussion of scope than validity.
> 
> Of course, having public discourse in a community of experts that 
> disparrages the validity of a claim could bolster invalidation 
> arguments.

Or create a liability for the IETF and the parties involved.

> So I can see how this might be a disfavored act in the IEEE community, 
> which seems to be slanted towards rights holders (I speak as a 
> long-term member of IEEE and as a consultant on IPR). Perhaps we'd all 
> be better off if the IEEE were a little more critical of misguided 
> claims? Regular raising of a hue and cry of "Bullshit!" would go a 
> long way towards reducing the damage caused by unmerited patents.

Dean - I think the problem is that the individuals in the IETF who represent 
their sponsors are generally not licensed patent agents or attorneys (although 
there are a couple of exceptions to this last one) and so its really hard for 
someone who has no experience in the patent process to make any reliable 
commentary.

The unfortunate occurance in the IETF is that people make specific claims about 
what they professionally believe is and is not patentable but the reality is 
that no matter what they say they are not the patent agency or its examiners so 
the act of making these declarations as fact is literally practicing law 
without a license IMHO. Especially when these individuals make flat claims 
about the validity of a patent's status or filing.

Individuals may have a personal opinion but I am betting that the legal opinion 
of the Sponsor as to some other party's patent filing is not something that the 
Sponsor's are willing to grant to their un-skilled and non-legally trained 
technology players here in the IETF.

Todd Glassey

> 
> --
> Dean Willis
> 
> --- Original message ---
>> From: Trowbridge, Stephen J (Steve) 
>> 
>> Cc: ietf-...@ietf.org, p...@ietf.org, adrian.far...@huawei.com, 
>> i...@core3.amsl.com, andrew.g.ma...@verizon.com, stbry...@cisco.com
>> Sent: 14.4.'10,  8:47
>>
>> Hi all,
>> In IEEE we are admonished to never discuss the essentiality or 
>> validity of patent claims. I cannot believe this is considered an 
>> appropriate discussion in IETF.
>> Regards,
>> Steve
>>
>> -Original Message-
>> From: pwe3-boun...@ietf.org [mailto:pwe3-boun...@ietf.org] On Behalf 
>> Of Yaakov Stein
>> Sent: Wednesday, April 14, 2010 1:44 AM
>> To: mmor...@cisco.com; lmart...@cisco.com; tom.nad...@bt.com; 
>> Aissaoui, Mustapha (Mustapha); david.i.al...@ericsson.com; 
>> Busschbach, Peter B (Peter)
>> Cc: i...@core3.amsl.com; Secretariat; p...@ietf.org; 
>> adrian.far...@huawei.com; andrew.g.ma...@verizon.com; 
>> stbry...@cisco.com
>> Subject: Re: [PWE3] Posting of IPR Disclosure related to Cisco's 
>> Statement of IPR relating to draft-ietf-pwe3-oam-msg-map-12
>>
>>
>> This disclosure (1311) quotes application US20080089227A1: Protecting 
>> multi-segment pseudowires which may impact 
>> draft-ietf-pwe3-redundancy, and perhaps ICCP, MS-PW architecture, and MS-PW 
>> setup.
>> There is no apparent connection with oam-msg-map - in fact the claims 
>> stress that the triggers are failures of PSN elements (e.g. S-PEs) 
>> and are NOT from the ACs, making any connection untenable.
>>
>> A previous disclosure by the same company (863) refers to
>> 20080285466 : Interworking between MPLS/IP and Ethernet OAM 
>> mechanisms which may impact mpls-eth-oam-iwk, but not oam-msg-map, 
>> unless one interprets the

RE: Motivation to submit an idea in IETF?

[Yaakov Stein]

Abhishek, 

I see that you have already received multiple answers, 
but as someone who deals with IPR and standardization,
I would like to make a few points.

First, since you ask about motivation, I would ask you what is your motivation
for filing a patent? In software and communications patent applications are 
almost never
filed for the reasons that they are filed in the classical practical arts,
namely to acquire exclusivity for a certain time.
The fact that they take so long to be granted (often 4-5 years),
and that it is so difficult to predict whether they will be granted,
effectively rules out acquiring a reasonable window of exclusivity.

Instead, there are two main reasons to file -
big companies file in order to have sufficient defenses against other big 
companies
who may attack them, and small companies file in order to be attractive to
big companies who may acquire them. 

Note that large companies almost never sue smaller ones for infringement
(as the small companies don't have the resources to pay anyway);
if threatened, it is much easier to lock them out of sales channels
or to acquire them.
Large companies sue other large companies for many reasons,
but only infrequently to acquire exclusivity.
Trolls go after large companies (who can afford to pay), 
since the large company's patent portfolio doesn't threaten them.
Small companies almost never sue other small companies
(neither have the resources).
Small companies who sue larger ones are probably doing so more
for the PR than for the IPR aspects.

Second, what is the motivation for submitting ideas to SDOs such as the IETF?
One reason is to push an approach for which you have an advantage, 
under the assumption that if standardized you have get an effective exclusivity 
window.
Another is to impede progress when your approach is not accepted
until you have the time to implement the accepted approach.
Finally, the very fact that you contribute to a document gives you 
(and in some SDOs, your company) the visibility to potential customers.

So if you are looking for a window of exclusivity,
it is probably safer to invest time in standardization.
The window may be shorter, but 17 years is probably meaningless
for most inventions in software and communications anyway.

If you are looking for your invention to be actually implemented,
it is certainly better to place it in the public domain
(or at least patent it and offer to RAND license it)
and propose its standardization.

If you really want to make money using patents, 
then filing is too risky and too expensive.
Buy up already granted ones that are being sold by companies 
going out of business - they may not be good enough to keep a company solvent,
but you may be able to get substantial nuisance payments
from large companies.

Y(J)S

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of 
Abhishek Verma
Sent: Friday, January 22, 2010 02:58
To: ietf@ietf.org
Subject: Motivation to submit an idea in IETF?

Hi,

I have a basic question relating to patents and IETF.

Assume that i have a nifty idea on how i can speed up, lets say, a
database exchange in OSPF. My doubt is that why should i submit an
IETF draft describing this, which can later become an RFC, when i can
very well patent this idea? I understand that if i submit this to
IETF, then there will be an RFC and all vendors will come out with
inter-operable implementations. However, if i dont give it to IETF and
rather submit a patent, i can do very well for the vendor that i work
for. All customers using this vendor's boxes will now have access to
patented database exchange in OSPF, which will effectively mean more
business for this vendor.

So, the question is, what is the motivation for somebody to write an
internet-draft when the person can file a patent?

I spoke to several people offline and i couldnt get any good answers.
The typical response was that most ISPs prefer multiple vendors, and a
patented solution will cause issues as the other vendor will not have
that support. Is this the only  reason?

Thanks,
Abhishek
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,> (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

[Yaakov Stein]

Huub

I strongly disagree with some of your statements,
although some of the difference may be semantic.

CCM indeed supports CC and CV, but the only real PM function it support is live 
PLR,
by virtue of the counters. 
One and two way delay and variation are not supported 
(because there is no option to put timestamps in the CCM PDU),
nor does it support the data TLV to check loss of connectivity of large frames.
And in many deployments "synthetic frame" packet loss is desired.

In practice (and I am talking about many dozens of deployments in which we have 
been involved),
I have encountered CCs between each pair of MEPs, 
and separate CCs (running at 300 per second) in a separate VLAN for ring 
protection when applicable.

In addition, LBMs or TSTs have to be run occasionally to check that there are 
not problems with large packets.

Then for PM there is a whole array of other messages.
The MEF has been trying for over a year to reduce the number of different 
messages needed.
 
Of course, this is all for one level of OAM. There are additionally Y.1731 
frames running
and higher and lower levels. And in many cases there are also EFM OAM frames at 
the edges.

That's what I meant by a nightmare. 

Had the CCMs had (as I originally suggested in Q5/13) optional timestamps
(at the front with the TLV offset indicating their presence)
and data TLVs to control the length, we would have reduced all 1-way 
functionality to a single
message.

Y(J)S



-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub 
van Helvoort
Sent: Saturday, October 10, 2009 23:15
To: ietf@ietf.org
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements,> 
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

Hello Yaacov,

You wrote:

> I rescind my first comment,
> but stand by my second one.

This was your second, with my comments [hvh] in-line:

 > Second, "that the mechanisms in Y.1731 are sufficiently
 > simple to allow some "hardwarization".

[hvh] this HW already exists, as was mentioned at the IETF75
   when draft-bhh-mpls-tp-oam-y1731 was discussed.

 > The other main fault with Y.1731 is its fracturing of
 > the capabilities among so many different OAM message types,
 > rather than realizing that there are really only two OAM types
 > (one way and reflecting), with options for various monitoring
 > or  measurement functions.

[hvh] a better way to divide the messages is by "pro-active"
   and "on-demand". The set of pro-active should be as small
   as possible and combine different capabilities as much
   as possible.

 > If you only need CCMs, yes Y.1731 is easy (but so is any other
 > heartbeat format).

[hvh] note that CCM supports CC + CV (for signal fail detection)
   + PM (for signal degrade detection) + fault reporting (RDI)
   in a single message.
   There are only two more pro-active messages: AIS and LCK
   and only one of CCM, AIS and LCK will be active at the same
   time.

 > Once you want to do CCs, CCs for protection (G.8031/G.8032
 > require their own),

[hvh] NO. CCM is used to trigger protection, 1+1 linear
   protection does not need additional messages, 1:1 and
   ring protection require a message to synchronise the
   status of the nodes involved in the protection.
   This would be the only message that can be active at
   the same time as CCM, however only on the protection
   channel.

 > packet loss measurement, and delay measurement, it becomes
 > a nightmare.

[hvh] I disagree, these are message used only on-demand and
   they will not be active at the same time. Only five are
   currently defined: LB. LT, LM, DM, 1DM.

Regards, Huub.

-- 

Always remember that you are unique...just like everyone else...
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

[Yaakov Stein]

Francesco, 

Thanks for pointing out to me how poor my memory has become.

For some reason I remembered 3, 30, and 300 per second,
instead of 10, 100, and 300 per second.

I rescind my first comment,
but stand by my second one.

Y(J)S


-Original Message-
From: Francesco Fondelli [mailto:francesco.fonde...@gmail.com] 
Sent: Thursday, October 08, 2009 09:33
To: Yaakov Stein
Cc: Rui Costa; ietf@ietf.org; Adrian Farrel
Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements 
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

On Thu, Oct 8, 2009 at 8:43 AM, Yaakov Stein  wrote:
> Rui,

Hi all,

> While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP,
> and quite understanding the reasoning behind reusing existing formats,
> I am puzzled by two of your statements.
>
> First, that Y.1731 CCMs "would ease more vendor's implementations to
> converge to the 50ms protection timescale".
> One of the major problems with Y.1731 is the lack of a 100 packet per second
> rate, forcing the use of 300 packets per second at high resource cost.

hemm

--- T-REC-Y.1731-200802 ---
7.1.1 CCM (with ETH-CC information) Transmission
When ETH-CC is enabled, a MEP periodically transmits CCM frames as
often as the configured transmission period. Transmission period
can be one of the following seven values:
- 3.33ms: default transmission period for protection switching
  application (transmission rate of 300 frames/second)
- 10ms: (transmission rate is 100 frames/second)
  ^^
---

Even if I'm not a big fan of it I have to say that
100 pps is foressen by Y.1731 (and even by your ID,
http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-03, Section 4.1.1)

[cut]

> Y(J)S

Ciao
FF
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

[Yaakov Stein]

Rui, 

While a co-author of the draft proposing re-use of Y.1731 OAM for MPLS-TP,
and quite understanding the reasoning behind reusing existing formats,
I am puzzled by two of your statements.

First, that Y.1731 CCMs "would ease more vendor's implementations to
converge to the 50ms protection timescale".
One of the major problems with Y.1731 is the lack of a 100 packet per second
rate, forcing the use of 300 packets per second at high resource cost.
I feel that 50 ms protection requirements are the best reason NOT to use Y.1731.

Second, "that the mechanisms in Y.1731 are sufficiently simple  
to allow some "hardwarization".
The other main fault with Y.1731 is its fracturing of the capabilities
among so many different OAM message types,
rather than realizing that there are really only two OAM types
(one way and reflecting), with options for various monitoring or measurement 
functions.
If you only need CCMs, yes Y.1731 is easy (but so is any other heartbeat 
format).
Once you want to do CCs, CCs for protection (G.8031/G.8032 require their own),
packet loss measurement, and delay measurement, it becomes a nightmare.


Y(J)S



-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rui 
Costa
Sent: Monday, October 05, 2009 11:27
To: ietf@ietf.org
Cc: Adrian Farrel
Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements 
(Requirementsfor OAM in MPLS Transport Networks) to Proposed Standard

SDH and EoSDH networks are widely used by Portugal Telecom Comunicacoes 
(PTC) and TMN (respectively the incumbent operator in Portugal and PT   
group's mobile operator), as well as foreign PT's clients (Brazilian "Vivo",
for instance). These operators are used to both SDH and Ethernet's OAM  
paradigm. We ask you therefore to consider that MPLS-TP OAM protocols MUST  
allow equivalent OAM mechanisms.

Being more precise, we would like to use the same protocol messages, to 
give/have   
the same "touch&feel" we had in SDH and for less time in ETH.   

In SDH...   
-it allows you at each end to check you have signal reception and notify the 
other end when you don't (RDI)  
-it does so at different levels (in SDH you can have it both for each VC and 
for the STM)
-it has a means by which to exchange an APS protocol

In ETH...   
-we've been using Y.1731 in EoSDH systems; it was the ITU standard developed 
for this purpose and was thought in the same principles stated for SDH; the 
most logical evolution would hence be to use the same PDUs and mechanisms as 
faithfully as possible with an adequate MPLS-TP encapsulation   
-MEF defined performance monitoring functions for frame loss measurement 
[FL], delay measurement, delay variation measurement, which are also addressed  
in Y.1731   

The main reason to use the same PDUs as in Y.1731 is probably the same i guess  
and respect in RFC5654 2nd general requirements: economy. We can't though 
forget this   
requirement list will have impact on ITU standards and that, although much of   
the work in MPLS-TP is IETF's merit and sweat, probably no one would need it if 
ITU 
didn't start T-MPLS (whose interoperability problems with MPLS/IP were 
afterwards   
pointed out by IETF and originated all the work we can see now).

I would also like to point out that the mechanisms in Y.1731 are sufficiently 
simple
to allow some "hardwarization", which would ease more vendor's implementations 
to   
converge to the 50ms protection timescale, allowing a way to do this in a 
cheaper,  
more scalable and miniaturized way. 

Thank You for your time. Best Regards,  
Rui Costa   

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Yaakov Stein]

Patrik,

> Problem with LaTeX and TeX is the need for class libraries, 

How is that different from needing the latest tcl code for xml2rfc ?

> and the lack of agreed upon way of distributing a 
> LaTeX/TeX file with the class files needed (part from what is "standard"), 
> or lack of automatic tools that include needed things from the class files to 
> the source file.

Still nowhere near the combination of opaque processing instructions needed for 
xml2rfc.

Something like \documentclass[std,trust200902]{RFC} at the top of the file
is all that would be needed.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF

[Yaakov Stein]

> I bought the TeXbook in 1989 and liked it, despite the learning curve.

Did you read the entire TeXbook and only then start TeXing ?
Although I have read every page several times,
I never set out to do so. For me it was a quick scan,
modification of existing files, and then reading as needed.

> I tried LaTeX in 1992 and junked it.  The header&footers used
> in the LaTeX book where impossible to create with LaTeX (which I think
> amounts to cheating), so I dropped back to plain TeX. 

Nothing is impossible. You just have to write your own style files (in TeX).
I have written several completely new LaTeX styles, you can do
anything that TeX allows (that is, anything at all).
In fact, I wrote a style for Hebrew Language PhD theses - 
that required reversing the line direction, different line splitting, etc.

> The problem with most LaTeX documents I came across in 1991-1995
> was that they used style files that were extremely hard to find
> (for someone not using a particular universities infrastructure).

Most journals or textbook publishers that accept TeX in any form
will supply you with their style file. The beauty is that you can
prepare your text and then slap on the style at the last moment
(or if one journal rejects your paper, you can easily prepare it for submission
to another journal). 

I considered writing a style for IDs and RFCs.
But although the initial effort would not be major,
I don't want to be stuck for life with maintenance.
Kudos to those who maintain the xml2rfc tools.

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: XML2RFC must die, was: Re: Two different threads - IETF Document Format

[Yaakov Stein]

> ... and don't get me started on LaTeX.

I am not sure what problems you had with LaTeX, but as someone who has
written thousands of pages using TeX,
I can't imagine anything better for professional document preparation.

On the other hand, the learning curve is relatively steep,
and its full power is not needed for the plain text documents that
most people participating in this thread seem to be writing.

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: RFC archival format, was: Re: More liberal draft formatting standards required

[Yaakov Stein]

OK, here is what happens on my netbook using your method.

Original

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type  |Length |R|T|  Transport flags  |  Res  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  MTU  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


What I see :


0 1 2 3 4 5 6 7 8 9 0
 1 2 3 4 5 6 7 8 9 0 1 2 
3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+
   | Type  |L
ength |R|T|  Transpor
t flags  |  Res  |
   +-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+
   | 
 MTU 
 |
   +-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+
-+-+-+-+-+-+-+-+-+


Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: More liberal draft formatting standards required

[Yaakov Stein]

> To save time, I would suggest adopting the Patent Office rules on  
> Perpetual Motion. People advocating for a change to facilitate figures  
> (or to allow complicated math, such as tensor analysis) should have an  
> existence proof, i.e., a document that requires the change to be  
> published. (A document that left the IETF to be published elsewhere  
> for this reason would also do.)

Marshall

If I remember correctly, draft-ash-alt-formats gave such examples.

G.805 diagrams were needed for some of the PWE and MPLS work,
but could not be put in the desired format. 

I personally started writing up a description of a packet loss concealment 
technique, 
but had to give up due to the formulas not being transcribable 
(I had no problem submitting a patent application instead).

In TICTOC we are not even considering attempting any work that needs math,
but rather leave it to other SDOs.
It is considered a limitation of the system.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: RFC archival format, was: Re: More liberal draft formatting standards required

[Yaakov Stein]

> Last but not least, just filter out anything between < and > and  
> replace a few &xxx; sequences and you're back to plain text. We could  
> probably even format RFCs such that if you remove the HTML, you're  
> left with the current ASCII format.

You seemed to have missed the point.

Almost all RFCs have ASCII art in them,
and although perhaps not absolutely needed for correct implementation 
they are necessary to comprehend the document.

When you improperly break lines these figures are irreversibly corrupted,
and in essence you lose a large part of the document.

In fact, you lose exactly the same information that you would lose 
were we to standardize some other format that embeds characters without 
compression
and merely pull the ASCII characters out.

So if you object to using a non-ASCII format because it will not be 100% 
readable
30 years from now, you should object to using the present format today.

Y(J)S
 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: More liberal draft formatting standards required

[Yaakov Stein]

The limitations of ASCII format have been discussed here numerous times.
For example, see the lengthy thread last year on draft-ash-alt-formats (now 
expired).

Many people have proposed modern approaches that comply with the constraints.
Going back a generation or two to nroff seems to me to be a step in the wrong 
direction.

Y(J)S

-Original Message-
From: Douglas Otis [mailto:do...@mail-abuse.org] 
Sent: Thursday, July 02, 2009 08:19
To: alh-i...@tndh.net
Cc: 'Theodore Tso'; Yaakov Stein; 'IETF Discussion Mailing List'
Subject: Re: More liberal draft formatting standards required


On Jul 1, 2009, at 10:58 AM, Tony Hain wrote:

> An alternative would be for some xml expert to fix xml2rfc to parse  
> through the xml output of Word. If that happened, then the  
> configuration options described in RFC 3285 would allow for wysiwyg  
> editing, and I would update 3285 to reflect the xml output process.  
> I realize that is a vendor specific option, but it happens to be a  
> widely available one.


Reasons for wanting more than just plain text documents is to permit  
inclusion of charts, graphs, and tables, for a visual society.  A safe  
way to provide this type of output using stable open-source code would  
be with roff preprocessors, like eqn, pic, tbl.

Word's closed code is continuously changing.   Availability of this  
closed application depends upon OS compatibility and version  
regressions.   Both are moving targets.  In addition, Word formats  
permit inclusion of potentially destructive scripts within highly  
flexible and obfuscating structures.   troff normally outputs .ps and  
is supported by various utilities like X viewers in open source.  Unix  
based OSs like OSX and Linux still support this document format, where  
grohtml can generate HTML output. The disadvantage of using the roff  
approach has been a lack of IETF boilerplate pre-processors.  Merging  
XML structures could be combined with powerful roff presentation  
utilities to generate IETF documents.

In many respects, roff offers simpler and proven stable formats.  The  
present xml2rfc utilities do not offer wysiwyg.   Combining custom pre- 
processors and visualization utilities, the roff suite offers greater  
security, stability and versatility for all OSes and media  
presentations types, along with iterative wysiwyg modes of operation.   
There would be little difference using roff tools from using xml2rfc,  
however the results could show a marked visual improvement.  A desire  
for security might even foster a resurgence in roff tools to leverage  
proven and stable document generation.

Everything old is new again.

-Doug




___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: More liberal draft formatting standards required

[Yaakov Stein]

Have a look at Dave Mills recent remarks on the NTP list :
https://lists.ntp.org/pipermail/ntpwg/2009-June/001519.html

Due to his diminished eyesight he can't handle the text
of the document he is co-authoring without significant preprocessing.

Y(J)S


-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Melinda 
Shore
Sent: Thursday, July 02, 2009 02:23
To: Randy Presuhn
Cc: IETF Discussion Mailing List
Subject: Re: More liberal draft formatting standards required

Randy Presuhn wrote:
> I don't know.  I prefer vi.

You can run nroff on a buffer inside of both vi and emacs
and get the output in another buffer.

I've read internet drafts on a variety of handheld devices,
from the old Sharp Wizards to Palm Pilots to a Blackberry,
and I very much appreciate having a lowest-common-denominator
document format.  The only drawback has been the fixed line
length - it can be slightly annoying for text but it renders
ascii graphics completely useless on a narrower screen.  On
balance I think it's a reasonable tradeoff, though.  And
personally, I'm grateful that such a wide variety of tools
can be used to generate conforming drafts - I think that it
helps keep the process just a little more open.

Melinda
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: More liberal draft formatting standards required

[Yaakov Stein]

>Oh and please no more of the thousand years nonsense. If mankind can
>decipher Linear-B after three millenia on the basis of two shopping
>lists and an op-ed piece then there is never going to be any problem
>with PDF or HTML. The idea that we would lose the ability to process
>those formats is simply too ridiculous for words.

Of course we can still decipher Linear-B - it's in Unicode 
http://unicode.org/charts/PDF/U1.pdf .

If it were in ASCII art I am sure that no-one would have been able to figure it 
out.

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: More liberal draft formatting standards required

[Yaakov Stein]

>> The TXT versions do not print on my printer and have not printed
>> reliably on any printer I have ever owned.

>I discovered by accident that, on my machine, simply opening a
>text version in Microsoft Word gives a document which prints
>properly, page breaks and all. (10 point Courier I think.)
>Maybe not a purists' solution, but good enough to allow me to
>move on.

Until about 5 years ago I could open an RFC or ID in a simple text editor
and press print. But I no longer have a "simple" editor on my machine.
The closest I have is Microsoft's "Notepad" which defaults to larger fonts and 
margins.
It breaks every line into 1 1/2 lines, making the text close to unreadable,
and the printout about 3 times the number of pages.

I use Word sometimes, but I need to do more work.

After forcing the file to be opened in Word,
I have to perform a "select all" and change the font to Courier
and the size to 10. (If I don't change the font to a monospace one
all the artwork is undecipherable.)

Then I have to make the top margin smaller - the default top margin
makes a break just before the footer, so that a print out has every other page
containing only a footer at the top and otherwise blank
(the page break IS understood).

I used to be able to go into page preview mode and fix things up for printing
in a WYSIWYG fashion, but that no longer works in the newer version of Word.

So, the argument that the format we use is future proof is still holding up.
I indeed CAN still print an RFC on my machine, 
but it does take a lot of work.

I would not be surprised if with my next machine I would find it impossible
to print correctly using any of the standard utilities provided,
and that I would be forced to write a program to do so.

The machine after that will probably not have any languages I know,
and I hope that the IETF will be able to provide (free of charge)
a viewer with printing option.

Y(J)S



___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Yaakov Stein]

Joel

Yes, I referred to that list when I quoted "classical programming code".

However, as the list does not include a set of recognized programming languages,
I thought that the issue was left open.

By code marker I assume you mean  ... ,
which is itself a kind of pseudocode.

Y(J)S

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com] 
Sent: Tuesday, June 23, 2009 19:13
To: Yaakov Stein
Cc: Marshall Eubanks; ietf list; IAB IAB; IESG; Trustees
Subject: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

There is an explicit list of what is automatically covered as code.
After discussion, that list does not (did not, the last time I checked) 
include pseudo-code.
Document authors are free to mark their pseudo-code using the code 
marker if they want it treated as code.

The problem, as far as I am concerned, is that pseudo-code is not 
well-defined, and therefore including it in the general list, we would 
have ambiguity as to what was or was not covered.

Yours,
Joel


Yaakov Stein wrote:
> Could you change the wording "BSD License" to "revised BSD License"
> to avoid confusion with the "original BSD license"
> that contained the infamous "advertising clause" ?
> 
> Is pseudocode covered by the terms of redistribution of source code in 
> section 4 ?
> The last line of the list of code component types is "classical programming 
> code".
> Does this imply a requirement that the code can be parsed by some means ?
> 
> Y(J)S
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Proposed Revisions to the IETF Trust Legal Provisions (TLP)

[Yaakov Stein]

Could you change the wording "BSD License" to "revised BSD License"
to avoid confusion with the "original BSD license"
that contained the infamous "advertising clause" ?

Is pseudocode covered by the terms of redistribution of source code in section 
4 ?
The last line of the list of code component types is "classical programming 
code".
Does this imply a requirement that the code can be parsed by some means ?

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPR/Copyright

[Yaakov Stein]

> I don't understand why you think a document that is built on one
> that uses pre-5398 text but was published, say, this year with
> the disclaimer is different from one that uses pre-5398 text but
> was published in the middle of last year.  

I don't think there is a difference.
I was only warning that people shouldn't think that this is going 
to go away any time soon. I am sure that when people build on 
some recent RFC they will be thinking that it is all covered,
but if that RFC built on a yet older one, the problem remains.

> Whatever we do, there will be documents for a very long time
> that have roots in pre-5378 materials.  Whether those roots are
> significant depends, presumably, on how much text was carried
> forward not on how many times it was carried forward, so I don't
> see a "second derivative" issue that is any different from the
> first one.

Over time the original work becomes diluted (in quantity and quality), 
and eventually effectively disappears.
There is a lot of case law regarding this issue,
and it all hinges on transformativeness.
The more new material there is, and the more the original material is 
reinterpreted, 
the more likely it is that the use of the original material
will be considered fair use.

One rather recent case is Sheldon Abend Revocable Trust vs. Spielberg,
where it was claimed that Spielberg's movie Disturbia borrowed
from Hitchcock's "Rear Window" which was based on a short story by Woolrich
the copyrights for which are owned by the trust.
Hitchcock did obtain a license, but Spielberg didn't.


Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPR/Copyright

[Yaakov Stein]

> I note that, if the community's preference is really the second
> choice, then we are finished.  The Trustees would presumably
> follow the general rough consensus on this list, interpret the
> existing workaround as permanent, and  we would all move on.

Well, almost finished.

If a draft using the workaround becomes RFC and someone wants to
reuse material from it, the latter work becomes a "second derivative".
So we will need to use the workaround for some post-5398 RFCs as well.
In fact, a recursive algorithm is needed to determine whether or not
to use the pre-5398 language.


Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

request for community assistance regarding TICTOC requirements

[Yaakov Stein]

Hi all,

The TICTOC WG is finalizing the scope of its requirements draft.

As of now the draft has information regarding the timing requirements for
-Cellular Backhauling
-Circuit Emulation
-Test and Measurement
-ToD over the general Internet
we have still unintegrated information for
-Sensor networks
-Legal uses of time
-Industrial Automation
and we have removed two applications for lack of interest or feasibility
-Remote Telco
-Electric power distribution.

We are still soliciting help in gathering requirements information for
-Uses of precise time in networking
-Metrology
If anyone can help in these latter applications, please contact the TICTOC 
chairs.
If no interest is expressed, we intend removing these applications from the list
of applications being considered.

In addition, if someone feels we missed an application that requires
distribution of timing information, it is possibly not too late to consider its 
inclusion.

Thanks

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Consensus Call for draft-housley-tls-authz

[Yaakov Stein]

> Once again, I wish non-lawyers would ask question before interpreting the
> patent law. The experimentation exception referred to in that wikipedia
> article [§271(e)(1) or "Hatch-Waxman" exemption] is largely relevant to
> pharmaceuticals in process of tests and experiments for regulatory approval.
> It has nothing whatsoever to do with software that doesn't get approved by
> anyone. 

This is one application, however in Madey vs. Duke the appeals court 
for the Federal Circuit allowed an experimentation defense for purposes of
"amusement, to satisfy idle curiosity, or for strictly philosophical inquiry"
as long as this experimentation is not 
"in furtherance of the alleged infringer’s legitimate business".

Internationally, Article 30 or TRIPS allows member states
to provide experimentation exceptions unrelated to regulatory issues.

The experimentation defense is also known in common law,
and was upheld in Whittemore v. Cutter in the early 1800s.


Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IETF copying conditions

[Yaakov Stein]

> Actually, it isn't trademark protection, at least in any of the usual senses.

> But it may be fraud, or at least misrepresentation of the product.

Well, actually that is almost the same thing.

A (common law) trademark is defined as a distinctive sign used by a legal entity
to uniquely identify the source of its product to consumers,
in order to distinguish them from products of others.
(Note that it need not be registered in common law jurisdictions, although 
registration has advantages.)
>From the beginning trademark infringement has been associated with the
common law tort of "passing off".

In the US the Lanham Act was enacted specifically to deter false or misleading 
statements
in advertising or promotion that may harm the holder of a mark.

In economic theories of law such marks are justified by the lowering of 
informational costs
for the consumer, who can be sure that once it is ascertained that a product 
fulfils a need,
a subsequent product bearing the mark is essentially the same as that 
originally tested.

This maps rather directly to the issue at hand.
The IETF as a legal entity used the term SMTP to designate a particular 
protocol.
Although the IETF is not technically the source of all implementations,
the RFC (and especially one with reference code) can be considered the source
which was being protected.
If one were to apply "SMTP" to a protocol not conforming to RFC 2821,
that would be passing off that protocol to consumers
by making misleading statements.
Furthermore, as it would not interoperate with RFC 2821 conformant 
implementations,
the information costs would be increased
as each time the term was used one would have to test interoperability.

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-rfc-image-files-00.txt

[Yaakov Stein]

> I was never able to get the LaTeX style file to work such that I got 
> perfectly-formatted output acceptable to id-nits.
> (And id-nits was quite a bit less rigorous the last time I tried this.)

Which is precisely the reason that the style file will need constant upkeep ...

Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-rfc-image-files-00.txt

[Yaakov Stein]

> and there may be others that I don't know about.

A long time ago I used TeX. There was (and I believe still is) a LaTeX style 
file.

TeX was the distinct advantage that the source is pure ASCII
(and there are spelling checkers, bibliographic tools, etc.)
but the results are presentation-quality, including graphics.

It also is much richer in features than xml2rfc,
and has been debugged much better
(Knuth offers monetary rewards for finding bugs,
and doubles the reward each time).

(I had considered developing a new LaTeX style file and writing some tools
to go with it. But then I realized that once I "volunteered" to do that,
I would have to continue maintaining it for all time.)

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Simpler than draft-rfc-image-files-00.txt

[Yaakov Stein]

> Pardon my reverse-parochialism, but I think the need to be able to
> spell editors' and contributors' names correctly, and give examples of
> messages containing payloads which are not expressible in 7-bit
> characters, dwarfs in importance the need to decorate RFCs with
> pictures.  -Tim

But then again the spell-check and name-checking
would assumably be in the ASCII portion of the text
(leaving aside L8N author names for the moment)
and all that wuld be needed is for the RFC editor to
run the checks on the text portion of the document
before making the final copy.

Making again the point made hundreds of times before,
the figures are not there for decoration.
I personally had to abandon writing drafts on 2 occasions
because I could not capture equations or formal diagrams.
One became a patent application instead of becoming IPR-free
(interestingly, patent offices the world over allow modern formats,
and archive granted patents going back to their beginnings)
and the second became an ITU-T Recommendation
(where PDFs are the normative format).


Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: draft-rfc-image-files-00.txt

[Yaakov Stein]

This draft tries to solve ONE of the problems we were attempting to solve
in draft-ash-alt-formats (now expired),
namely, handling figures that are hard to render in ASCII art.

On the other hand, the proposed solution reminds me of the state-of-the-art
in the 1980s when I had to submit academic papers with the all figures at the 
back.
This makes it hard to read and hard to understand.
When reading on a screen (and we don't want to force people into printing 
everything)
it will be extemely difficult to see the figure and the relevant text at the 
same time.

One solution would be to have a tool that merges the two files on the screen.

In any case, if we have agreement as to a format (e.g. PDF/A) to be used for 
non-ASCII,
then why not use that format for the entire draft ?
If we ARE worried about the survivability of the non-ASCII file,
then this proposal does not solve anything,
as the figureless ASCII version will be incomplete.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: lateral approach to SS7/VoIP over satellite

[Yaakov Stein]

Dear Rubin

The only US patent I see granted to WTL is 6958999 from 2005.

If the subject of your IPR is the aggregation of multiple VoIP payloads
into a single packet in order to reduce overhead,
various methods to do this have already standardized in RFC 4170,
RFC 5087 section 5.2, and ITU-T Y.1452,
and have been widely deployed for the last 10 years.

Can you explain what is new or give a pointer to the application publication 
number ?

Y(J)S


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rubin Rose
Sent: Wednesday, August 13, 2008 3:29 PM
To: ietf@ietf.org
Subject: lateral approach to SS7/VoIP over satellite

Dear members,

I was inspired to submit content in order to explore the potential for 
integration of NOP into current revised standards for transmission of SS7 over 
IP over satellite.

If this content is deemed too commercial for this readership kindly advise or 
direct me towards a more appropriate audience; a brief overview of the concept 
is included in the text below related to a joint development successfully 
completed with ESA (European Space Agency): The complete article is covered in 
the attached link, and a separate .xls file includes calculation parameters for 
NOP benefits over SIP and H323.

"WTL has an excellent track record in providing equipment for voice services 
using satellite trunking and has over 100 systems deployed around the world. 
The company's key strength in this area has always been the superior 
bandwidth-saving capability of WTL's patented NOP (Network Optimisation 
Protocol).
The Artes 4 contract provided joint funding for a series of developments 
designed to make WTL equipment perform an even better job for telecom operators 
wishing to use these emerging low cost satellite services. One aspect of the 
ESA project was to modify NOP to operate efficiently over DVB-RCS services. The 
lower price point of DVB-RCS equipment and space segment means that this is of 
great interest to operators, particularly in the developing world."

Regards,



Rubin Rose
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

[Yaakov Stein]

 
All three categories are absolutely needed.

It is self evident, although unfortunate,  that the "accepted" category
will be used.
Even after WG, IESG, IETF LC, and the RFC editor, some errors make it
through.

>From my experience with RFC errata, the "rejected" category will also
definitely be used.
I have seen some entirely erroneous comments
(for example claiming that pseudocode for packet processing could not be
correct
since the loop over packets never terminates - the proposed fix was to
decrement
the packet size each time and terminate when the packet size reached
zero!),
and some pretty useless rewordings.

Although we can quibble over the nomenclature, the "archived" category
has several uses.
One example is when the erratum submitter was not a WG participant,
and truly could not understand what was intended (at least without the
authors explaining what they meant).
If the RFC is ever obsoleted by a newer one, this will serve as a
reminder to rewrite that passage.
Another example is when the RFC suggests a method to handle an
exception, 
while a simpler method is inherent in the protocol itself.


Y)J(S
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

transitioning email rules

[Yaakov Stein]

I assume that others have come across this problem as well,
but I haven't seen anything mentioned about it on this list or the IETF
sites.
 
I receive over 500 non-spam emails every day (peaks can reach 1000).
These include emails from about 15 IETF lists, 
about 25 other standardization lists, some 20 lists on technical topics,

multiple internal corporate lists, (and even a few emails sent only to
me).
 
The only way I can deal with this load and maintain my sanity
is by using a large set of sorting rules.
I have quite a few rules dealing with IETF emails that all worked well
until the transition.
 
Some of my rules look for [WG-NAME] in the subject line.
However, some WG lists (e.g. L2VPN) do not use this convention .
Also, I sometimes have trouble when I forward an email to someone "for
information"
who then returns an urgent answer leaving the subject line intact.
 
Some of my rules WERE based on the sender, 
for example, mails from [EMAIL PROTECTED]
With the transition the sender changed to
[EMAIL PROTECTED]
 
I exchanged emails with [EMAIL PROTECTED] and was told that this
kind of change was here to stay. Being somewhat skeptical I decided to
change
the logic and to focus on the list to which it was sent, rather than the
sender.
I had avoided this in the past, since frequently people email someone
else 
and only cc the list, making the logic more intricate.
 
These new rules work some of the time, but not always.
For example, in the past emails to the MPLS WG list 
(that were from [EMAIL PROTECTED] but now come from
[EMAIL PROTECTED])
were sent to [EMAIL PROTECTED] . I modified my rule to flag this list
address.
But now the emails are being directed to [EMAIL PROTECTED] !
 
Would it be possible to post information that would help here ?
What is constant and can be relied upon ?
Would it be possible to set up guidelines for WGs to follow,
including those (e.g. NTP) who use non-IETF domains ?
 
Y(J)S
 
___
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf

RE: Anyone else having trouble reaching tools.ietf.org?

[Yaakov Stein]

> Is anyone else having trouble reaching http://tools.ietf.org ? Over 
> the past few weeks I've found that I'm often unable to reach the 
> server at tools.ietf.org.  I'll click on the URL for an 
> Internet-Draft, for instance, and in a minute or two I get back the
good old Firefox "Server not found"
> error.  I try to ping the server and all packets are lost.  

I had problems last week. 404'ed for an hour or so, pings lost.
Since then everything has been fine.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IPv4 Outage Planned for IETF 71 Plenary

[Yaakov Stein]

 
> The only thing that looks plausible is "Microsoft TCP/IP version 6".

Tha's what I used, and I can now ping with IPv6.

I too wondered which of the three -  TCP, IP or Microsoft  - was version
6.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IPv4 Outage Planned for IETF 71 Plenary

[Yaakov Stein]

 
> During the IESG/IAOC Plenary at IETF 71, we are going to turn off IPv4
support on the IETF network 
> for 30 to 60 minutes.  We will encourage the audience to use the
Internet and determine which services 
> that they have come to take for granted remain available.

Is there an assumption here that no-one is listening to the plenary
presentations anyway?

I sure wouldn't want to be showing slides when everyone is trying
to get their connectivity up. In fact, the shouting back and forth
of solutions to various problems will probably drown out the mike.

Why don't we dedicate a separate 2 hour plenary just to this experiment 
with the moderator announcing workarounds and collected statistics ?

Y(J)S
 


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Westin Vancouver Update

[Yaakov Stein]

I would like to add my thanks as well.

The contrast between IETF/Neustar and the Westin staff (who still can't
get my reservation right) is quite striking.

Y(J)S

-Original Message-
From: Ted Hardie [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 29, 2007 7:24 PM
To: Ray Pelletier
Cc: [EMAIL PROTECTED]; ietf@ietf.org
Subject: Re: Westin Vancouver Update

At 10:55 PM -0800 11/28/07, Cullen Jennings wrote:
>Wow. That greatly exceeded my expectations for a resolution. Thanks to
everyone who made that happen.

I agree, and I second the thanks.  I want to thank, in particular, the
Secretariat staff who volunteered to be relocated.  Given the current
situation and the enormous amount of work that they do to put on an IETF
meeting, this is an act of selflessness that goes beyond the
professionalism and kindness we have come to expect.  It means,
basically, that they will be adding time and removing rest opportunities
from days that are  already longer and busier than even those of the
IESG or IAB.

Many thanks,
Ted


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Westin Bayshore throwing us out

[Yaakov Stein]

> I will be certainly be writing letters to the Bayshore and their parent
> company to express my displeasure, and I hope that the IETF will
> remember this week's events the next time it considers holding a meeting
> at a Starwood Hotel.

and while we are at it...
 
We will need cloak room service 
(at least for those who require a heavy coat to walk 5 blocks in freezing 
temperatures).
It assume that the Westin will waive the charge this service usually entails.
 
Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Westin Bayshore throwing us out

[Yaakov Stein]

The Westin Bayshore just called me to tell me that they are undergoing 
renovations,
and so unfortunately they are kicking me out of the room that I had reserved in 
early September.
 
They offered to put me up in the Renaissance 5 blocks away,
but, when asked, told me that the night time temperatures are close to,
or below freezing.
 
I am sure that many of you consider zero Celsius a reasonable temperature,
but I don't. 
 
The hotel would not tell me how many people were being relocated
in this fashion, but apparently there are many.
 
I made travel plans based on a confirmation from the hotel that 
the IETF selected as venue, and less than a week before arrival
the hotel throws me out with no recourse.
 
I then asked the hotel if they were going to provide a shuttle service,
and they said that they would have to consider it.
 
I think that the IETF should insist on this as minimal compensation
for those who are being downgraded in this fashion. 
 
 
Y(J)S
 
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Patents can be for good, not only evil

[Yaakov Stein]

Larry

Sorry that I answered before seeing that others
had already said the same thing.

However, even after reading your subsequent email,
I am unconvinced.  Requesting a re-examination
is a lengthy process, and if unsuccessful further
strengthens the party holding the patent
(as it has gone through 2 examinations).

On the other hand, the patent holder can force you
to respond in a Texas court within 30 days,
incurring the costs of representation.

BTW, this kind of patent busting is hardly new.
There used to be a "patent busters" site
where bounties were offered.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Patents can be for good, not only evil

[Yaakov Stein]

 
>> I specifically applied for patents underlying the technology behind 
>> RFC 4722/RFC 5022 and RFC 4730 specifically to prevent third parties,

>> who are not part of the IETF process, from extracting royalties from 
>> someone who implements MSCML or KPML.

> That was a waste of your time and money. Publication of those
inventions by you, at zero cost to you and others, 
> would have been sufficient to prevent someone else from trying to
patent them. 

Quite untrue, in my experience.

The patent examiners almost never find prior art from the open
literature.
Their decisions are based on their databases of existing patents.

So althought you are quite right in principle,
open publication has low probability of blocking someone from getting a
patent. 

Fighting a granted patent on the base of open publication prior art
would cost much more.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

FW: ITU-T Recommendations

[Yaakov Stein]

This should interest many of you ...
 
Y(J)S



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 17, 2007 2:34 PM
Subject: ITU-T Recommendations




The ITU Sales and Marketing Division would like to inform you that in
view of the overall success of the recent trial, the policy of free
access to ITU-T recommendations has recently been adopted on a permanent
basis by ITU Council 2007.

This new policy includes free-to-the-general-public access to in-force
and superseded ITU-T Recommendations (posted in .pdf format only).  

Additionally, contributing ITU Members and Sector members (including
Associates) may also access all pre-published ITU-T Recommendations as
well as ITU-T Recommendations in other formats not limited to .pdf (via
their TIES password only).  Non-members would still be required to pay
(via an annual Online Subscription or individual pay-per-download) to
access pre-published and non-.pdf formats, or otherwise purchase the
quarterly-released DVD of ITU-T Recommendations.

We should also remind you that this information is relative to ITU-T
Recommendations only. 

For more precise information on this offer, or on ITU Publications in
general, please do not hesitate to contact us directly via return email.

We trust this information proves useful and thank you for your continued
support of ITU Publications.  
Best Regards, 
ITU Sales & Marketing 
[EMAIL PROTECTED] 
Place des Nations 
1211 GENEVA SWITZERLAND 
Fax +41 22 730 5194 
www.itu.int/publications   


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Last Call: draft-ietf-hubmib-efm-cu-mib (Ethernet in the First Mile Copper (EFMCu) Interfaces MIB) to Proposed Standard

[Yaakov Stein]

Sorry for the nonsubstantive content, but ...
 
The Abstract of this draft refers to IEEE Std 802.3ah-2004.
This was the output of the EFM task force,
which completed its work several years ago.
All content has been absorbed into the 2005 version of 802.3.
 
In particular, generic issues on copper are in clause 61, 
10PASS-TS is covered in clause 62 and 2BASE-TL is addressed in clause
63.

Although the inclusion into the base standard is mentioned later on in
the document,
the precise clauses are not, and the 802.3ah nomenclature persists
throughout the document.

This behavior is similar to another forum insisting on referencing an
Internet Draft, 
even after an RFC has been issued.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Warning - risk of duty free stuff being confiscated on the way to Prague

[Yaakov Stein]

 
> I believe there are similar issues for travel to the US 

yes, I just had my bottle of water confiscated in Dallas airport
(coming back from another convention at the same hotel as IETF65)
and had to buy another bottle (of precisely the same type) two steps
after the security check.

It seems that the airport stores have figured out how to profit
from these rulings, just as the airlines profit from the photo-ID
requirement.
So don't expect this to go away ...

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: IETF IP Contribution Policy

[Yaakov Stein]

 
Larry Rosen, 

It is indicative of your letter's content that the introduction
informs us that the IETF is the SDO responsible for Ethernet
and WiFi (well, they both start with IE don't they?).

Getting down to the letter itself.

  IETF, the most democratic and open of standards organizations, 
  is proposing a contribution policy that, simply put, may result in
standards 
  that are not truly open for implementation and use in open source
software. 
  This draft formal policy ... expressly omits any patent licenses.

Do you expect us to issue an RFC stating that anyone who submits an ID 
automatically grants a world-wide royalty-free license to use the
described technology ?

I doubt that this is a reasonable expectation.
Many IETF participants do not have the authority to grant such license
terms,
and even were all authors to grant such licenses,
I assume that you realize that their may be other parties
holding IPR rights who have not participated.

So I guess you furthermore expect anyone who submits an ID
to indemnify eveyone with regards to third party IPR rights?

These issues have been around for years, 
and the reasonable path, taken by the IETF, ITU and most other SDOs
is to require participants to disclose their IPR,
and to encourage them to disclose any IPR about which they know.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: MUST implement AES-CBC for IPsec ESP

[Yaakov Stein]

 
Russ Housley wrote:
> During the IETF Last Call for draft-manral-ipsec-rfc4305-bis-errata, 
> we received a comment that deserves wide exposure.
> 
> For ESP encryption algorithms, the document that was sent out for Last

> Call contains the following table:
> 
>   RequirementEncryption Algorithm (notes)
>   ---
>   MUST   NULL (1)
>   MUST-  TripleDES-CBC [RFC2451]
>   SHOULD+AES-CBC with 128-bit keys [RFC3602]
>   SHOULD AES-CTR [RFC3686]
>   SHOULD NOT DES-CBC [RFC2405] (3)
> 
> The Last Call comment suggests changing the "SHOULD+" for AES-CBC to 
> "MUST."
> 
> I support this proposed change, and I have asked the author to make 
> this change in the document that will be submitted to the IESG for 
> consideration on the Telechat on January 25th.  If anyone has an 
> objection to this change, please speak now.  Please send comments on 
> this proposed change to the iesg@ietf.org or ietf@ietf.org mailing 
> lists by 2007-01-24.
> 
> Russ Housley
> Security AD

Strangely missing is AES/GCM [RFC4106].

SHOULDn't this be a SHOULD ?

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

event calendar

[Yaakov Stein]

When clicking on 
http://www.ietf.org/meetings/events.cal.html
one gets the event 
calendar that was posted a while ago.
But within a few 
seconds the page refreshes and one is sent to http://geneva.isoc.org/events/,
which is a quite 
different, and much more limited list.
 
I understand that 
the list maintenance is best-effort 
and that itt is 
available in text format,
but is there some 
reason for the html format to be hidden ?
 
Y(J)S
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: WIPO issues (was: Network Endpoint Assessment (nea))

[Yaakov Stein]

To qualify for protection, an industrial design must be aesthetic, 
and I believe that elegant design should be one of our goals in protocol
design.

However, industrial designs are "divorced from all technical aspects of
the article",
and thus at least some small portion of our ongoing work may be
ineligible for protection.

A major obstacle to be overcome before applying for design protection
for our work 
is the fact that ASCII RFCs can not contain lines or colors,
and would probably be rejected by the appropriate national offices.

Finally, please note the treaties:
   Terribly Complex Protection for Intellectual Property (TCP/IP)
   Ugly Dumb Protection for Intellectual Property (UDP/IP)
may directly impact our work.

Y(J)S





___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Why cant the IETF embrace an open Election Process

[Yaakov Stein]

Title: RE: Why cant the IETF embrace an open Election Process ratherthansome






I am somewhat surprised that no-one has actually answered the 
question
why DO we use a noncom rather than open elections?
 
I think that one answer to that question is quite 
simple.
In open elections where all meeting participants
or all active WG participants take part,
there would be a strong bias towards large 
corporations
who can afford to devote a large number of representatives.
 
In fact, we could rapidly find the IETF effectively kidnapped
by one or two companies, stifling creativity and serving to 
further their narrow economic interests, rather than 
those
of the developer and user communities at large. 
This would undermine the whole purpose of the IETF.
 
The noncom has built-in restrictions that work to keep 
the
IETF diverse and responsive to a wide community.
 
Isn't it easier to answer the question asked rather than 
indulging in the content-free discussion we have just 
witnessed?
 
Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Fixing the algorithm

[Yaakov Stein]

> "The philosophers have analysed the IETF election process in many
ways, the point is to change it"

Actually, the entire process was pre-analyzed in RFC 3979, 
but the analysis was ignored.

As RFC 3797 specifically says, the fair and unbiased method 
is to order the candidates using a random process of sufficient entropy,
and then select the first ten to serve on the NONCOM.
Should one of the 10 turn out to be ineligible or decline to serve
or be disqualified for any reason, the next (11th) candidate is added
to the NONCOM.

As has been stated here on several ocassions, 
the fairness is destroyed by giving any latitude to anyone 
(NONCOM chair, ISOC president, etc) to influence the outcome.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Now there seems to be lack of communicaiton here...

[Yaakov Stein]

> I haven't kept count, but I think it's more evenly split (especially
since Jeff's message quoted above).

Just another comment following up on my previous email.

Allowing this list to influence the outcome is just as bad
as allowing the NONCOM chair to decide.

In the weekly posting summary there are usually less than 50 posters.
It would not be hard for someone (or some small group)
to put together 20 sock-puppets and influence the "majority opinion"
here.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: RFC 4612 - historic status

[Yaakov Stein]

Brian

The details of whether one branch of the MIME tree or another
is best suited for the application is definitely more suitable for the
RAI area.

The fact that this problem is not discussed in the RFC
and the historic designation is misleading,
is a good subject for this list.

I personally think something needs to be done,
such as publishing a bis version with informational
designation and an IESG note about the advisability
of using the audio MIME type.

Y(J)S

-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED] 
Sent: Monday, August 14, 2006 11:23
To: Paul E. Jones
Cc: 'John C Klensin'; [EMAIL PROTECTED]; 'Eliot Lear'; ietf@ietf.org
Subject: Re: RFC 4612 - historic status

I suggest that instead of disturbing a couple of thousand people with
this discussion, it would be profitable to take it up with the RAI Area
Directors. They certainly know more about it than I do.

 Brian


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: RFC Editor RFP Review Request

[Yaakov Stein]

 
> That vast number does not establish the credibility of the series; the

> original ones do.

IP, TCP, UDP, etc would not cease to be used 
if either the IETF or the RFC editor disappeared,
or even if their original RFCs forgotten.

The main importance of the RFC series is the 
demonstration of continuity
from the early roots and the present IETF work. 

The "credibility" of the original standards (not the "series") is
important,
but were there a gap between then and now, 
the series would be rendered useless.

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: RFC 4612 - historic status

[Yaakov Stein]

 

> Because the IESG believed that specifying an image format as an audio
subtype was to be discouraged, but should be documented for reference.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_comment&;
id=42143

> The standard MIME type for T.38 is image/t38 (RFC 3362).


I would agree if T.38 were an image type. It isn't.

The image format for group 3 faxes is given in T.4 and NOT in
T.30 (procedures for group 3 over PSTN) or T.38 (procedures for group 3
over IP).

Furthermore, T.38 specifically states that it  
"defines the procedures to be applied to allow Group 3 facsimile
transmission between terminals 
where in addition to the PSTN or ISDN a portion of the transmission path
used between terminals includes an IP 
network, e.g. the Internet."

Note the statement "in addition to the PSTN ...".
T.38 presupposes that if one wants to transfer an image
over an IP network, then one would send an image file.
 
What T.38 does is to relay the T.30 fax (audio signals)
across an IP network.

In any case, as there is no IESG note at the beginning, 
and no mention of the image/t38 MIME type anywhere,
the IESG's intent is not clear from the RFC.

On the contrary, one gets the feeling that the use of RTP
is being declared historic, leaving UDPTL.

Y(J)S



___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RFC 4612 - historic status

[Yaakov Stein]

According to RFC 
2026 historic RFCs are those whose
specification has 
been superceded by a more recent specification.
 
RFC 4612 is labeled 
historic, and defines a MIME type
for T.38 over RTP, a 
practice that is just now being adopted
and to be 
encouraged.
 
Indeed, the RFC 
discusses limitations of UDPTL,
but it does not 
suggest deprecating its use.
In any case the 
subject of the RFC is the RTP mode,
and not 
UDPTL.
 
So why the 
"historic" designation?
 
Y(J)S
 
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: RFC Editor RFP Review Request

[Yaakov Stein]

> Why is this true - I am not saying its not but its an assertion that
is undocumented and unsupported. 

Well, we could do a process experiment. 
No standards-track RFCs for 5 years,  and the start afresh. 
Not sure I would support experiment, but I can't think of any other way
to prove the tenets.

Actually, even that experiment wouldn't be proof without a control
group.
So perhaps we should try 5 years of RFCs only for the western hemisphere
and see if the eastern hemisphere has faith in the RFC series 5 years
later.

> So how does this work - why would the series be less valuable and
because of what - 

In psychophysics there is the concept of the Just Noticeable Difference
or JND.
The JND is the minimal change in the physical world that produces a
noticeable
effect on the senses. JNDs are the main experimental method for studying
the 
so called mind-body connection problem.

Imagine sitting in the desert before sunrise. At first everything is
dark,
and then you perceive a small amount of light. That is the first unit.
Then after a while you can say that you have seen an increase in the
amount of light. Two units. In that way you continue until full sunlight
(N units). It turns out that the JND units are logarithmically related
to the amount of light as measured by a photometer; i.e. when it was
still relatively dark we notice very small changes, 
but once the sun is half up tremendous increases can go by un-noticed.

Now imagine sitting watching Internet technology develop.
At the beginning every addition was immediately noticeable.
IP, TCP, ICMP, etc each were a JND. Over time individual RFCs
that may make giant contributions and require much more sophistication
are no longer considered major steps, perhaps only the entire
output of a WG, dozens of RFCs, maps into a single JND.
(This does not denigrate high number RFCs as compared to low number
ones,
it is just a feature of the body-mind mapping.)

However, each JND is conceived as one more step in a path to
enlightenment.

Now consider what woud happen were we to cover the person sitting in the
desert 
with a black cloth after 1/2 hour of observing the minute changes,
and then uncover him. He would immediately note a giant change in
the amount of light. He would certainly not be able to quantify the
change
or on its basis tell how much time had elapsed,
and may even not be sure that he was still in the same place.

Loss of physchological continuity would cause Internet standards
observers 
to lose faith in the new work being done, which would no longer be
considered
a direct consequence of continuous development efforts.
New work would seem unnecessary and overly complex, the jump
would simply be too many JNDs for the mind to grasp.

> this is a key question in establishing a value propisition for the
IETF's wares.

Agreed.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: [INDEP] Re: RFC Editor RFP Review Request

[Yaakov Stein]

>   Your last statement - that a break in the series would
invalidate it - argues very forcibly that no such "gap" can be allowed
to occur going forward (unless you are of the opinion that IP, TCP, UDP
etc. are "done evolving").  Hence, something would have to take the
place of the IETF and the RFC series practically immediately.


What I said was that a gap in standards-track RFCs would render the
series useless.
Were we to be foolish enough to allow a prolonged hiatus in the RFC
series,
there would be other SDOs more than willing to take over
maintenance and extension of the IP suite,
of course labeling the resulting standards "Implementation Agreements"
or 
"Recommendations" instead of "RFCs".

More importantly, later IETF work (even if called "RFCs")
would not be readily viewed as a natural evolution of the original IP
standards,
and would require us to actively market them.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Re: RFC Editor RFP Review Request

[Yaakov Stein]

 
> That vast number does not establish the credibility of the series; the

> original ones do.

IP, TCP, UDP, etc would not cease to be used 
if either the IETF or the RFC editor disappeared,
or even if their original RFCs forgotten.

The main importance of the RFC series is the 
demonstration of continuity
from the early roots and the present IETF work. 

The "credibility" of the original standards (not the "series") is
important,
but were there a gap between then and now, 
the series would be rendered useless.

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: The IETF 66 Attendees Alias

[Yaakov Stein]

> Having a per-meeting special list has an obvious and reasonable basis.
> However it makes each meeting's list a special case for IETF
administration and for attendees.  
> Possible variations to consider:

I think the best variation is automatic resgistration to meeting list,
but to use this list only for urgent messages (either from secretariat,
or allow from others bu moderated to allow only urgent messages
through).

All messages about download speed of cookies and healthfullness of WiFi
should be directed to discussion list. This way everyone's existing
email rules 
function as desired, and the emails are archived so that we can later
compare
meetings from the point of view of cookie speed, WiFi health, etc.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: The IETF 66 Attendees Alias

[Yaakov Stein]

Ray, 

I sent a similar email in reply to the endless thread on Internet access
at the Delta.

Please only allow emails to the participants list from IETF personel
for important meeting-related information.

Y(J)S


___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Call for Artworks! 'Graphic & Drawing' Deadline 25th July 2006.

[Yaakov Stein]

 
How is this event related to the IETF?  This is the third e-mail I've
seen to ietf@ietf.org about this event, but I have yet to figure out how
it's related.  Can you please clarify the connection for me?

[YJS] Maybe it is in response to the thread about graphics in RFCs   :->




___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Yaakov Stein]

 
> How about people volunteer to help the effort or how about we fund the
RFC Editor to work with the XML2RFC people?  
> Simply having a working group does NOT produce running code.  Let's
not have committees unless we have an answer to this question.

Eliot

The simple answer is that the IETF should be developing
neither a document creation tool nor a tracking tool,
nor funding the creation or such tools,
nor setting up committees to develop specifications for such tools.

There are perfectly good document creation and tracking tools available.

When are we going to get back to work relevant to the IETF?

RFC 3935 is effectively a charter for the IETF as a whole.
It states

   The mission of the IETF is to produce high quality, relevant
   technical and engineering documents that influence the way people
   design, use, and manage the Internet in such a way as to make the
   Internet work better.  These documents include protocol standards,
   best current practices, and informational documents of various kinds.

I believe that some people are mis-interpreting this statement.

I propose adding as explicit non-goals 
 * the developing of new document creation tools
 * the developing of new version tracking tools
 * the development of new document archival processes

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Yaakov Stein]

 
Hmm.   With Word, for instance, virtually every correction to
the text results in a huge clutter of change-tracking notes about format
changes and similar drivel.  
For many documents, it makes the S/N ratio just miserable.   If there
were a "track
substantive textual changes only" option, an "ignore format changes"
one, or some sort of "accept all format, font, and style changes"
command, 
I'd probably agree with you about utility.  But, given the reality of
those systems today, I tend to agree with Ned, 
even though I like a feature of those system that you didn't mention 
(the ability to insert comments whose appearance in the output can
easily turned on and off.   and some processing options comes
close, 
but isn't quite the same).

[YJS] My experience has been quite different.

I work, on a daily basis, with many extremely complex Word documents
each of which is handled by many different people (often with
conflicting aims).
These documents often go through dozens of revisions.

And although (as mentioned often before) I am no great fan of Word,
I have never seen S/N problems of the type you mention.

I suspect that your co-authors are really fooling around way too much
with presentation aspects rather than content.
Next time agree on a ground rule that first the ideas should be
gotten right, and leave the pretty-printing for the final round.
Not only does this make sense and save everyones time, 
it will probably eliminate your S/N problem. 

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Image attachments to ASCII RFCs (was: Re: Last Call: 'Propose d Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats))

[Yaakov Stein]

 
As we have announced at several plenary reports (does anyone ever pay
attention??), 
the RFC Editor has been trying to work with the xml2rfc fraternity to
make xml2rfc into an effective document formatting tool.
It has not been quick or easy.  I just checked with one of our editors,
Alice Hagens, who uses xml2rfc regularly.  
She tells me that she entered several issues into the xml2rfc tracker,
but she does not think "anyone is looking at it any more."  

[YJS] I have heard it several times.

But when I say that we have a problem in developing the document
handling tools,
people on this list tell me that we aren't even doing any development,
that this is just a groupd of volunteers, and that their progress in no
way
effects the process.

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> Because it's sufficient to generate the ASCII version once on
publication and then keep it. 
> Keeping the source is essential for completely separate tasks (meta
data extraction, document revision, generating other formats such as
HTML or PDF).

You are using "the ASCII version" as a proxy for a printed page 
(and as I once complained, it is not a faithful proxy on all platforms).
However, the problems we wanted to solve were precisely those where
ASCII
is not sufficient, namely graphics and equations, and so we need
to return to the printed page as the final word.

> So far the IETF hasn't done that. The format is ASCII.

See above.

> One good reason to use a specific XML grammar is that when the only
thing that's available is a presentation-oriented format 
> (such as Word or PDF), it gets *much* harder to do meaningful things
with the source. 

You are making assumptions about presentation formats.  
It is quite easy to do meaningful manipulations on TeX source.

> And that's one of the reasons why volunteers maintain xml2rfc (both
the format itself and various implementations). 

And here is precisely where we are expending efforts.
I too enjoy coding, but why are we recreating for the XML2RFC
environment
mechanisms that exist in available tools?

The zenith of these efforts is a script to extract TeX-style math
expressions, run TeX on each separately, 
create images, and then embed them into a PDF created from the xml.
... and all that just to avoid using TeX.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> I would say that getting always the same printout is a non-goal.

Why? As has been stated previously, in most SDOs the "printed page"
is the final word. One of the many inconveniences of xml2rfc is the need
to add "vspace blankLines" to avoid unfortunate page breaks.

>You're comparing apples and oranges here. 
>For instance, you could use XSL-FO (an XML format...) which also is
closer to presentation markup than the RFC2629 XML format.

Why should the IETF be inventing new tools to create documents at all?
Why aren't we focusing on developing protocols for the IP world,
and adopting existing tools for the mundane task of document creation?

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> How about Tex?

> It is as old as the internet and you can use vi to read and edit.
> You still can use grep to scan all old documents to find something.

It is also the only method to always get precisely the same printout,
has the best equation typesetting, makes perfectly good diagrams,
and the source is pure future-proof ASCII.

And there are advanced tools for editing and comparison on all platforms

of which I know, for those who desire something a bit stronger than vi
and grep.

As I have said before, if we decide on TeX instead of XML
we solve all the problems.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

RE: Last Call: 'Proposed Experiment: Normative Format in Addition to ASCII Text' to Experimental RFC (draft-ash-alt-formats)

[Yaakov Stein]

 
> In total, assuming that those are for different documents, that is
still less than 1% if those RFCs published in that time period.

> I know some folks are vocal that there is a problem.
> But, the evidence suggests otherwise.

I don't understand the logic here.

Of course there are very few PDFs, since they are not normative
and you have to do all the ASCII work anyway.

Face with this requirement, people have several options
1) write partial and/or hard to understand descriptions
2) publish elsewhere
3) patent the ideas and charge us for them
(it says something about our process if a Government bureaucracy 
that insists on archaic procedures can handle figures and equations 
better than we can)
4) give up.

Y(J)S

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf