Re: [payload] [Payload] Last Call: (RTP Payload Format for DV (IEC 61834) Video)) to Proposed Standard

[Kazuhiro Mishima]

Hi Qin, Roni,

Thank you for comments.
I've just updated our draft as draft-ietf-payload-rfc3189bis-03.

See comments in-line please.


> 1. Section 1:
>
> [Qin]: It looks this version extends RFC3189 to support some new features.
> However I can not see any dependency to RFC3189 in the introduction section
> until
> I read the last section in this document, is it more straigtforward and
> clear to merge the section 7,8
> to the introduction section and clarify how this document is different from
> RFC3189.
>
> Roni: This document does not extend but obsolete RFC3189, so it should not
> reference it. As for the difference from RFC3189 I think it is better to
> have a separate section.

Now, I keep the section by Roni's comment.

> 2. Section 3.1.1
>
> [Qin]: In section 7, you claim you have removed SMPTE 306M, since it is
> covered by SMPTE 314M format.
> However in section 3.1.2, the value for SMPTE 306M is still kept in the
> encode list. So the question is
> where do you remove SMPTE 306M in this document? Why SMPTE 306M in the media
> type registration is still kept?
> Does this conflict with what you said in the section 7?
>
> Roni: Maybe change the first bullet of section 7
>
> " Removed SMPTE 306M, since it is covered by SMPTE 314M format"
>
> To
>
> "support for SMPTE 306M is only for backward interoperability, since it is
> covered by SMPTE 314M format"

I changed the sentence in 1st bullet of sec.7.

> 3. Section 3.1.1
>
>  [Qin]: Is it real that there is no interoperability consideration since
> Interoperability with Previous Implementations is discussed in the section 8
> of this document?
>
> Roni: Go od, add of this RFC

I added the "Interoperability Consideration" which refers to sec.8.

> 4. Section 3.2.1
>
> [Qin]: I believe it is not appropriate to spell this note out when this
> document is published but you may put
> it as errata or in the section 7.
>
> Roni: good point. Maybe discuss it in section 8, since this may be an
> interoperability issue

This discussion moved to sec.8.

> Also not that the syntax " <
>  span lan
> 0pt;font-family:"Courier New"'>a=fmtp: encode= encoding> audio=
>   bundled>"
>
> Does not have ";" before the audio while the examples have, I think that ";"
> should separate between the parameters.

I fixed the syntax.

> 5.  Section 3.2.1
>
> Roni: I do not see this as a major issue. It can stay from my point of view.
>
> 6. Section 3.2.1
>
> [Qin]: s/ a format specifc parameter/ a format of specific parameter
>
> Roni: the current text is OK
>
> 7. Section 3.2.1
>
>  [Qin] s/one of the following/one of the following value.
> One question is:
> How do you distinguish between required parameter or optional parameter in
> the a=fmtp line?
>
> 8. Section 3.2.2
>
> [Qin]: When you are talking about encode, you are using "encoding
> type","DV-video encoding", "type of DV format" in the section 3.2,
> and using "encode type" in section 3.2.2, should they be the same thing? why
> not use the same terminology for consistency?
>
> Roni: The only issue I see is in
>
> "The required parameter " which should be "The required
> parameter "encode""

I changed it.

> 9. Section 3.2.2"
>
> [Qin]: Does it worth a exmaple to expain how SDP Grouping Framework can be
> used to correlate audio with video data in the section 3.3.1?
>
> Roni: I think that there is example in RFC 5888, so I will leave it to the
> authors.

I mentioned about this example.

> 10. Section 3.3.1
>
>  [Qin]: What do you mean "when this is done"? It is not clear to me from the
> context.
>
> Roni: to me it looks like if what is said in the previous sentence.

I changed it as more clearly.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[John C Klensin]

Ray and IAOC,

I hate to keep bringing this up, but the discussions leading up
to BCP 101 and the oft-replated principle of "maximum amount of
transparency to the IETF community that can be reasonably
obtained" strongly suggest that documents that are intended to
evolve into RFPs be circulated in draft to the IETF community
for comment.  If there is some reason why that it not possible,
reasonable transparency suggests that the IAD or IAOC
proactively provide an explanation to the community, rather than
waiting to be asked.   

Community review of draft RFPs is particularly important
because, for reasons outlined in BCP 101, there is little
opportunity for effective community input once proposals are
received and contract negotiations start.

Each time this issue has been raised in the past, the IAOC has
agreed that exposing RFP drafts is The Right Thing to do, yet
RFPs keep appearing without opportunity for community review.

Two omissions from this document illustrates why community input
is important:

(1) I don't know how much experience IAOC members have with
trying to participate remotely, but, having done so, there are
insights into what is needed that one just cannot obtain by
physically attending a meeting and observing how things work.
If any RFP or subsequent contract does not provide for input
from, and probably interviews of, selected people who have tried
to participate remotely while carrying out various roles, then
the odds are high that the resulting work will not be adequate
in practice.  Instead, this RFP appears to provide only for
"observ[ing] group and plenary sessions" and then review of the
initial specifications by groups that are unlikely to include
the full range of remote participants.  

It seems to me that a call for comments from those with actual
remote participation experience and for contractor interviews
with a selection of those people.   There is a long history of
asking developers and tool-builders what users need.  The
perceived success level in having a process that is limited to
asking developers and tool-builders produce results that
actually match user needs has been abysmal. 

(2) The list of "Environments" is also interesting.  Whether
caused by health issues, travel limitations, or other
considerations beyond the control of the individuals, we've had
experience that has required remote participation of IAB and
IESG members, members of key committees (the RSOC and RFC
Editorial Board are on my mind at the moment, but, if the IAOC
itself has not been affected yet, I believe that is only a
matter of time).  At least parts of the meetings of those groups
are, properly, not open.  While most of those meetings are
scheduled far in advance, ad hoc sessions for which
participation by members who happen to be remote do occur.
Those bodies and meetings create remote participation
requirements that are quite different from the environments
listed -- small meeting support that goes well beyond "8 being
simultaneous at any one time", a need for session privacy, and a
need to accommodate meetings that are scheduled on relatively
short notice.

I don't fault the IAD or IAOC for failure to identify those
types of issues internally.  I do believe it reinforces the
importance of getting community review of RFP drafts so that
there is maximum opportunity for others to spot issues that the
IAD and IAOC have overlooked.

In addition, while I don't believe members of the community
should be required to read and study IAOC minutes to find out
that particular RFPs are under development so that they can
comment, I note that no IAOC minutes have been posted since
those for an IAOC meeting held on 27 July during IETF 81.

I recommend that the RFP be withdrawn until modifications such
as those suggested above can be discussed by the IAOC and
further input on draft RFP provisions sought from the community.
I also recommend that no further RFPs be issued until the
relevant IAOC discussions and decisions be properly recorded in
IAOC minutes and those minutes posted.

regards,
john



--On Wednesday, October 19, 2011 09:25 -0700 IETF Administrative
Director  wrote:

> The IETF Administrative Oversight Committee (IAOC), on behalf
> of the IETF, announces this Request for Proposal to develop
> the specifications for Remote Participation Services. The
> successful bidder will enter into a contract with the Internet
> Society.
> 
> The primary goal of this project is to develop consensus on a
> set of requirements for IETF Remote Participation Services
> (RPS) to enhance remote participation at IETF meetings,
> interim and virtual working group meetings.
> 
> Background
> The IETF has supported remote meeting participation over the
> Internet for many years. For example, the audio of  each
> session is made available in real time so that remote
> participants can listen to the proceedings. Instant messaging
> is supported by having a jabber room 'conference' for each
> session, so that co

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Frank Ellermann]

On 20 October 2011 10:27, John C Klensin wrote:

[...}

+1

Two "it's only me" observations:  What some mobile
broadband providers euphemistically sell as "ISDN"-
speed in Germany and what Microsoft claims to be a
"media player" is a major PIT* with whatever the
IETF considers as "audio streaming".

If there are good jabber scribes not assuming that
"audio" remotely works or is related to their side
of "real time" remote jabber participation can be
fun.  Even if jabber doesn't work very well there
are often at least interesting jabber logs.

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

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[John C Klensin]

--On Thursday, October 20, 2011 11:49 +0200 Frank Ellermann
 wrote:

> +1
> 
> Two "it's only me" observations:  What some mobile
> broadband providers euphemistically sell as "ISDN"-
> speed in Germany and what Microsoft claims to be a
> "media player" is a major PIT* with whatever the
> IETF considers as "audio streaming".
> 
> If there are good jabber scribes not assuming that
> "audio" remotely works or is related to their side
> of "real time" remote jabber participation can be
> fun.  Even if jabber doesn't work very well there
> are often at least interesting jabber logs.

And the time-lag differences among the IETF audio stream, other
audio arrangements (WebEx, Skype, etc.), and the jabber activity
can be seriously crazy-making.  I didn't intend my examples to
be comprehensive, only to illustrate that it is important to
talk with users.   Thanks, Frank, for adding to the list.

   john


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

secdir review of draft-ietf-vcarddav-kind-app-00.txt

[Stephen Hanna]

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines a new value for the vCard kind property:
application. This value is to be used for vCards that represent
software applications.

The Security Considerations section of this document states:

   Use of vCards to represent software applications is not envisioned to
   introduce security considerations beyond those specified for vCards
   in general as described in [VCARD].

However, the Security Considerations section of [VCARD] doesn't
seem adequate to the task. It merely points out that vCards don't
have any security protections and therefore SHOULD be transported
over a secure mechanism such as S/MIME or PGP if security is a
concern. This advice may be adequate if the vCard is only used
to transmit contact information for a person but it's generally
not adequate when the vCard contains information about a software
application. For example, this draft suggests that the KEY property
can be used to convey a public key associated with an application.
What a weak way to convey a public key! Will the recipient be able
to determine whether the key is accurate? How might the key be
revoked if necessary? No provisions are made for this. Other vCard
properties such as URL may cause problems if malicious.

Without proper security protections, the application vCard kind
seems like a great tool for phishing and social engineering.
Attackers can forge an email apparently from a trusted party,
including an application vCard and instructions to click on it
to see something cool. A naive email client may easily decide
that clicking on an application vCard should run the application
referenced in the vCard or visit the URL in the vCard or whatever.

I suggest that the Security Considerations section of the draft
be updated to include specific warnings that the contents of an
application vCard should be considered untrustworthy and dangerous
unless they have been securely delivered from a trustworthy source.
Even then, there's a real possibility that the source may have
been compromised before the vCard was sent. So information
obtained from vCards should not be regarded as ipso facto
trustworthy. Software should not act on information contained
in a vCard unless there's a strong reason to believe it's
accurate. And the KEY property SHOULD NOT be used for an
application. Instead, more robust techniques for managing
software public keys should be used.

Thanks,

Steve

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

RE: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[George, Wes]

I'm also completely mystified as to why IPv6 support for all proposed/requested 
features is not an explicitly stated requirement, even at this phase. It's not 
always as simple as "we'll make sure we make it IPv6 capable when we implement 
it..." with the sorts of solutions you're looking for here. Knowing that we 
require this at this phase would allow for some vendor self-selection or proper 
time to fix the gaps prior to formal proposals, so that we don't end up with 
lip service around IPv6 support.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART review of draft-ietf-eai-rfc5335bis-12

[Russ Housley]

Miguel:

I interpret this text to mean that the old limit was 998 octets and that the 
new limit is 988 octets.

Russ


On Oct 18, 2011, at 4:50 PM, Miguel A. Garcia wrote:

> Nits/editorial comments:
> 
> - Section 3.4 reads:
> 
>   Section 2.1.1 of [RFC5322] limits lines to 998 characters and
>   recommends that the lines be restricted to only 78 characters.  This
>   specification changes the former limit to 988 octets.
>  bbb^^^
> 
> I wonder if there is an error in the third line and the text should say "... 
> limit to 998 octets" rather than "988". Otherwise, I can't explain the 988 
> figure.
> 

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

IPv6 support in hotel contract?

[George, Wes]

My last message caused something else to occur to me - there has been a lot of 
discussion both here and at NANOG about hotels being woefully underprepared for 
the internet (and address) use that their guests generate when a conference 
full of geeks and their multiple devices per person descend upon them. 
Sometimes the IETF is successful at convincing the hotel to let them take over 
the internet service in the guest rooms, sometimes not.

Perhaps we can kill two birds with one stone by starting to require IPv6 
service in the guest rooms when we enter into negotiations with hotels. If they 
don't have it, we'll be happy to temporarily take over the internet service, or 
assist them in getting it enabled permanently in their existing network, and if 
neither of those options are acceptable, it provides negotiating leverage on 
other things. This also has the net effect of starting to make it clear to 
hotel management that IPv6 is going to start being mandatory for some subset of 
their guests before too much longer.

I realize that having something in the contract doesn't mean that we're any 
more likely to get it. But the fact that it's in the contract makes a statement 
in and of itself. IAOC, any reason why this couldn't be added, especially given 
how far in advance you're negotiating with venues?

Thanks,

Wes George



This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: IPv6 support in hotel contract?

[TJ]

+1 ... Whether it works or not, it's atleast worth the effort!

/TJ
On Oct 20, 2011 8:07 AM, "George, Wes"  wrote:

>  My last message caused something else to occur to me – there has been a
> lot of discussion both here and at NANOG about hotels being woefully
> underprepared for the internet (and address) use that their guests generate
> when a conference full of geeks and their multiple devices per person
> descend upon them. Sometimes the IETF is successful at convincing the hotel
> to let them take over the internet service in the guest rooms, sometimes
> not.
>
> ** **
>
> Perhaps we can kill two birds with one stone by starting to require IPv6
> service in the guest rooms when we enter into negotiations with hotels. If
> they don’t have it, we’ll be happy to temporarily take over the internet
> service, or assist them in getting it enabled permanently in their existing
> network, and if neither of those options are acceptable, it provides
> negotiating leverage on other things. This also has the net effect of
> starting to make it clear to hotel management that IPv6 is going to start
> being mandatory for some subset of their guests before too much longer. **
> **
>
> ** **
>
> I realize that having something in the contract doesn’t mean that we’re any
> more likely to get it. But the fact that it’s in the contract makes a
> statement in and of itself. IAOC, any reason why this couldn’t be added,
> especially given how far in advance you’re negotiating with venues?
>
> ** **
>
> Thanks,
>
> ** **
>
> Wes George
>
> ** **
>
> --
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and any copy of this
> E-mail and any printout.
>
> ___
> 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: Gen-ART review of draft-ietf-eai-rfc5335bis-12

[Pete Resnick]

Your initial suspicion was correct: It is a typo.

Impressive how many folks can miss something so simple.

I'll put it in a note to the RFC Editor.

pr

On 10/20/11 5:48 AM, Miguel A. Garcia wrote:
Yes, I interpret the same. But having found no motivation for the 
reduction of 10 octets, I just wanted to verify that there is no typo 
in the figure.


A bit of motivation for the "988" would help too.

/Miguel

On 20/10/2011 14:42, Russ Housley wrote:

Miguel:

I interpret this text to mean that the old limit was 998 octets and 
that the new limit is 988 octets.


Russ


On Oct 18, 2011, at 4:50 PM, Miguel A. Garcia wrote:


Nits/editorial comments:

- Section 3.4 reads:

   Section 2.1.1 of [RFC5322] limits lines to 998 characters and
   recommends that the lines be restricted to only 78 characters.  This
   specification changes the former limit to 988 octets.
  bbb^^^

I wonder if there is an error in the third line and the text should 
say "... limit to 998 octets" rather than "988". Otherwise, I can't 
explain the 988 figure.








--
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

Re: Anotherj RFP without IETF community input

[Simon Perreault]

On 2011-10-20 08:41, George, Wes wrote:
> I'm also completely mystified as to why IPv6 support for all
> proposed/requested features is not an explicitly stated requirement,
> even at this phase.

And more generally, this should be considered an opportunity for
dogfooding the protocols we create. IPv6 is one of them. SIP, RTP, the
XCON stuff, and XMPP could be others.

It would be very sad if we end up with the usual everything-over-HTTP
Flash applet stuff.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Anotherj RFP without IETF community input

[Joel jaeggli]

On 10/20/11 02:49 , Frank Ellermann wrote:
> On 20 October 2011 10:27, John C Klensin wrote:
> 
> [...}
> 
> +1
> 
> Two "it's only me" observations:  What some mobile
> broadband providers euphemistically sell as "ISDN"-
> speed in Germany and what Microsoft claims to be a
> "media player" is a major PIT* with whatever the
> IETF considers as "audio streaming".

icecast http/mp3 streaming is as commonly supported as anything I could
find. on balance the majority of internet radio runs over it and there
are both generic as well as specialized clients for virtually every
modern platform.

> If there are good jabber scribes not assuming that
> "audio" remotely works or is related to their side
> of "real time" remote jabber participation can be
> fun.  Even if jabber doesn't work very well there
> are often at least interesting jabber logs.
> 
> -Frank
> ___
> 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: Anotherj RFP without IETF community input

[Dave Cridland]

On Thu Oct 20 14:33:43 2011, Simon Perreault wrote:

On 2011-10-20 08:41, George, Wes wrote:
> I'm also completely mystified as to why IPv6 support for all
> proposed/requested features is not an explicitly stated  
requirement,

> even at this phase.

And more generally, this should be considered an opportunity for
dogfooding the protocols we create. IPv6 is one of them. SIP, RTP,  
the

XCON stuff, and XMPP could be others.


Right - the current system is XEP-0045 (an XSF thing) over XMPP (an  
IETF thing), supplemented by MP3 over HTTP for audio. The chatrooms I  
find fine - if anyone has suggestions for what else those need to do  
I'd appreciate knowing (as would the rest of the participants in the  
standards group at the XSF).


Having audio fed over RTP would be an obvious first step, and that  
could be negotiable by both XMPP and SIP clients.


As a remote participant for the vast majority of IETFs I've (not?)  
attended, I'd humbly suggest that the most useful things a remote  
participant can have are reasonably synchronized audio (instead of  
several seconds delay, which makes timely responses difficult) and  
ensuring that the chatrooms are visible in the physical room (thus  
making all in-room participants aware of the chatroom's remote  
participants and what their input is). A second projector and screen  
in the room is embarrassingly low-tech, but very effective.


I can see the utility of having some kind of screencast thing for the  
slides, although as a rule, I hate slides, so this comes a distant  
third. Being able to downlaod them and sing along at home is just  
fine.


I don't particularly care if my actual voice isn't heard in the room.  
I understand that many will miss my dulcet tones, of course, but the  
thing I really want to be able to do, as a remote participant, is  
participate.


Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART review of draft-ietf-eai-rfc5335bis-12

[Pete Resnick]

On 10/20/11 6:59 AM, Miguel A. Garcia wrote:

But even if it is a typo, the text makes no sense. It says:

   Section 2.1.1 of [RFC5322] limits lines to 998 characters and
   recommends that the lines be restricted to only 78 characters.  This
   specification changes the former limit to 988 octets.

So, if the limit is still 998, then there is no change with respect 
the former limit.


See the next sentence:

   (Note that in
   ASCII octets and characters are effectively the same but this is not
   true in UTF-8.)

Remember, in UTF-8, characters can be multiple octets. So 998 UTF-8 
encoded *characters* are likely to be many more than 998 octets long. So 
the change is to say that the limit is in octets, not in characters.


pr

--
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

R: [mpls] R: Re: 答复: 回复： R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[D'Alessandro Alessandro Gerardo]

John,
I often appreciate Erminio's comments on this mailing list but I had not till 
now the pleasure to meet him because he does not attend the IETF meetings.

At my knowledge, I'm the only "Alessandro" that has been following  MPLS-TP 
standardization process and apparently it seems to me you want to associate 
Erminio's comments to me (in your email below).

I regret to tell you that I follow standards on behalf of TI and exclusively 
for the interest of my Company. I have therefore no need to use an informal 
email account (and I'll never do it).

Best regards,
Alessandro
--
Telecom Italia
Alessandro D'Alessandro
Transport Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07


-Messaggio originale-
Da: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] Per conto di John E 
Drake
Inviato: mercoledì 19 ottobre 2011 23:55
A: erminio.ottone...@libero.it; brian.e.carpen...@gmail.com; 
yang.jia...@zte.com.cn
Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org
Oggetto: RE: [mpls] R: Re: 答复: 回复： R: FW: Last Call: 
 (The Reasons for Selecting a 
Single Solution for MPLS-TP OAM) to Informational RFC

Alessandro,

Apparently, the advice given regarding the risks and costs associated with 
deploying proprietary or pre-standard solutions didn't resonate with you.  Do 
you really expect the rest of us to clean up after you?

Thanks,

John

> -Original Message-
> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf
> Of erminio.ottone...@libero.it
> Sent: Wednesday, October 19, 2011 1:49 PM
> To: brian.e.carpen...@gmail.com; yang.jia...@zte.com.cn
> Cc: m...@ietf.org; mpls-bounces@ietf.orgLarry; ietf@ietf.org
> Subject: [mpls] R: Re: 答复: 回复： R: FW: Last Call:  mpls-tp-oam-considerations-01.txt> (The Reasons for Selecting a Single
> Solution for MPLS-TP OAM) to Informational RFC
>
> If the MPLS WG had selected the OAM solution that was already existing
> (as indicated multiple times by the operators which have already
> massively deployed it), we would have had a single OAM solution both
> in the market and in the IETF RFCs.
>
> We now have "two" OAM solutions: one (which is not actually really
> singular)
> documented by IETF RFCs and one widely implemented and deployed. This
> draft is not resolving this issue at all.
>
> >Messaggio originale
> >Da: brian.e.carpen...@gmail.com
> >Data: 5-ott-2011 22.16
> >A: 
> >Cc: "m...@ietf.org", "ietf@ietf.org",
>  bounces@ietf.orgLarry>
> >Ogg: Re: [mpls] 答复:  回复：  R: FW: Last Call:  mpls-tp-oam-
> considerations-01.txt> (The Reasons for Selecting a Single Solution
> for MPLS- TP OAM) to Informational RFC
> >
> >Hi Jian,
> >
> >On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote:
> >> Dear All,
> >>
> >> I do not support either.
> >>
> >> In section 3.5:
> >> If two MPLS OAM protocols were to be deployed we would have to
> consider
> >> three possible scenarios:
> >> 1) Isolation of the network into two incompatible and unconnected
> islands.
> >>
> >> Two OAM solutions have been discussed for a long time in both ITU-T
> and
> >> IETF.
> >> Each solution has their own supporters inculding carriers and
> vendors.
> >> So I don't think there is any interworking issue between two OAM
> solutions.
> >> Carrier will select one OAM solution, A or B, in their network.
> >> No need to select A and B at one network at the same time.
> >
> >There are two large costs that you are ignoring:
> >
> >a) all vendors wishing to bid for business from A and B will have to
> >   implement and support both solutions.
> >
> >b) when A buys B or B buys A, the incompatible networks will have to
> >   be merged.
> >
> >These are costs that run to hundreds of millions of USD, EUR or CNY.
> >They are costs caused directly by SDOs creating rival solutions.
> >
> >I think it would be irresponsible of the IETF not to document this
> >situation. As engineers, we have an ethical responsibility here.
> >
> >Brian
> >___
> >mpls mailing list
> >m...@ietf.org
> >https://www.ietf.org/mailman/listinfo/mpls
> >
>
>
> ___
> mpls mailing list
> m...@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Di

R: [mpls] FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[erminio.ottone...@libero.it]

I do not support the publication of this draft.

As indicated by many technical comments already raised on this topic, what the 
MPLS WG has defined is not a single solution but encopasses a variety of 
incompatible options none of which meet the requirements of major transport 
operators. The draft is therefore technically incorrect unless the concept of 
"single soution" is defined as anything but what meets the requirements of 
major transport operators.

Looking at the precedents provided in the draft, I can see at least a couple 
which were a great market success (e.g., OSPF/IS-IS and SONET/SDH). I wonder 
whether the real motivaiton for the selection of a "single solution" as defined 
above is to manipulate the market to avoid MPLS-TP being as successfull as 
these precedents.

In order to make comments according to the "IETF tradition", my text change 
proposal is very simple: replace the whole document with the text provided by 
draft-fang-mpls-tp-oam-considerations. draft-fang-mpls-tp-oam-considerations 
provides considerations from operators that have field experience with large 
scale deployments of MPLS-TP which are more relevant that incorrect 
phylosophical considerations.

>Messaggio originale
>Da: adr...@olddog.co.uk
>Data: 26-set-2011 23.57
>A: 
>Ogg: [mpls] FW: Last Call: 
> (TheReasons for Selecting a Single Solution for MPLS-TP OAM) to 
Informational RFC
>
>MPLS Working Group,
>
>Please be aware of the IETF last call as shown below. The document was 
presented
>for publication as an individual RFC with IETF consensus and AD sponsorship.
>
>This draft is clearly close and relevant to the work you do, but after
>discussing with the chairs I came to the conclusion that it does not comment 
on
>the technical or process decisions of the MPLS working groups, and it does 
not
>attempt to make any technical evaluations or definitions within the scope of 
the
>MPLS working group. It is more of a philosophical analysis of the way the 
IETF
>approaches the "two solutions" problem with special reference to MPLS-TP 
OAM.
>
>Thus, I am accepting the document as AD Sponsored rather than running it 
through
>the MPLS working group. My reasoning is that the working group has got plenty 
to
>do working on technical issues without being diverted into wider IETF
>philosophy.
>
>As an AD Sponsored I-D it is subject to a four week IETF last call. That is
>plenty of opportunity for everyone to comment and express their views. 
Please
>send your comments to the IETF mailing list as described below, or (in
>exceptional circumstances) direct to the IESG.
>
>Thanks,
>Adrian
>
>> -Original Message-
>> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-
>> boun...@ietf.org] On Behalf Of The IESG
>> Sent: 26 September 2011 20:43
>> To: IETF-Announce 
>> Subject: Last Call:  
(The
>> Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational 
RFC
>> 
>> 
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'The Reasons for Selecting a Single Solution for MPLS-TP OAM'
>>as an Informational
>> RFC
>> 
>> 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-10-24. 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
>> 
>>The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
>>for use in transport network deployments. That is, MPLS-TP is a set
>>of functions and features selected from the wider MPLS toolset and
>>applied in a consistent way to meet the needs and requirements of
>>operators of packet transport networks.
>> 
>>During the process of development of the profile, additions to the
>>MPLS toolset have been made to ensure that the tools available met
>>the requirements. These additions were motivated by MPLS-TP, but form
>>part of the wider MPLS toolset such that any of them could be used in
>>any MPLS deployment.
>> 
>>One major set of additions provides enhanced support for Operations,
>>Administration, and Maintenance (OAM). This enables fault management
>>and performance monitoring to the level needed in a transport
>>network. Many solutions and protocol extensions have been proposed to
>>address these OAM requirements, and this document sets out the
>>reasons for selecting a single, coherent set of solutions for
>>standardization.
>> 
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
>> 
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-sprecher-mpls-tp-oam-considerations/
>> 
>> 
>> No IPR declarations have been submitted direc

R: Re: [mpls] 答复: 回复： R: FW: Last Call: (The Reasons for Selecting a Single Solution for MPLS-TP OAM) to Informational RFC

[erminio.ottone...@libero.it]

If the MPLS WG had selected the OAM solution that was already existing (as 
indicated multiple times by the operators which have already massively deployed 
it), we would have had a single OAM solution both in the market and in the IETF 
RFCs.

We now have "two" OAM solutions: one (which is not actually really singular) 
documented by IETF RFCs and one widely implemented and deployed. This draft is 
not resolving this issue at all.

>Messaggio originale
>Da: brian.e.carpen...@gmail.com
>Data: 5-ott-2011 22.16
>A: 
>Cc: "m...@ietf.org", "ietf@ietf.org", 
>Ogg: Re: [mpls] 答复:  回复：  R: FW: Last Call:  (The Reasons for Selecting a Single Solution for MPLS-
TP OAM) to Informational RFC
>
>Hi Jian,
>
>On 2011-10-06 03:53, yang.jia...@zte.com.cn wrote:
>> Dear All,
>> 
>> I do not support either.
>> 
>> In section 3.5:
>> If two MPLS OAM protocols were to be deployed we would have to consider
>> three possible scenarios:
>> 1) Isolation of the network into two incompatible and unconnected islands.
>> 
>> Two OAM solutions have been discussed for a long time in both ITU-T and
>> IETF.
>> Each solution has their own supporters inculding carriers and vendors.
>> So I don't think there is any interworking issue between two OAM 
solutions.
>> Carrier will select one OAM solution, A or B, in their network.
>> No need to select A and B at one network at the same time.
>
>There are two large costs that you are ignoring:
>
>a) all vendors wishing to bid for business from A and B will have to
>   implement and support both solutions.
>
>b) when A buys B or B buys A, the incompatible networks will have to
>   be merged.
>
>These are costs that run to hundreds of millions of USD, EUR or CNY.
>They are costs caused directly by SDOs creating rival solutions.
>
>I think it would be irresponsible of the IETF not to document this
>situation. As engineers, we have an ethical responsibility here.
>
>Brian
>___
>mpls mailing list
>m...@ietf.org
>https://www.ietf.org/mailman/listinfo/mpls
>


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

R: Re: [mpls] unresolved technical concerns

[erminio.ottone...@libero.it]

What about going into the mailing list and LS logs and read the comments 
provided by several service providers before asking for them being repeated 
again in a I-D that will fate share with the past comments (i.e., ignored)?

The comments have been already made. It is now the duty of the party which has 
so far ignored them to provide an answer.

It is also so easy to keep ingnoring drafts and technical comments and request 
people to continue to produce drafts

>Messaggio originale
>Da: jdr...@juniper.net
>Data: 5-ott-2011 23.20
>A: "Luyuan Fang (lufang)", "Alexander Vainshtein", "D'Alessandro Alessandro Gerardo", "Stewart Bryant (stbryant)"
>Cc: "m...@ietf.org", "ietf@ietf.org"
>Ogg: Re: [mpls] unresolved technical concerns
>
>That's because it is *so* much easier to just keep mumbling 'major unresolved 
technical concerns'.  I expect it is something learned in Yoga class. 
>
>> -Original Message-
>> From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of
>> Luyuan Fang (lufang)
>> Sent: Wednesday, October 05, 2011 5:11 PM
>> To: Alexander Vainshtein; D'Alessandro Alessandro Gerardo; Stewart
>> Bryant (stbryant)
>> Cc: m...@ietf.org; ietf@ietf.org
>> Subject: Re: [mpls] unresolved technical concerns
>> 
>> Yep. We are going in circles again.
>> We need to see technical details on the issues documented in an I-D as
>> Stewart suggested.
>> Don't remember seeing such document either.
>> 
>> Luyuan
>> 
>> 
>> > -Original Message-
>> > From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf
>> Of
>> > Alexander Vainshtein
>> > Sent: Wednesday, October 05, 2011 4:18 PM
>> > To: D'Alessandro Alessandro Gerardo; Stewart Bryant (stbryant)
>> > Cc: ietf@ietf.org; m...@ietf.org
>> > Subject: Re: [mpls] unresolved technical concerns
>> >
>> >
>> > Dear Alessandro,
>> > Lots  of thanks for a prompt response.
>> >
>> > Unfortunately your response does not really help (at least, me) to
>> > identify even a single
>> > specific technical issue. You may attribute it to my faulty memory,
>> > but I could not remember any. Presenting these cocerns in the form
>> > of an I-D as suggested by Stewart would  be the right first step.
>> >
>> >
>> > My 2c
>> > Sasha
>> >
>> > 
>> > From: D'Alessandro Alessandro Gerardo
>> > [alessandro.dalessan...@telecomitalia.it]
>> > Sent: Wednesday, October 05, 2011 6:54 PM
>> > To: stbry...@cisco.com; Alexander Vainshtein
>> > Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org
>> > Subject: unresolved technical concerns
>> >
>> > Dear Stewart, Dear Sasha,
>> > I think there are already enough contributions in that direction I
>> > (with many other experts) contributed to in the form of IETF mailing
>> > list discussion and ITU-T liaisons. Unfortunately I regret to say
>> that
>> > some questions for clarification and concerns risen in those emails
>> > (for sure some of mine) still remain without an answer. At the same
>> > time, some comments provided by ITU-T liaisons still remain
>> unresolved.
>> >
>> > Best regards,
>> > Alessandro
>> >
>> > --
>> > Telecom Italia
>> > Alessandro D'Alessandro
>> > Transport Innovation
>> > Via Reiss Romoli, 274 - 10148 Torino
>> > phone:  +39 011 228 5887
>> > mobile: +39 335 766 9607
>> > fax: +39 06 418 639 07
>> >
>> >
>> > -Messaggio originale-
>> > Da: Stewart Bryant [mailto:stbry...@cisco.com]
>> > Inviato: mercoledì 5 ottobre 2011 12:24
>> > A: D'Alessandro Alessandro Gerardo
>> > Cc: adr...@olddog.co.uk; m...@ietf.org; ietf@ietf.org
>> > Oggetto: Re: [mpls] R: FW: Last Call: > > considerations-01.txt> (The Reasons for Selecting a Single Solution
>> for
>> > MPLS-TP OAM) to Informational RFC
>> >
>> > On 05/10/2011 10:38, D'Alessandro Alessandro Gerardo wrote:
>> >  > major unresolved technical concerns
>> >
>> > Alessandro
>> >
>> > Please can I suggest that you write an internet draft detailing these
>> > "major unresolved technical concerns" so that we can all understand
>> > them.
>> >
>> > Such a draft needs to be technical, and describe the actions that the
>> > network operator is unable to perform, or the fault cases that they
>> are
>> > unable to diagnose using the OAM defined in the IETF RFCs, or late
>> > stage WG drafts.
>> >
>> > Alternatively if you are referring to a bug in the MPLS-TP OAM
>> > protocols, you need to tell the community what it is.
>> >
>> > I believe that this request has been made  a number of times, in
>> > various forums, and, as far as I know, no document has yet been
>> > produced.
>> >
>> > An argument of the form "you must standardize what I want"
>> > will not fly. What is needed is a very clear technical definition of
>> > the issue(s).
>> >
>> > When we have the "major unresolved technical concerns"
>> > on the table, we will be in a position to determine the best
>> > disposition of those issues.
>> >
>> > Stewart
>> >
>> >
>> >
>> >

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[SM]

At 01:27 20-10-2011, John C Klensin wrote:

Two omissions from this document illustrates why community input
is important:

(1) I don't know how much experience IAOC members have with
trying to participate remotely, but, having done so, there are


I'll rephrase that as "I don't know how much experience IAOC members 
have with trying to participate in a working group remotely".  I hope 
that is clear in case an IAOC member would like to comment.



insights into what is needed that one just cannot obtain by
physically attending a meeting and observing how things work.
If any RFP or subsequent contract does not provide for input
from, and probably interviews of, selected people who have tried
to participate remotely while carrying out various roles, then
the odds are high that the resulting work will not be adequate
in practice.  Instead, this RFP appears to provide only for
"observ[ing] group and plenary sessions" and then review of the
initial specifications by groups that are unlikely to include
the full range of remote participants.


If the experience is based on usage of Meetecho, Adobe, Citrix and 
Webex, it does not cover my use case.  These services may be good 
enough for some use cases but they have enough failure modes to make 
remote participation difficult.  The RFP mentions bidirectional audio 
and video.  As John has attempted to chair a working group remotely, 
he might be aware that real-time can mean more than 10 seconds 
between the time an event occurs and when it is registered at the remote end.



In addition, while I don't believe members of the community
should be required to read and study IAOC minutes to find out
that particular RFPs are under development so that they can
comment, I note that no IAOC minutes have been posted since
those for an IAOC meeting held on 27 July during IETF 81.


I noticed that too.


I recommend that the RFP be withdrawn until modifications such
as those suggested above can be discussed by the IAOC and
further input on draft RFP provisions sought from the community.
I also recommend that no further RFPs be issued until the
relevant IAOC discussions and decisions be properly recorded in
IAOC minutes and those minutes posted.


I doubt that's going to happen.

I would be grateful if Meetecho, Adobe, Citrix and Webex could be 
kept as experimental instead of being standardized.  XMPP works 
fine.  The current audio feed may not be sexy but it actually works 
in less than ideal environments.  BTW, the audio feed for the plenary 
sessions could be published on the agenda web page as it is usually a 
hassle to find.


Regards,
-sm 


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

Re: Gen-ART review of draft-ietf-eai-rfc5335bis-12

[Miguel A. Garcia]

Yes, I interpret the same. But having found no motivation for the 
reduction of 10 octets, I just wanted to verify that there is no typo in 
the figure.


A bit of motivation for the "988" would help too.

/Miguel

On 20/10/2011 14:42, Russ Housley wrote:

Miguel:

I interpret this text to mean that the old limit was 998 octets and that the 
new limit is 988 octets.

Russ


On Oct 18, 2011, at 4:50 PM, Miguel A. Garcia wrote:


Nits/editorial comments:

- Section 3.4 reads:

   Section 2.1.1 of [RFC5322] limits lines to 998 characters and
   recommends that the lines be restricted to only 78 characters.  This
   specification changes the former limit to 988 octets.
  bbb^^^

I wonder if there is an error in the third line and the text should say "... limit to 998 
octets" rather than "988". Otherwise, I can't explain the 988 figure.





--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART review of draft-ietf-eai-rfc5335bis-12

[Miguel A. Garcia]

But even if it is a typo, the text makes no sense. It says:

   Section 2.1.1 of [RFC5322] limits lines to 998 characters and
   recommends that the lines be restricted to only 78 characters.  This
   specification changes the former limit to 988 octets.

So, if the limit is still 998, then there is no change with respect the 
former limit.


/Miguel

On 20/10/2011 15:19, Pete Resnick wrote:

Your initial suspicion was correct: It is a typo.

Impressive how many folks can miss something so simple.

I'll put it in a note to the RFC Editor.

pr

On 10/20/11 5:48 AM, Miguel A. Garcia wrote:

Yes, I interpret the same. But having found no motivation for the
reduction of 10 octets, I just wanted to verify that there is no typo
in the figure.

A bit of motivation for the "988" would help too.

/Miguel

On 20/10/2011 14:42, Russ Housley wrote:

Miguel:

I interpret this text to mean that the old limit was 998 octets and
that the new limit is 988 octets.

Russ


On Oct 18, 2011, at 4:50 PM, Miguel A. Garcia wrote:


Nits/editorial comments:

- Section 3.4 reads:

Section 2.1.1 of [RFC5322] limits lines to 998 characters and
recommends that the lines be restricted to only 78 characters.  This
specification changes the former limit to 988 octets.
   bbb^^^

I wonder if there is an error in the third line and the text should
say "... limit to 998 octets" rather than "988". Otherwise, I can't
explain the 988 figure.









--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Gen-ART review for draft-irtf-hiprg-dht-04

[kathleen.moriarty]

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-irtf-hiprg-dht-04
Reviewer: Kathleen Moriarty
Review Date: October 20, 2011
IETF LC End Date: 11/1/11
IESG Telechat date: (if known)

Summary: This draft requires further review.  There are just a few grammar nits 
listed below, but the use of SHA-1 should be updated or noted as a concern.

This is an experimental draft, building off of other experimental RFCs.  The 
IESG outlined a number of concerns at the start of RFC5201, at least one of 
which is also present in this document.  SHA-1 is no longer a preferred 
algorithm and there is no algorithm agility in the specification (it appears to 
be a field size limitation from previous RFCs, but there is no explanation).  
This is not listed in the security considerations either.  If the IESG is still 
okay with experimental documents proceeding with SHA-1 specified, this should 
be discussed in the security considerations section at a minimum. It seems that 
the service described could use another hash algorithm since the exchanges are 
fully defined in this document.

If the algorithm cannot be updated, the description of the design in the 
abstract should be updated as HIP is not designed with the security features 
described in the following sentences.
"The protocol is
   designed to be resistant to denial-of-service (DoS) and man-in-the-
   middle (MitM) attacks.  When used together with another suitable
   security protocol, such as the Encapsulated Security Payload (ESP),
   it provides integrity protection and optional encryption for upper-
   layer protocols, such as TCP and UDP."

This could be a result of RFC5201 having a MUST statement for the use of SHA-1. 
 The earlier document, RFC4423 specifies a hash is to be used and at the time 
it was written, SHA-1 was the NIST recommendation (2003).

Major issues:

Minor issues:

Nits/editorial comments:
Abstract: Change: This document specifies a common interface for using HIP with 
a
To: "This document specifies a common interface for using Host Identity 
Protocol (HIP) with a"
The Introduction uses the spelled out acronym without putting (HIP) after it if 
you want to define it here as well.

Introduction: 3rd sentence, add a comma:
Change from: "These keys are hashed and prefixed
   to form Host Identity Tags (HITs) which appear as large random
   numbers."
To: "These keys are hashed and prefixed
   to form Host Identity Tags (HITs), which appear as large random
   numbers."

Section 2: Is there a reason why the hash value is limited to using SHA-1?  
This should be a choice for algorithm agility if possible.

Section3, paragraph 6: Consider breaking this into two sentences:
"The host SHOULD
   retain the last Update ID value it used for each HIT across reboots,
   or perform a self lookup in the DHT, since that number may be
   retained in the DHT records and will determine the preferred address
   used by peers."

Section 4, paragraph 4: Consider changing the following sentence (joining two 
thoughts not three) and 'address publish' does not read quite right:
From: "The ttl_sec field used with address publish includes the time-to-
   live, the number of seconds for which the entry will be stored by the
   DHT, which SHOULD be set to the number of seconds remaining in the
   address lifetime."
To: "The ttl_sec field used with the address publish command includes the 
time-to-
   Live and the number of seconds for which the entry will be stored by the
   DHT, which SHOULD be set to the number of seconds remaining in the
   address lifetime."

Section 7: Security Considerations
If there is some reason why you can't use anything stronger than SHA-1 for a 
hash, this should also be listed as a security consideration.  I don't think 
the IETF is putting through documents that use SHA-1 anymore as standards track.


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

Gen-ART Telechat Review of draft-ietf-dnsext-rfc2672bis-dname-24

[Ben Campbell]

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

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-dnsext-rfc2672bis-dname-24
Reviewer: Ben Campbell
Review Date: 2011-10-20
IESG Telechat date: 2011-10-20

[Apologies for the late review--I had some unexpected travel, and let this one 
fall through the cracks.]

Summary: This draft is very close to ready for publication as proposed 
standard. My substantive comments from version 22 have all been addressed. 
There are still a couple of remaining nits.

Major issues:

None. [The missing sections I commented on in my previous review have been 
added back in as sections 3.4.2 and 6, respectively.]

Minor issues:

None.

Nits/editorial comments:

-- idnits still has some comments, please check

-- Abstract: Still need to explicitly say the draft "obsoletes" 2672 and 
"updates" the other RFCs mentioned in the header.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Anotherj RFP without IETF community input

[Henk Uijterwaal]

John and others.

On 20/10/2011 10:27, John C Klensin wrote:

> I hate to keep bringing this up, 
[...]
> I recommend that the RFP be withdrawn until modifications such
> as those suggested above can be discussed by the IAOC and
> further input on draft RFP provisions sought from the community.

-1.

Or I disagree completely here and I do not see the need for the RFP to
be withdrawn.

The task is clear, it is to write an ID with the requirements.  The
ID process offers sufficient opportunities for the community to
provide input, it is a matter of finding somebody to hold the pen
and write the document.   I think we should move forward here and
start doing the work, not endlessly discuss the fine details of a
process.

Henk


-- 
--
Henk Uijterwaal   Email: henk(at)uijterwaal.nl
  http://www.uijterwaal.nl
  Phone: +31.6.55861746
--

There appears to have been a collective retreat from reality that day.
 (John Glanfield, on an engineering project)
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPv6 support in hotel contract?

[Worley, Dale R (Dale)]

> From: George, Wes [wesley.geo...@twcable.com]
> 
> Perhaps we can kill two birds with one stone by starting to require
> IPv6 service in the guest rooms when we enter into negotiations with
> hotels.

At least, we should start *trying* to get IPv6 service from hotels.
We may have a very hard time getting it, but the fact that customers
are starting to *ask* for it will help make hotels aware of IPv6.

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

RE: RFP for Remote Participation Services Specifications Development

[Worley, Dale R (Dale)]

> From: IETF Administrative Director [i...@ietf.org]
> Sent: Wednesday, October 19, 2011 12:25 PM
> 
> The IETF Administrative Oversight Committee (IAOC), on behalf of the
> IETF, announces this Request for Proposal to develop the
> specifications for Remote Participation Services. The successful
> bidder will enter into a contract with the Internet Society.
> [...]
> The RFP can be found at: .

Actually the RFP is at
http://iaoc.ietf.org/documents/RPS-Specifications-RFP-2011-10-19.pdf

Yes, it's a PDF file, not a standardized format!  Talk about not
eating our own dogfood!

> Proposals must be received via email at rpellet...@isoc.org no later
> than November 1, 2011, 5:00 P.M. EDT.

13 days for the vendors to become aware of the proposal and answer it?
That sounds unlikely to get optimal participation.  (Unless the IAOC
has already been working with prospective vendors.)

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

Re: Anotherj RFP without IETF community input

[Simon Pietro Romano]

Hi,

you might want to have a look at the Meetecho IETF sites (see, e.g., 
http://ietf81.conf.meetecho.com/), which contain session recordings and give 
you a flavour of what is currently available to remote participants. BTW, 
Meetecho is XCON, mediactrl, RTP and XMPP compliant. As far as I saw, most of 
the desiderata included in the RFP message might be satisfied with our 
platform, which, not by chance, has been conceived at the outset with an 
IETF-minded approach.

Simon

Dave Cridland  ha scritto:

On Thu Oct 20 14:33:43 2011, Simon Perreault wrote:
> On 2011-10-20 08:41, George, Wes wrote:
> > I'm also completely mystified as to why IPv6 support for all
> > proposed/requested features is not an explicitly stated 
> requirement,
> > even at this phase.
> 
> And more generally, this should be considered an opportunity for
> dogfooding the protocols we create. IPv6 is one of them. SIP, RTP, 
> the
> XCON stuff, and XMPP could be others.
> 
> 
Right - the current system is XEP-0045 (an XSF thing) over XMPP (an 
IETF thing), supplemented by MP3 over HTTP for audio. The chatrooms I 
find fine - if anyone has suggestions for what else those need to do 
I'd appreciate knowing (as would the rest of the participants in the 
standards group at the XSF).

Having audio fed over RTP would be an obvious first step, and that 
could be negotiable by both XMPP and SIP clients.

As a remote participant for the vast majority of IETFs I've (not?) 
attended, I'd humbly suggest that the most useful things a remote 
participant can have are reasonably synchronized audio (instead of 
several seconds delay, which makes timely responses difficult) and 
ensuring that the chatrooms are visible in the physical room (thus 
making all in-room participants aware of the chatroom's remote 
participants and what their input is). A second projector and screen 
in the room is embarrassingly low-tech, but very effective.

I can see the utility of having some kind of screencast thing for the 
slides, although as a rule, I hate slides, so this comes a distant 
third. Being able to downlaod them and sing along at home is just 
fine.

I don't particularly care if my actual voice isn't heard in the room. 
I understand that many will miss my dulcet tones, of course, but the 
thing I really want to be able to do, as a remote participant, is 
participate.

Dave.
-- 
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_

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: Anotherj RFP without IETF community input

[Simon Pietro Romano]

Hi,

you might want to have a look at the Meetecho IETF sites (see, e.g., 
http://ietf81.conf.meetecho.com/), which contain session recordings and give 
you a flavour of what is currently available to remote participants. BTW, 
Meetecho is XCON, mediactrl, RTP and XMPP compliant. As far as I saw, most of 
the desiderata included in the RFP message might be satisfied with our 
platform, which, not by chance, has been conceived at the outset with an 
IETF-minded approach.

Simon

Dave Cridland  ha scritto:

On Thu Oct 20 14:33:43 2011, Simon Perreault wrote:
> On 2011-10-20 08:41, George, Wes wrote:
> > I'm also completely mystified as to why IPv6 support for all
> > proposed/requested features is not an explicitly stated 
> requirement,
> > even at this phase.
> 
> And more generally, this should be considered an opportunity for
> dogfooding the protocols we create. IPv6 is one of them. SIP, RTP, 
> the
> XCON stuff, and XMPP could be others.
> 
> 
Right - the current system is XEP-0045 (an XSF thing) over XMPP (an 
IETF thing), supplemented by MP3 over HTTP for audio. The chatrooms I 
find fine - if anyone has suggestions for what else those need to do 
I'd appreciate knowing (as would the rest of the participants in the 
standards group at the XSF).

Having audio fed over RTP would be an obvious first step, and that 
could be negotiable by both XMPP and SIP clients.

As a remote participant for the vast majority of IETFs I've (not?) 
attended, I'd humbly suggest that the most useful things a remote 
participant can have are reasonably synchronized audio (instead of 
several seconds delay, which makes timely responses difficult) and 
ensuring that the chatrooms are visible in the physical room (thus 
making all in-room participants aware of the chatroom's remote 
participants and what their input is). A second projector and screen 
in the room is embarrassingly low-tech, but very effective.

I can see the utility of having some kind of screencast thing for the 
slides, although as a rule, I hate slides, so this comes a distant 
third. Being able to downlaod them and sing along at home is just 
fine.

I don't particularly care if my actual voice isn't heard in the room. 
I understand that many will miss my dulcet tones, of course, but the 
thing I really want to be able to do, as a remote participant, is 
participate.

Dave.
-- 
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_

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: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Randy Bush]

i read the message from ray as an rfp for someone to write the rfp for
remote services.  aside from being a very amusing bureaucratic layer
cake, this would not seem to need a lot of experience with remote
access, but rather good ears and a taste for the bureaucracy and discord
the ietf has become.

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

Re: Anotherj RFP without IETF community input

[SM]

At 08:15 20-10-2011, Henk Uijterwaal wrote:

-1.

Or I disagree completely here and I do not see the need for the RFP to
be withdrawn.


There could at least be a modicum of transparency.


The task is clear, it is to write an ID with the requirements.  The
ID process offers sufficient opportunities for the community to
provide input, it is a matter of finding somebody to hold the pen
and write the document.   I think we should move forward here and
start doing the work, not endlessly discuss the fine details of a
process.


Breaking stuff that works does not qualify as an endless discussion 
of the fine details of a process in my book.


The RFP will cost money.  In theory, such decision have to be 
documented, justified and there should be community review.  The IAOC 
did not publish any details about Valley View.


At 09:04 20-10-2011, Simon Pietro Romano wrote:
you might want to have a look at the Meetecho IETF sites (see, e.g., 
http://ietf81.conf.meetecho.com/), 
which contain session recordings and give you a flavour of what is 
currently available to remote participants. BTW, Meetecho is XCON, 
mediactrl, RTP and XMPP compliant. As far as I saw, most of the 
desiderata included in the RFP message might be satisfied with our 
platform, which, not by chance, has been conceived at the outset 
with an IETF-minded approach.


It's all nice to pick a solution that is based on protocols developed 
within the IETF.   In the wild, you can expect sign-up that doesn't 
work.  You'll find participants having to hunt down the audio stream 
as that information is not published.  The server is hosted in 
Italy.  If I recall correctly, there were some connectivity 
issues.  This is not about Meetecho not offering a good service.  I 
am aware that you responded to the questions to get things working.


draft-jaeggli-ietf-streaming-media-status-00 discussed about IETF 
streaming.  As Meetecho has been around since a few meetings, it 
would be helpful to have some documentation about the experience gained.


Regards,
-sm  


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

Re: Anotherj RFP without IETF community input

[John C Klensin]

--On Thursday, October 20, 2011 17:15 +0200 Henk Uijterwaal
 wrote:

>> I recommend that the RFP be withdrawn until modifications such
>> as those suggested above can be discussed by the IAOC and
>> further input on draft RFP provisions sought from the
>> community.
> 
> -1.
> 
> Or I disagree completely here and I do not see the need for
> the RFP to be withdrawn.
> 
> The task is clear, it is to write an ID with the requirements.
> The ID process offers sufficient opportunities for the
> community to provide input, it is a matter of finding somebody
> to hold the pen and write the document.   I think we should
> move forward here and start doing the work, not endlessly
> discuss the fine details of a process.

Henk,

Actually, unless the IAOC has already selected either a vendor
or a short list of vendors, that isn't the task.  The task is to
get proposals from a selection of vendors and then pick on.  In
that regard, the list of issues the proposing contractor is
supposed to consider ("the Environment") is very important
because some potential proposers might, at least in principle,
submit a proposal for some list of environments to be supported
but not feel they were competent to evaluate others.   If the
community introduces completely new issues or environments to be
considered once we go into the I-D process, a contractor might
be entirely justified to say either "not in the contract and I'm
not going to do it because I can't do it well" or "not in the
contract, it will cost you $XYZ extra for me to write
requirements for it, please send money".  Neither is a desirable
situation, to put it mildly.

With regard to transparency and openness to community input, I
suggest that exposing a draft RFP to community review
--something the community has asked for several times and which
the IAOC has generally agreed is reasonable and appropriate--
serves two separate purposes.  You can dismiss the second as
"fine details of a process", but it seems to me that the first
is quite substantive.

(1) The IETF Community often has perspectives on issues that are
broader from those represented on the IAOC.  Consequently,
community input may actually provide ideas that should be
discussed and evaluated as to whether they should be in the RFP
(remembering that a different set of tasks may yield different
bidders).  The few hours of discussion since I sent my note
illustrate the issues: whether you believe that consideration
for IPv6, poor-connectivity participant environments, more
specific consideration of input from those who have experienced
remote participation in various roles, or remote participation
in non-WG/non-BOF meetings is important, those issues should at
least be aired and discussed, openly, by the IAOC.  Perhaps
they, and whatever else might be identified, already have been
discussed and the IAOC has made decisions about them that the
community will find acceptable.  But, if they have, there is no
way to find out from any minutes that have been published, which
is why that isn't a "fine detail of process" either.

(2) The IAOC is required to be open and transparent with the
IETF community, including publishing timely minutes.  Maybe no
one cares any more or maybe the IAOC has concluded that the
expectation/ requirements are impossible.  But then another
provision of BCP 101 applies, which is that the IAOC, having
noticed that some procedures cannot be followed or requirements
met, is obligated to identify the problem to the community and
recommend changes to solve it.   I don't consider simply
ignoring those rules to be an option or even a fine detail of
process, but YMMD.

best,
   john




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

Re: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Bob Hinden]

John,

The RFP is not a solicitation to vendors of remote participation services.  It 
is to hire someone to write a requirements document for remote participation 
services.  It is not to develop any code nor are the items listed in the RFP 
the only things that should be included.  Note that it explicitly calls for 
having community input into the requirements.  The RFP includes:

  "After gathering all of this input, the contractor will prepare an
   initial specification for review by the IETF Tools Team and the
   vmeet mail list participants."

and

  "Specifications will be circulated as IETF Internet-Drafts (I-D)"

The intent of this work is to develop a set of requirements for community 
review.  I don't see any significant value in asking the community for input on 
an RFP that is for hiring someone to write a specification to generate 
community input.  

Also, while the SOW does not indicate it, because it is not something the 
contractor will do, the Internet-Draft will be "last called" to confirm that it 
represents community consensus.  This will be done by the General AD as has 
been done earlier with other specification tasks.

Regarding the IAOC minutes, the IAOC is aware that there is a problem.  I am 
sorry to report that the current volunteer approach to taking and producing 
IAOC minutes is not working.  I had hoped we could make the volunteer approach 
work.  The IAOC concluded on today's IAOC call that we should approach ISOC to 
get additional administrative support to improve this function.  I will report 
on the outcome of that in Taipei.

Regards,
Bob



On Oct 20, 2011, at 1:27 AM, John C Klensin wrote:

> Ray and IAOC,
> 
> I hate to keep bringing this up, but the discussions leading up
> to BCP 101 and the oft-replated principle of "maximum amount of
> transparency to the IETF community that can be reasonably
> obtained" strongly suggest that documents that are intended to
> evolve into RFPs be circulated in draft to the IETF community
> for comment.  If there is some reason why that it not possible,
> reasonable transparency suggests that the IAD or IAOC
> proactively provide an explanation to the community, rather than
> waiting to be asked.   
> 
> Community review of draft RFPs is particularly important
> because, for reasons outlined in BCP 101, there is little
> opportunity for effective community input once proposals are
> received and contract negotiations start.
> 
> Each time this issue has been raised in the past, the IAOC has
> agreed that exposing RFP drafts is The Right Thing to do, yet
> RFPs keep appearing without opportunity for community review.
> 
> Two omissions from this document illustrates why community input
> is important:
> 
> (1) I don't know how much experience IAOC members have with
> trying to participate remotely, but, having done so, there are
> insights into what is needed that one just cannot obtain by
> physically attending a meeting and observing how things work.
> If any RFP or subsequent contract does not provide for input
> from, and probably interviews of, selected people who have tried
> to participate remotely while carrying out various roles, then
> the odds are high that the resulting work will not be adequate
> in practice.  Instead, this RFP appears to provide only for
> "observ[ing] group and plenary sessions" and then review of the
> initial specifications by groups that are unlikely to include
> the full range of remote participants.  
> 
> It seems to me that a call for comments from those with actual
> remote participation experience and for contractor interviews
> with a selection of those people.   There is a long history of
> asking developers and tool-builders what users need.  The
> perceived success level in having a process that is limited to
> asking developers and tool-builders produce results that
> actually match user needs has been abysmal. 
> 
> (2) The list of "Environments" is also interesting.  Whether
> caused by health issues, travel limitations, or other
> considerations beyond the control of the individuals, we've had
> experience that has required remote participation of IAB and
> IESG members, members of key committees (the RSOC and RFC
> Editorial Board are on my mind at the moment, but, if the IAOC
> itself has not been affected yet, I believe that is only a
> matter of time).  At least parts of the meetings of those groups
> are, properly, not open.  While most of those meetings are
> scheduled far in advance, ad hoc sessions for which
> participation by members who happen to be remote do occur.
> Those bodies and meetings create remote participation
> requirements that are quite different from the environments
> listed -- small meeting support that goes well beyond "8 being
> simultaneous at any one time", a need for session privacy, and a
> need to accommodate meetings that are scheduled on relatively
> short notice.
> 
> I don't fault the IAD or IAOC for failure to identify those
> types of issues 

Re: IPv6 support in hotel contract?

[Joel jaeggli]

On 10/20/11 08:50 , Worley, Dale R (Dale) wrote:
>> From: George, Wes [wesley.geo...@twcable.com]
>>
>> Perhaps we can kill two birds with one stone by starting to require
>> IPv6 service in the guest rooms when we enter into negotiations with
>> hotels.
> 
> At least, we should start *trying* to get IPv6 service from hotels.
> We may have a very hard time getting it, but the fact that customers
> are starting to *ask* for it will help make hotels aware of IPv6.

I see no pointing in asking for something that a hotel agent is going to
not be able to respond to.

if you want a brown M & M's crontract you're going to actually have to
work with an agent that can grok and then meet your requirements.

> Dale
> ___
> 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: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Randy Bush]

> I don't see any significant value in asking the community for input on
> an RFP that is for hiring someone to write a specification to generate
> community input.

the problem may be that you may lack a sense of humor, an appreciation
of recursion, and a vision for just how twisted ietf process can be
made.

can we please restart the poisson wg so all this can be moved elsewhere?

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

RE: IPv6 support in hotel contract?

[George, Wes]

> From: Joel jaeggli [mailto:joe...@bogus.com]

> > At least, we should start *trying* to get IPv6 service from hotels.
> > We may have a very hard time getting it, but the fact that customers
> > are starting to *ask* for it will help make hotels aware of IPv6.
>
> I see no pointing in asking for something that a hotel agent is going
> to
> not be able to respond to.
>
> if you want a brown M & M's crontract you're going to actually have to
> work with an agent that can grok and then meet your requirements.

[WEG]] Joel, I think this is a spurious line of logic. We already have plenty 
of "brown M&Ms" requirements. We bring in our own internet access (sometimes by 
running new fiber into the building). We ask for the ability to take over the 
hotel's guest room wireless network or at least the uplink. If we get told no, 
we try (I hope) to ask about their abilities to cope with an extremely high 
amount of simultaneous internet usage, we ask lots of questions about the 
technical logistics of putting on a conference of this size, including using 
their power and cabling to provide wireless in common areas, interacting with 
their PA system, using their equipment, etc, and the "hotel agent" either 
answers them directly or finds someone who can.
We don't generally work with "Roscoe's Motor Lodge" whose internet service is a 
single residential AP managed by "my brother Darrel." These are international 
hotel chains, usually with contracts to national/international corporations to 
professionally manage their guest internet services. If we ask, the response is 
likely to be "well, no one's ever asked for that before..." but that should be 
followed with "...but we'll find out..."

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: IPv6 support in hotel contract?

[David Morris]

On Thu, 20 Oct 2011, George, Wes wrote:

> > From: Joel jaeggli [mailto:joe...@bogus.com]
> 
> > > At least, we should start *trying* to get IPv6 service from hotels.
> > > We may have a very hard time getting it, but the fact that customers
> > > are starting to *ask* for it will help make hotels aware of IPv6.
> >
> > I see no pointing in asking for something that a hotel agent is going
> > to not be able to respond to.
> >
> > if you want a brown M & M's crontract you're going to actually have to
> > work with an agent that can grok and then meet your requirements.
> 
> [WEG]] Joel, I think this is a spurious line of logic. We already have 
> plenty of "brown M&Ms" requirements. We bring in our own internet access 
...
> professionally manage their guest internet services. If we ask, the 
> response is likely to be "well, no one's ever asked for that before..." 
> but that should be followed with "...but we'll find out..."

+1 ... and asking will raise awareness of the issue.

Of course, as has been mentioned many times in other threads, we
negotiate meeting venues a long time in advance. There may even
be an IT support plan to add IPV6 before we arrive..
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Anotherj RFP without IETF community input

[Worley, Dale R (Dale)]

> From: Simon Perreault [simon.perrea...@viagenie.ca]
> 
> On 2011-10-20 08:41, George, Wes wrote:
> > I'm also completely mystified as to why IPv6 support for all
> > proposed/requested features is not an explicitly stated requirement,
> > even at this phase.
> 
> And more generally, this should be considered an opportunity for
> dogfooding the protocols we create. IPv6 is one of them. SIP, RTP, the
> XCON stuff, and XMPP could be others.

I agree with the sentiment, but at *this* stage, that is, *finding*
someone to write the requirements, the RFP should not include specific
requirements for the remote participation system.

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

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Phillip Hallam-Baker]

One thing to consider is charging for this service

I have no problem paying some fee to the IETF in order to get better remote
participation capability when I am unable to travel to the location chosen.

I would much rather pay $200-$300 to have good remote attendance capability
(video etc.) than get by on 'free'.

This would be assuming that there would be some markup on the remote
attendance cost to finance the secretariat etc.


This is not something I would have suggested until recently because the
broadband connectivity has not been up to it until very recently.


On Thu, Oct 20, 2011 at 12:29 PM, Randy Bush  wrote:

> i read the message from ray as an rfp for someone to write the rfp for
> remote services.  aside from being a very amusing bureaucratic layer
> cake, this would not seem to need a lot of experience with remote
> access, but rather good ears and a taste for the bureaucracy and discord
> the ietf has become.
>
> randy
>



-- 
Website: http://hallambaker.com/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [IAOC] Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[John C Klensin]

--On Thursday, October 20, 2011 10:50 -0700 Bob Hinden
 wrote:

> John,
> 
> The RFP is not a solicitation to vendors of remote
> participation services.  It is to hire someone to write a
> requirements document for remote participation services.  It
> is not to develop any code nor are the items listed in the RFP
> the only things that should be included.  

Bob,

I was somewhat confused by differences between the description
of the RFP in the announcement that was sent out and the RFP
itself (aggravated very slightly by the link in the announcement
not being correct).  I apologize for that confusion at the same
time I suggest that propriety suggests that they should be
consistent.

That said, I understood that this was to hire someone to write a
requirements document.  I suggest that, if you want a fair and
open process, it would be good to follow the rules closely
enough to make it possible for non-insiders to bid (or to make
it explicit that only insiders and regular attendees are
eligible).

As I mentioned in my response to Henk, what you ask for in an
RFP not only affects what you get (even if all you are looking
for is a requirements spec) and who is likely to consider it
plausible to bid.  More important, I see nothing in BCP 101 that
says that the IAOC does not need to expose draft RFPs to
community review just because they do not, e.g., require code to
be written.  If the IAOC believes that such an exception is
needed because things don't work without it, then BCP 101 very
explicitly requires that the IAOC submit a change proposal to
the community.  That hasn't been done, so there is no exception.

> Note that it
> explicitly calls for having community input into the
> requirements.  The RFP includes:
> 
>   "After gathering all of this input, the contractor will
> prepare aninitial specification for review by the IETF
> Tools Team and thevmeet mail list participants."
> 
> and
> 
>   "Specifications will be circulated as IETF Internet-Drafts
> (I-D)"

Right.  But those are provisions for community review of a
requirements spec, expressed as an I-D.  We know how to handle
those, especially if you already have General AD and IESG
agreement for a Last Call.  What I'm concerned about is
community review of the RFP to be sure that any proposals
address the right set of issues and use adequate mechanisms to
be sure a good spec is developed (see my note to Henk).

> The intent of this work is to develop a set of requirements
> for community review.  I don't see any significant value in
> asking the community for input on an RFP that is for hiring
> someone to write a specification to generate community input.  

Again, I don't believe that BCP 101 or the associated
discussions and precedents give you (or the IAOC) the authority
to eliminate community review on the grounds that you don't see
it as having significant value.  Consider what would happen if
the IESG decided to waive IETF Last Call on a Standards-Track
document on the grounds that they understood the community well
enough to know that such a Last Call would be unlikely to yield
any significant comments.   I have no doubt that they could make
those judgments and make them accurately, but that is not the
point.  Nor is the IAOC authorized to translate its obligations
about transparency and openness to community comment so that it
applies only in cases where you believe there is significant
value in asking.

>...
> Regarding the IAOC minutes, the IAOC is aware that there is a
> problem.  I am sorry to report that the current volunteer
> approach to taking and producing IAOC minutes is not working.
> I had hoped we could make the volunteer approach work.  The
> IAOC concluded on today's IAOC call that we should approach
> ISOC to get additional administrative support to improve this
> function.  I will report on the outcome of that in Taipei.

I look forward to your report, but have a sense of deja vu about
prior discussions of this problem and similar commitments.
Perhaps I was just dreaming on the prior occasions.

best,
   john

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

Re: Anotherj RFP without IETF community input

[Kevin P. Fleming]

On 10/20/2011 02:21 PM, Phillip Hallam-Baker wrote:

One thing to consider is charging for this service

I have no problem paying some fee to the IETF in order to get better
remote participation capability when I am unable to travel to the
location chosen.

I would much rather pay $200-$300 to have good remote attendance
capability (video etc.) than get by on 'free'.


I would also be onboard with paying a reasonable (USD200) fee to have 
high-quality remote participation available. The free options should 
still exist, but they can continue to be 'best-effort' services.


--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[John C Klensin]

--On Thursday, October 20, 2011 15:21 -0400 Phillip Hallam-Baker
 wrote:

> One thing to consider is charging for this service
> 
> I have no problem paying some fee to the IETF in order to get
> better remote participation capability when I am unable to
> travel to the location chosen.
> 
> I would much rather pay $200-$300 to have good remote
> attendance capability (video etc.) than get by on 'free'.
>...

Hi.

As others have pointed out, this is an RFP about writing a
requirements spec.  Please examine the announcement and RFP (I
assume the latter is authoritative, but am not sure) to
determine whether you think the RFP should require that a
contractor include studying this issue as part of the task.
Perhaps it is.  If so, you should be objecting to the RFP
itself.  If not, this type of comment should probably be raised
when the first draft I-D shows up.

IMO, the question of "environments" to be examined is definitely
insufficient in the RFP, not because it prohibits a contractor
from doing or proposing anything else (as Bob points out, it
doesn't) but because I believe a draft requirements
specification would be completely inadequate unless some or all
of those issues -- especially issues with meetings that do not
conform to the paragraph starting "Each session..." in the
"Background" part of the SOW in the RFP --  were addressed.

Similarly, I don't think the RFP is adequate unless it insists
on proposals in which applicants provide details about their
plans for "conducting interviews" with the various listed
parties.  Some of those groups, especially those who have
actually participated remotely in one or more meetings but
normally attend in person and those who almost always
participate remotely, are often underrepresented in IETF
considerations and easily blown off, especially if the
contractor expects all interviews to be completed in the IETF 82
timeframe.   Without such a requirement, we could easily find
ourselves in a situation in which a contractor said "we bid on
the basis of resources to conduct interviews that week; if
additional interviews are needed, you will need to adjust the
terms".

I cite those as examples of comments on the RFP in the hope of
making the distinction between such comments and an attempt to
pre-discuss the I-D that will presumably come out of this
process.

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

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[Randy Bush]

> One thing to consider is charging for this service

i strongly agree.  whoever is drafting the rfp should charge heavily for
putting up with massive micromanagement.

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

Re: Anotherj RFP without IETF community input (was: Re: RFP for Remote Participation Services Specifications Development)

[edj . etc]

Requirements are one thing.

How about some discussion of "goals" to drive the requirements?  For example, 
is it a goal of the RFP to specify a tool set that would be so good that people 
would pay to use it?  

My reaction to the text in the announcement of the RFP is that the overall 
objectives are ill-defined.

> to enhance remote participation at IETF meetings,
> interim and virtual working group meetings.

What does "to enhance" mean in this context?

If I was at all interested in bidding on this new piece of spec development 
work, I would either ask for a lot more clarity on the desired goals of 
"enhanced" remote participation, or I would propose that the first phase of the 
project should be focused on developing some consensus on this.

+1 to John Klensin's view that if the RFP had been reviewed by the community 
before publication, it would have been better.

Regards,

Ed  J.

-Original Message-
From: John C Klensin 
Sender: ietf-boun...@ietf.org
Date: Thu, 20 Oct 2011 15:41:22 
To: Phillip Hallam-Baker
Cc: ; ; 
Subject: Re: Anotherj RFP without IETF community input (was: Re:
RFP for Remote Participation Services Specifications Development)



--On Thursday, October 20, 2011 15:21 -0400 Phillip Hallam-Baker
 wrote:

> One thing to consider is charging for this service
> 
> I have no problem paying some fee to the IETF in order to get
> better remote participation capability when I am unable to
> travel to the location chosen.
> 
> I would much rather pay $200-$300 to have good remote
> attendance capability (video etc.) than get by on 'free'.
>...

Hi.

As others have pointed out, this is an RFP about writing a
requirements spec.  Please examine the announcement and RFP (I
assume the latter is authoritative, but am not sure) to
determine whether you think the RFP should require that a
contractor include studying this issue as part of the task.
Perhaps it is.  If so, you should be objecting to the RFP
itself.  If not, this type of comment should probably be raised
when the first draft I-D shows up.

IMO, the question of "environments" to be examined is definitely
insufficient in the RFP, not because it prohibits a contractor
from doing or proposing anything else (as Bob points out, it
doesn't) but because I believe a draft requirements
specification would be completely inadequate unless some or all
of those issues -- especially issues with meetings that do not
conform to the paragraph starting "Each session..." in the
"Background" part of the SOW in the RFP --  were addressed.

Similarly, I don't think the RFP is adequate unless it insists
on proposals in which applicants provide details about their
plans for "conducting interviews" with the various listed
parties.  Some of those groups, especially those who have
actually participated remotely in one or more meetings but
normally attend in person and those who almost always
participate remotely, are often underrepresented in IETF
considerations and easily blown off, especially if the
contractor expects all interviews to be completed in the IETF 82
timeframe.   Without such a requirement, we could easily find
ourselves in a situation in which a contractor said "we bid on
the basis of resources to conduct interviews that week; if
additional interviews are needed, you will need to adjust the
terms".

I cite those as examples of comments on the RFP in the hope of
making the distinction between such comments and an attempt to
pre-discuss the I-D that will presumably come out of this
process.

best,
   john
 
___
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: IPv6 support in hotel contract?

[Alejandro Acosta]

On Thu, Oct 20, 2011 at 2:29 PM, David Morris  wrote:
>
>
> On Thu, 20 Oct 2011, George, Wes wrote:
>
>> > From: Joel jaeggli [mailto:joe...@bogus.com]
>>
>> > > At least, we should start *trying* to get IPv6 service from hotels.
>> > > We may have a very hard time getting it, but the fact that customers
>> > > are starting to *ask* for it will help make hotels aware of IPv6.
>> >
>> > I see no pointing in asking for something that a hotel agent is going
>> > to not be able to respond to.
>> >
>> > if you want a brown M & M's crontract you're going to actually have to
>> > work with an agent that can grok and then meet your requirements.
>>
>> [WEG]] Joel, I think this is a spurious line of logic. We already have
>> plenty of "brown M&Ms" requirements. We bring in our own internet access
> ...
>> professionally manage their guest internet services. If we ask, the
>> response is likely to be "well, no one's ever asked for that before..."
>> but that should be followed with "...but we'll find out..."
>
> +1 ... and asking will raise awareness of the issue.

+1  we always should try

>
> Of course, as has been mentioned many times in other threads, we
> negotiate meeting venues a long time in advance. There may even
> be an IT support plan to add IPV6 before we arrive..
> ___
> 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: IPv6 support in hotel contract?

[Robinson Tryon]

On Thu, Oct 20, 2011 at 2:59 PM, David Morris  wrote:
> Of course, as has been mentioned many times in other threads, we
> negotiate meeting venues a long time in advance. There may even
> be an IT support plan to add IPV6 before we arrive..

I think that it's great if they say they have a plan to add IPv6
support, but plans (especially about IPv6) seem to have a weird habit
of being delayed. It seems prudent to put it in the signed contract so
that there are no surprises from either the hotel/venue side or from
the conference organizers' side.

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

Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 79 messages in the last 7 days.
 
script run at: Fri Oct 21 00:53:02 EDT 2011
 
Messages   |  Bytes| Who
+--++--+
  6.33% |5 |  6.58% |43125 | john-i...@jck.com
  6.33% |5 |  3.82% |25024 | ra...@psg.com
  3.80% |3 |  5.99% |39239 | l...@pi.nu
  5.06% |4 |  4.06% |26595 | yaako...@rad.com
  2.53% |2 |  6.30% |41272 | malcolm.be...@zte.com.cn
  3.80% |3 |  4.41% |28862 | erminio.ottone...@libero.it
  3.80% |3 |  3.98% |26051 | wesley.geo...@twcable.com
  3.80% |3 |  3.90% |25559 | presn...@qualcomm.com
  3.80% |3 |  3.09% |20248 | miguel.a.gar...@ericsson.com
  3.80% |3 |  2.85% |18655 | dwor...@avaya.com
  3.80% |3 |  2.81% |18391 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com
  3.80% |3 |  2.56% |16748 | joe...@bogus.com
  2.53% |2 |  3.61% |23646 | sprom...@unina.it
  2.53% |2 |  3.41% |22326 | jdr...@juniper.net
  2.53% |2 |  2.70% |17656 | s...@resistor.net
  2.53% |2 |  2.52% |16534 | barryle...@computer.org
  2.53% |2 |  2.02% |13236 | sarikaya2...@gmail.com
  1.27% |1 |  2.55% |16714 | bob.hin...@gmail.com
  1.27% |1 |  1.78% |11644 | trej...@gmail.com
  1.27% |1 |  1.66% |10848 | neil.2.harri...@bt.com
  1.27% |1 |  1.65% |10777 | alessandro.dalessan...@telecomitalia.it
  1.27% |1 |  1.64% |10755 | huubatw...@gmail.com
  1.27% |1 |  1.47% | 9604 | edj@gmail.com
  1.27% |1 |  1.42% | 9285 | th...@sfc.wide.ad.jp
  1.27% |1 |  1.42% | 9273 | kathleen.moria...@emc.com
  1.27% |1 |  1.40% | 9147 | nar...@us.ibm.com
  1.27% |1 |  1.31% | 8589 | i...@ietf.org
  1.27% |1 |  1.20% | 7836 | sha...@juniper.net
  1.27% |1 |  1.19% | 7768 | hal...@gmail.com
  1.27% |1 |  1.15% | 7535 | s...@elandnews.com
  1.27% |1 |  1.14% | 7459 | daedu...@btconnect.com
  1.27% |1 |  1.13% | 7384 | asay...@cisco.com
  1.27% |1 |  1.13% | 7378 | n...@gnutls.org
  1.27% |1 |  1.09% | 7111 | go...@erg.abdn.ac.uk
  1.27% |1 |  1.04% | 6837 | alejandroacostaal...@gmail.com
  1.27% |1 |  1.03% | 6740 | d...@cridland.net
  1.27% |1 |  1.01% | 6602 | henk.uijterw...@gmail.com
  1.27% |1 |  0.99% | 6486 | jdfalk-li...@cybernothing.org
  1.27% |1 |  0.98% | 6438 | adr...@olddog.co.uk
  1.27% |1 |  0.94% | 6130 | d...@xpasc.com
  1.27% |1 |  0.91% | 5928 | bishop.robin...@gmail.com
  1.27% |1 |  0.88% | 5769 | hous...@vigilsec.com
  1.27% |1 |  0.87% | 5716 | kpflem...@digium.com
  1.27% |1 |  0.84% | 5484 | simon.perrea...@viagenie.ca
  1.27% |1 |  0.81% | 5317 | jo...@iecc.com
  1.27% |1 |  0.81% | 5275 | b...@nostrum.com
+--++--+
100.00% |   79 |100.00% |   654996 | Total

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

Re: IPv6 support in hotel contract?

[Cullen Jennings]

We just failed to manager to find a venue in Asia because there was no venue 
that meant all the constraints. I'd rather not add more constraints to the 
hotel selection. I love the taste of dog food, but v6 in the hotel is not 
something that I find critical to accomplish the task I come to IETF to get 
done. 


On Oct 20, 2011, at 7:01 AM, George, Wes wrote:

> My last message caused something else to occur to me – there has been a lot 
> of discussion both here and at NANOG about hotels being woefully 
> underprepared for the internet (and address) use that their guests generate 
> when a conference full of geeks and their multiple devices per person descend 
> upon them. Sometimes the IETF is successful at convincing the hotel to let 
> them take over the internet service in the guest rooms, sometimes not.
>  
> Perhaps we can kill two birds with one stone by starting to require IPv6 
> service in the guest rooms when we enter into negotiations with hotels. If 
> they don’t have it, we’ll be happy to temporarily take over the internet 
> service, or assist them in getting it enabled permanently in their existing 
> network, and if neither of those options are acceptable, it provides 
> negotiating leverage on other things. This also has the net effect of 
> starting to make it clear to hotel management that IPv6 is going to start 
> being mandatory for some subset of their guests before too much longer.
>  
> I realize that having something in the contract doesn’t mean that we’re any 
> more likely to get it. But the fact that it’s in the contract makes a 
> statement in and of itself. IAOC, any reason why this couldn’t be added, 
> especially given how far in advance you’re negotiating with venues?
>  
> Thanks,
>  
> Wes George
>  
> 
> This E-mail and any of its attachments may contain Time Warner Cable 
> proprietary information, which is privileged, confidential, or subject to 
> copyright belonging to Time Warner Cable. This E-mail is intended solely for 
> the use of the individual or entity to which it is addressed. If you are not 
> the intended recipient of this E-mail, you are hereby notified that any 
> dissemination, distribution, copying, or action taken in relation to the 
> contents of and attachments to this E-mail is strictly prohibited and may be 
> unlawful. If you have received this E-mail in error, please notify the sender 
> immediately and permanently delete the original and any copy of this E-mail 
> and any printout.
> ___
> 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