Re: Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org]

[Glen Zorn]

On 06/08/2013 02:52 AM, Brian E Carpenter wrote:


Rule 1 for complex and divergent mail threads is to change the
Subject header when the subject changes. If you don't do that,
your mail is rather likely to get junked.

I think that IETF last call threads should stay on the main IETF
discussion list. That is exactly the right place for them.


Since I've requested (read "begged" ;-) for such threads to be moved to 
their own list on several occasions, I disagree again.



It's rather trivial to filter them into a dedicated folder;
I have one called 'lastcallsin', that also picks up most
WG Last Call threads, although those have less standardised
subject headers.


This would appear to work consistently only as long as 'Rule 1' above is 
not followed.




Brian

On 08/06/2013 06:17, Juliao Braga wrote:

+1

Em 07/06/2013 15:09, Ulrich Herberg escreveu:

I like the idea of a separate list for last calls. It would not solve
the issue of noise for all of us (and not reduce the overall amount of
emails), but it would separate general discussions from IETF LCs. I
have IETF emails filtered by mailing list into different IMAP folders,
and thus a separation could be useful for me.

Ulrich

Re: Last Call: (Security Threats for NHDP) to Informational RFC

[Abdussalam Baryun]

Dear Routing Area AD,

I had many comments/issues regarding your area always addressed to you
and  including this issue which I hope my all comments (past/present)
will help to make better practice/procedural progresses in this IETF
Area.
I am sorry also to any one receiving this email but I send it only to
an AD, IETF, and IESG. This is not noise but a signal to IETF to
progress, if you think it is noise please explain, and please notice
that all particpants have rights under the IETF procedures not only
managements. My reply below and if you want to continue discussing on
any other list please inform me, but if you reply copying any list, I
will have to do the same because you are part of management and I am
not.

On 6/6/13, Adrian Farrel  wrote:
> Sorry to everyone for the noise this thread is creating.

This thread containing my messages never creates noise, I beleive you
may ne refering to your messages only as noise. Please note that I
don't accept this describtion, I think that community messages
regarding any I-D is never noise even if the IETF management could not
handle the volume. I RECOMMEND any receiver that has noise in it to
fix its problem without blaming transmitters.

> Multiple questions that I have to answer.

ok, that is why this list is discussing list for ietf progress,

>
>> > It falls to me to make a call on this issue before the document moves
>> > on.
>> >
>> > Abdussalam has complained that he has not been acknowledged and has
>> > objected to the current text in section 8.
>> > The authors have responded on the MANET list
>> >
>> >> We believe that only comments that lead to significant improvements of
>> >> the draft deserve a listing in the acknowledgment section, and we have
>> >> therefore not modified the section.
>>
>> What was the WG decision?
>
> Are you asking whether there was an explicit consensus call within the
> working
> group on whether or not you should be acknowledged in this document?

I think the question is clear, and is easy to answer. The answer is,
there was no decision made by the WG or the community regarding my
request of adding a name in the ack section. You send me back a
question saying explicit consensus, it is simpler to make my question
asking of notification of such reaction from management, which was not
either established. I did not get a message saying that any kind of
consensus was established privately/publicly on any IETF lists (please
ask the WG chair because I am sure I did not received any answer for
my request by the WG/community).

> There was no such call in the working group or on the IETF list.

Thanks for the answer, so I understand that the editors/management did
not answer my request (one person from the community), just because
they or AD did not beleive in my concerns without consulting the WG in
any way.

>
>> Why any contribution that influnces the I-D ideas is not acknowledged?
>> IMO, if a technical-idea within the I-D was discovered wrong by a
>> participant, or a new technical-idea added to I-D from an input, then
>> the I-D should be acknowledged.
>
> This opinion does not apply to your comments on this document. You did not
> discover a wrong technical-idea. Your comments did not lead directly to the
> addition of any new technical-idea.

The question of I-D managers not acknowledging such
input/contribution, was not answered if you agree to acknowledge
discovering an error or adding a new idea. Regarding the opinion, do
you agree with the opinion first? Regarding the error and missing
information, I did discover error in the document and did found
missing definitions if this informational I-D (after my contribution
there was changes made to the document, please notice that)
>
>> > I have reviewed the email threads on the MANET mailing list and do not
>> > consider that Abdussalam made contributions to the text of the
>> > document.
>>
>> Didn't that person make review and discovered errors?
>
> "That person" is you.

Yes but I said that because this message it not me defending me, it is
me defending future wrong reaction of ignoring to acknowledge the
persons in the community. If any I-D authors are best knowledgeable
people in a special field they should not try to seek to
dis-acknowledge the community efforts that changed few I-D ideas (even
if the community person is not expert, that does not mean that authors
have right to exclude contributors).

> Yes, you made a review. Reviewing a document is not something authors
> acknowledge in the IETF or (AFAIK) in academic journals.

I disagree with your opinion, but do you think your opinion is in the
IETF procedure, if yes please provide me with that procedure of not
acknowledgement. I respect your opinion but it is wrong because in one
sense yes documents in the world don't acknowledge all reviews
(usually when they don't request it), one the other hand the world
documents do acknowledge reviews when the document owner calls for
review. Please note that this I-D did r

Re: Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org]

[Arturo Servin]

I have mixed opinions, filters in general work well (some false
positives like these ones that are moved to my "Last Call" filter) but
in general it is ok.

But I would not oppose to a new list for LC only.

Regards,
as

On 6/7/13 4:52 PM, Brian E Carpenter wrote:
> I think that IETF last call threads should stay on the main IETF
> discussion list. That is exactly the right place for them.
> It's rather trivial to filter them into a dedicated folder;
> I have one called 'lastcallsin', that also picks up most
> WG Last Call threads, although those have less standardised
> subject headers.

Additional NomCom Chair Email Aliases

[Alexa Morris]

As you probably know, this has been an unusual year for the NomCom. Matt 
Lepinski is wrapping up the work of the 2012-13 NomCom, while Allison Mankin is 
actively recruiting volunteers for the 2013-14 NomCom. To address the fact that 
we currently have two active NomCom Chairs, and to acknowledge that such a 
situation may recur at some point, it was determined that each chair should 
have a unique email alias. We have recently created the following:

- nomcom-chair-2...@ietf.org, which sends mail to Matt Lepinski

- nomcom-chair-2...@ietf.org, which sends mail to Allison Mankin

The email alias nomcom-ch...@ietf.org will also remain active, and will forward 
to Matt until the 2012-13 NomCom has completed their work. At that time we will 
configure it to forward to Allison, and we will alert the community about the 
change. 

Please let me know if you have any questions or concerns.

Regards,
Alexa


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

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

Re: Weekly posting summary for ietf@ietf.org

[John C Klensin]

--On Friday, 07 June, 2013 10:57 -0700 Bob Hinden
 wrote:

> Thomas,
> 
>> From my perspective, the intention/usefulness of the weekly
>> posting is to give folk a high-level view of who is posting
>> and how often. It is not uncommon to see certain individuals
>> stand out. In some cases, that makes perfect sense -- and the
>...
> I agree with your conclusion.  
> 
> I also wish that the signal level was higher.  The IETF list
> is important because we need to have a place where IETF wide
> issues can be discussed.  That doesn't work if many people
> unsubscribe due to the the low signal to noise level.

Agreed so far.

>  I hope
> that that people who consistently show up at the top of the
> posting summary will moderate their behavior.

And it is getting to that conclusion from the above that often
troubles me about the posting summary list rankings.  Assuming a
significant issues shows up on the list, whether in conjunction
with a Last Call or something else.  Posting a comment and then
following up the comments of others with a couple of more
postings constitutes three messages in a week, which is pretty
reasonable.  On the other hand, if there are four such issues in
a single week (it happens) then that same individual gets
"credited" with a dozen messages, which would make the top of
the list in many weeks.  

Because things do often seem to happen in clusters, the summary
list might be improved significantly by adding a four-week
average and rankings based on it.  That would help distinguish
the regular heavy posters from those whose numbers went up
because of a particular issue or set of issues in a given week
or two.

What that still wouldn't help with is distinguishing from a
theoretical very active and diligent IETF participant who
reviews and comments on every document that goes into Last Call
push every other issue discussed on the list and a troll who
comments on every Last Call and on other issues that he, she, or
it might even generate.  To measure that difference, one would
need a measure of the useful and relevant information content of
a message, not just a character/byte count.

best,
   john

Re: Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org]

[Melinda Shore]

On 6/7/13 11:52 AM, Brian E Carpenter wrote:
> Rule 1 for complex and divergent mail threads is to change the
> Subject header when the subject changes. If you don't do that,
> your mail is rather likely to get junked.
> 
> I think that IETF last call threads should stay on the main IETF
> discussion list. That is exactly the right place for them.

I tend to think so, as well.  You never know when someone's
going to stumble over something and make a comment that matters.
The cost is that you get jackasses being loud and petty, but frankly
you'd get that on a last call mailing list, anyway, since IETF
last calls have in a few cases been known to function as jackass
magnets.

It seems to me that the real problem isn't last calls, it's
people not understanding that behaving badly has a cost associated
with it, and that cost is that they're alienating people they'd
(apparently) like to work with and demolishing their chances of
getting an editorship or moving into leadership roles.

Melinda

Best list for IETF last calls [was: Weekly posting summary for ietf@ietf.org]

[Brian E Carpenter]

Rule 1 for complex and divergent mail threads is to change the
Subject header when the subject changes. If you don't do that,
your mail is rather likely to get junked.

I think that IETF last call threads should stay on the main IETF
discussion list. That is exactly the right place for them.
It's rather trivial to filter them into a dedicated folder;
I have one called 'lastcallsin', that also picks up most
WG Last Call threads, although those have less standardised
subject headers.

   Brian

On 08/06/2013 06:17, Juliao Braga wrote:
> +1
> 
> Em 07/06/2013 15:09, Ulrich Herberg escreveu:
>> I like the idea of a separate list for last calls. It would not solve
>> the issue of noise for all of us (and not reduce the overall amount of
>> emails), but it would separate general discussions from IETF LCs. I
>> have IETF emails filtered by mailing list into different IMAP folders,
>> and thus a separation could be useful for me.
>>
>> Ulrich
> 

Re: Weekly posting summary for ietf@ietf.org

[Juliao Braga]

+1

Em 07/06/2013 15:09, Ulrich Herberg escreveu:
> I like the idea of a separate list for last calls. It would not solve
> the issue of noise for all of us (and not reduce the overall amount of
> emails), but it would separate general discussions from IETF LCs. I
> have IETF emails filtered by mailing list into different IMAP folders,
> and thus a separation could be useful for me.
> 
> Ulrich

Re: Weekly posting summary for ietf@ietf.org

[Ulrich Herberg]

I like the idea of a separate list for last calls. It would not solve
the issue of noise for all of us (and not reduce the overall amount of
emails), but it would separate general discussions from IETF LCs. I
have IETF emails filtered by mailing list into different IMAP folders,
and thus a separation could be useful for me.

Ulrich

On Fri, Jun 7, 2013 at 9:11 AM, Andy Bierman  wrote:
>
>
> On Fri, Jun 7, 2013 at 8:52 AM, Ted Lemon  wrote:
>>
>> On Jun 7, 2013, at 11:48 AM, Andy Bierman  wrote:
>>
>> So why not move the signal?
>> Put IETF Last Call mail on last-c...@ietf.org and leave this list for
>> everything else.
>>
>>
>> The discussion still has to happen somewhere.   I certainly am not
>> restricting my meaningful participation in last calls, but even in that case
>> it is important to be restrained and not get into long fruitless
>> discussions, which, I am afraid, I am wont to do.
>>
>
>
> Some people consider the last call discussions to be signal
> and the rest (vast majority) of discussions to be noise.
> They would subscribe to a last-call mailing list, but not this one.
>
>
> Andy
>

Re: Weekly posting summary for ietf@ietf.org

[Bob Hinden]

Thomas,

> From my perspective, the intention/usefulness of the weekly posting is
> to give folk a high-level view of who is posting and how often. It is
> not uncommon to see certain individuals stand out. In some cases, that
> makes perfect sense -- and the signal level is high. In other cases,
> it shows (IMO) people who are too quick to post and who (too often)
> say predictable things if you've read previous threads on the same
> general topic. YMMV.

I agree with your conclusion.  

I also wish that the signal level was higher.  The IETF list is important 
because we need to have a place where IETF wide issues can be discussed.  That 
doesn't work if many people unsubscribe due to the the low signal to noise 
level.  I hope that that people who consistently show up at the top of the 
posting summary will moderate their behavior.

Bob

Re: Weekly posting summary for ietf@ietf.org

[Michael Richardson]

> "Andy" == Andy Bierman  writes:
Andy> So why not move the signal?
Andy> Put IETF Last Call mail on last-c...@ietf.org and leave this list for
Andy> everything else.

Okay, that would work for me.
Where would the reply-to: on those posts be set to?

I also don't think we ever solved the problem of moderation of @ietf.org
lists.  Specifically, I'd like it so that once I'm subscribed to one
@ietf.org list, that I could post to all of them. (Well, I wouldn't
post, I'd be replying in most cases)

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



pgpT7FRkD7HwL.pgp
Description: PGP signature

Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Elwyn Davies]

On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote:

> > Appendix F: I missed that the text/parameter format appeared in the
> > examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
> > definitions of these methods what encodings are acceptable for the
> > message bodies that may go with these methods and their responses.
> 
> Exactly, that is intentional. These methods can use anything that has a
> MIME type. Also it has HTTP's mechanisms for determining what formats
> one supports.
> 
> > Clearly the new text/parameter MIME format is one.  Is it the only one?
> 
> It is the only one defined by IETF for this purpose. That is why it is
> in the appendix so that RTSP users shall have something to define the
> parameters they want in. However, they have to accept the limitations of
> a basic text format.
> 
> > I guess you could use a application/json or an XML format but I guess
> > these would also either have to be called out explicitly in the method
> > descriptions or put in as feature extensions.  This needs to be
> > clarified in the method descriptions (s13).  The upshot of all this is
> > that I think Appendix F needs to be pulled back into Section 20 as
> > currently it is the only way to encode the message bodies.
> 
> I can agree that the format negotiation for the bodies of
> GET/SET_PARAMETER is not clear. I will look at proposing some
> improvements of the text related to the handling of method bodies and
> their format negotiation.
Good. I don't see where the server tells what formats it accepts for
either GET_PARAMETER or SET_PARAMETER.  Also the Accept spec doesn't say
anything about SET_PARAMETER.  AFAICS the client could tell the server
what formats it accepts as a side-effect of DESCRIBE but that's a bit
arcane - and it is not clear how you would separate the formats for
DESCRIBE from those for GET_PARAM and SET_PARAM.
> 
> However, I am not pulling in Appendix F. It is an optional to use format
> for parameter value pairs that can be used in these methods, it is not
> required. Nor, does the specification define any parameters that are
> transferred using this interface. The things that are in the appendix
> are not core protocol, they represent either informational things, like
> the examples and the state machine. The other appendices are normative
> definitions of particular choices for things that can be combined or
> used with RTSP, like RTP as media transport.
> 
OK, it is possible to use GET_PARAM for basic requirements without using
message bodies, so you can get away without defining a lowest common
denominator format. However, the use of message bodies for SET_PARAM is
RECOMMENDED so it seems a little odd not to ensure that server and
client will have at least one format in common. (And its not as if we
are dealing with a hugely complicated bit of spec for
text/parameters! :-) ).  Then, given the example in GET_PARAMETER it
seems sensible to advise implementing text/parameters as the default for
GET_PARAM also.

/Elwyn

Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Elwyn Davies]

On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote:
> Hi Elwyn,
> 
> Many thanks for the detailed review. We will address the nits you have
> raised, but I cut them out of this reply to focus on the more
> substantial issues you have brought up.
.. and thanks for the quick response.

> 
> See inline below.
OK.  I think the responses clear those issues.

I have done a little bit more on the Appendices and liaised a bit with
Robert Sparks.  'Highlights':

Appendix F: I missed that the text/parameter format appeared in the
examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
definitions of these methods what encodings are acceptable for the
message bodies that may go with these methods and their responses.
Clearly the new text/parameter MIME format is one.  Is it the only one?
I guess you could use a application/json or an XML format but I guess
these would also either have to be called out explicitly in the method
descriptions or put in as feature extensions.  This needs to be
clarified in the method descriptions (s13).  The upshot of all this is
that I think Appendix F needs to be pulled back into Section 20 as
currently it is the only way to encode the message bodies.

Appendix B: I appreciate that the state machine is illustrative and to
an extent 'abstract'.  However, the tables are really written to
describe the state machine in the server: the action column mostly
describes the events that come into the server (apart from the notify
actions) - sending these 'events' are actions in the client.  The 'real'
state machine in the both the server and the client has a somewhat more
complex form: I'd think that there was a STOPPED state in the server
when the media has reached an end point and not been explictly paused
and STARTING/PAUSING states in the client while the client waits for
response to PLAY/PAUSE respectively.  I think a little bit more
explanation about the dual nature of the columns would solve the
problem.

Appendix C: Pending.

Regards,
Elwyn
> 
> On 2013-06-06 02:11, Elwyn Davies wrote:
> > I am an additional Gen-ART reviewer for this draft. For background on
> > Gen-ART, please see the FAQ at
> > 
> > .
> > 
> > Please resolve these comments along with any other Last Call comments
> > you may receive.
> > 
> > Document: draft-ietf-mmusic-rfc2326bis
> > Reviewer: Elwyn Davies
> > Review Date: 5 June 2013
> > IETF LC End Date: 5 JUne 2013
> > IESG Telechat date: (if known) -
> > 
> > Summary:
> > Almost ready.  Generally this is an excellent and well written document,
> > particularly given its size.  There are a few minor issues to sort out
> > mainly at the nit level and some consistency issues to fix up.  The two
> > issues that I have brought out below are really at what the IESG would
> > call 'DISCUSS-DISCUSS' level.  The issue of URI scheme redefinition may
> > well have already been cleared by the URI expert - the draft does not do
> > itself any favours here by failing to explain what the syntax changes
> > are in s4.2; this raises immediate red flags that only start to fade a
> > couple of hundred pages later. The rudimentary nature of the pipeline
> > mechanism is carried over from RTSP 1.0.  I'd like to be sure that this
> > has been properly discussed in the WG as it looks pretty flaky to an
> > outsider.  There are several inconsistencies between various lists of
> > headers that need sorting out and there is no definition of
> > Proxy-Authorization in the ABNF.
> > 
> > There are also a fairly large number of editorial nits but these are all
> > localized and trivial to fix.  Finally I have't had time to review the
> > appendices (maybe there will be a follow up).
> > 
> > Robert Sparks is the main gen-art reviewer for the document; he asked
> > for additional eyes on the document given the size and his RAI
> > background.  Having (just) seen his review, I think we have both picked
> > up on the URI scheme and pipeline issues.  I am not sure that I concur
> > with his view that there is significant normative material in the
> > appendices - AFAICS the main protocol definition *is* in the main body
> > of the document and the bits especiially in Appendices B and C are not
> > the core of the protocol.  However this is based on a very cursory
> > glance through something like 75 pages of the document.  However, I do
> > concur with Robert's view that it needs a security expert to check the
> > security stories.
> > 
> > Major(ish) issues:
> > s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The 
> > last sentence of para 1 states that the 'details of the syntax' of the 
> > URIs 'have been changed'.  Is this a reasonable thing to do? Has this 
> > been cleared with the URI expert reviewer?  I am not entirely clear what 
> > the change involves and the draft doesn't explain exactly how the syntax 
> > has been altered  and its consequences (if any) in s4.2.  Some details
> > are fina

Re: Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC

[Richard Ogier]

AB,

As Joel pointed out, your questions should have been raised during the 
OSPF WG Last Call, which you did not participate in. You 
(inappropriately) posted questions on the MANET WG list after the OSPF 
WGLC was complete, and several people responded, most of them stating 
that RFC 5444 is not required for this document:


http://www.ietf.org/mail-archive/web/manet/current/msg15403.html
http://www.ietf.org/mail-archive/web/manet/current/msg15406.html
http://www.ietf.org/mail-archive/web/manet/current/msg15407.html
http://www.ietf.org/mail-archive/web/manet/current/msg15408.html

Although I should not be required to respond to your questions at this 
point, I will provide a few additional reasons why RFC 5444 and DLEP are 
not relevant for this document. (These reasons also apply to the 
parallel document draft-ietf-ospf-manet-single-hop-or-02.)


1. This draft does not propose a new interface, it only describes how 
the interface previously specified in RFC 5614 (and RFC 5820 for the 
other draft) can be configured in the special case of a single-hop 
MANET. Therefore, your comments should have been directed to RFC 5614 
(and RFC 5820).


2. RFCs 5614 and 5820 describe MANET extensions to OSPF, and one of the 
goals was to minimize changes to OSPF, so we decided to use OSPF packet 
formats (with minimal changes), rather than MANET packet formats that 
were designed without OSPF in mind. (This point is also made in the last 
message listed above.)


On the other hand, these are experimental documents, so your questions 
about using RFC 5444 and DLEP may be valid for future modifications to 
the proposed MANET extensions of OSPF (both RFCs 5614 and 5820). But 
they are not valid for draft-ietf-ospf-manet-single-hop-mdr or 
draft-ietf-ospf-manet-single-hop-or, not only because these two drafts 
have already completed WG Last Call, but also because they only describe 
how to configure RFCs 5614 and 5820 for the special case of a single-hop 
network.


Richard

On 6/6/13 3:15 AM, Abdussalam Baryun wrote:

> I send my request to the editors including questions but no reply from
> them to me. The thread [1] raised some issues, which is not mentioned
> in the I-D. The message [2] was ignored not answered (this is last
> reminder). The message [3] proposes using RFC5444 into this I-D, or
> raise the question of why not using MANET packet format within MANET
> domains (I need an answer).
>
> [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html
> [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html
> [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html
>
> The I-D SHOULD not go forward if it still ignores the IETF community 
questions.

>
> Regards
> AB
>
> On 6/5/13, The IESG  wrote:
>> The IESG has received a request from the Open Shortest Path First 
IGP WG

>> (ospf) to consider the following document:
>> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
>>  as Experimental 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 2013-06-19. 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
>>
>>
>> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
>> (MANETs) by specifying its operation on the new OSPF interface of type
>> MANET. This document describes the use of OSPF-MDR in a single-hop
>> broadcast network, which is a special case of a MANET in which each
>> router is a (one-hop) neighbor of each other router. Unlike an OSPF
>> broadcast interface, such an interface can have a different cost
>> associated with each neighbor. The document includes configuration
>> recommendations and simplified mechanisms that can be used in 
single-hop

>> broadcast networks.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/
>>
>> IESG discussion can be tracked via
>> 
http://datatracker.ietf.org/doc/draft-ietf-ospf-manet-single-hop-mdr/ballot/ 


>>
>>
>> No IPR declarations have been submitted directly on this I-D.

Re: Weekly posting summary for ietf@ietf.org

[Thomas Narten]

> I've wondered for some time whether the reported bytes is the
> whole message I send included context quotes, or if there is
> an attempt by the summary logic to factor out quoted
> content.

Original script is here:
http://www.hactrn.net/hacks/mh-list-traffic/mh-list-traffic

I don't think I've modified it other than to keep it running under my
local setup.

>From my perspective, the intention/usefulness of the weekly posting is
to give folk a high-level view of who is posting and how often. It is
not uncommon to see certain individuals stand out. In some cases, that
makes perfect sense -- and the signal level is high. In other cases,
it shows (IMO) people who are too quick to post and who (too often)
say predictable things if you've read previous threads on the same
general topic. YMMV.

Beyond that (e.g., tweaking the priorities of how rankings are done),
I don't see much point.  Different people will have different opinions
on what to give priority to, and this is ultimately a judgement call.

Thomas

Re: Weekly posting summary for ietf@ietf.org

[Tim Chown]

On 7 Jun 2013, at 17:12, joel jaeggli  wrote:

> On 6/7/13 6:03 PM, Tim Chown wrote:
>> 
>> As another example, the v6ops list has recently also had four threads run 
>> well over the 100 message count, specifically end to end response time, ULA 
>> usage, "being careful" about ULAs and the semantic prefix thread.
> v6ops had a single draft which attracted ~1100 messages over the course of a 
> year so this isn't new or unusual over there. A small number of posters tend 
> to be the majority of the volume on several topics, so if you're reading to 
> understand the positions of the working group or to measure consensus on the 
> list some judicious sorting is required.

Indeed.  Sorting and sifting through 500+ emails about one homenet topic over 
on 6man was similarly challenging (for the homenet arch text).  And many of 
those long v6ops threads were/are relevant to that.

It would be nice to determine some way to keep discussions open, without 
creating unnecessary volume, and repeating already raised arguments. 

Maybe the answer isn't email for judging consensus. As an outsider, I've seen 
the IESG/AD system, which seems to essentially allow positions on drafts to be 
expressed, and easily viewed at a glance. Maybe that's part of the answer, 
somehow. Some "position" view on a draft, that people can update/edit as the 
list discussion goes on, that becomes more useful "at a glance" for WG chairs 
and document editors?

We could continue as is with emails, but I've heard of a number of (very wise 
and valued) past contributors who no longer express their views, because of the 
problem of volume.

Or maybe it's not a valid concern.

Tim

Re: Weekly posting summary for ietf@ietf.org

[David Morris]

On Fri, 7 Jun 2013, Noel Chiappa wrote:

> > From: David Morris 
> 
> > I've wondered for some time whether the reported bytes is the whole
> > message I send included context quotes, or if there is an attempt by
> > the summary logic to factor out quoted content.
> 
> I think it's a _feature_ to count the included content, so that people who
> (often recursively) top-post on long prior messages, instead of editing down
> to just the bit(s) they are replying to, have some negative feedback for that
> (irritating) habit.

For now, I'm just trying to confirm my impression of the data. Folks who
don't make a case/case choice as to inline/top and removing chaff and
unneeded context probably aren't going to care where they stand on the
total byte count issue.

Re: Weekly posting summary for ietf@ietf.org

[joel jaeggli]

On 6/7/13 6:03 PM, Tim Chown wrote:
On 7 Jun 2013, at 16:52, Ted Lemon > wrote:


On Jun 7, 2013, at 11:48 AM, Andy Bierman > wrote:

So why not move the signal?
Put IETF Last Call mail onlast-c...@ietf.org 
and leave this list for everything else.


The discussion still has to happen somewhere.   I certainly am not 
restricting my meaningful participation in last calls, but even in 
that case it is important to be restrained and not get into long 
fruitless discussions, which, I am afraid, I am wont to do.


It's a significant problem for those who *have* to read the threads, 
in particular document authors, WG chairs, and ADs. Hats off to them 
for keeping up with it where they need to.


As another example, the v6ops list has recently also had four threads 
run well over the 100 message count, specifically end to end response 
time, ULA usage, "being careful" about ULAs and the semantic prefix 
thread.
v6ops had a single draft which attracted ~1100 messages over the course 
of a year so this isn't new or unusual over there. A small number of 
posters tend to be the majority of the volume on several topics, so if 
you're reading to understand the positions of the working group or to 
measure consensus on the list some judicious sorting is required.
Of course, a healthy debate is a good thing, as is having an open 
process for discussion. If we had very few comments that would 
certainly not be good either. But I fear that some valuable 
contributions are either being drowned out, or that some people with 
valuable input are being put off contributing.



Tim

Re: Weekly posting summary for ietf@ietf.org

[Andy Bierman]

On Fri, Jun 7, 2013 at 8:52 AM, Ted Lemon  wrote:

>  On Jun 7, 2013, at 11:48 AM, Andy Bierman  wrote:
>
>  So why not move the signal?
>  Put IETF Last Call mail on last-c...@ietf.org and leave this list for
> everything else.
>
>
> The discussion still has to happen somewhere.   I certainly am not
> restricting my meaningful participation in last calls, but even in that
> case it is important to be restrained and not get into long fruitless
> discussions, which, I am afraid, I am wont to do.
>
>

Some people consider the last call discussions to be signal
and the rest (vast majority) of discussions to be noise.
They would subscribe to a last-call mailing list, but not this one.


Andy

Re: Weekly posting summary for ietf@ietf.org

[Ted Lemon]

On Jun 7, 2013, at 12:04 PM, David Morris  wrote:
> I've wondered for some time whether the reported bytes is the
> whole message I send included context quotes, or if there is
> an attempt by the summary logic to factor out quoted
> content.

A penalty for top-posting sounds okay to me!

Re: Weekly posting summary for ietf@ietf.org

[Noel Chiappa]

> From: David Morris 

> I've wondered for some time whether the reported bytes is the whole
> message I send included context quotes, or if there is an attempt by
> the summary logic to factor out quoted content.

I think it's a _feature_ to count the included content, so that people who
(often recursively) top-post on long prior messages, instead of editing down
to just the bit(s) they are replying to, have some negative feedback for that
(irritating) habit.

Noel

Re: Weekly posting summary for ietf@ietf.org

[David Morris]

As long as the summary has been brought up ...

I've wondered for some time whether the reported bytes is the
whole message I send included context quotes, or if there is
an attempt by the summary logic to factor out quoted
content.

Dave Morris

Re: Weekly posting summary for ietf@ietf.org

[Tim Chown]

On 7 Jun 2013, at 16:52, Ted Lemon  wrote:

> On Jun 7, 2013, at 11:48 AM, Andy Bierman  wrote:
>> So why not move the signal?
>> Put IETF Last Call mail on last-c...@ietf.org and leave this list for 
>> everything else.
> 
> The discussion still has to happen somewhere.   I certainly am not 
> restricting my meaningful participation in last calls, but even in that case 
> it is important to be restrained and not get into long fruitless discussions, 
> which, I am afraid, I am wont to do.

It's a significant problem for those who *have* to read the threads, in 
particular document authors, WG chairs, and ADs. Hats off to them for keeping 
up with it where they need to.

As another example, the v6ops list has recently also had four threads run well 
over the 100 message count, specifically end to end response time, ULA usage, 
"being careful" about ULAs and the semantic prefix thread. 

Of course, a healthy debate is a good thing, as is having an open process for 
discussion. If we had very few comments that would certainly not be good 
either. But I fear that some valuable contributions are either being drowned 
out, or that some people with valuable input are being put off contributing.

Tim

Re: Weekly posting summary for ietf@ietf.org

[Ted Lemon]

On Jun 7, 2013, at 11:48 AM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:
So why not move the signal?
Put IETF Last Call mail on last-c...@ietf.org and 
leave this list for everything else.

The discussion still has to happen somewhere.   I certainly am not restricting 
my meaningful participation in last calls, but even in that case it is 
important to be restrained and not get into long fruitless discussions, which, 
I am afraid, I am wont to do.

Re: Weekly posting summary for ietf@ietf.org

[Andy Bierman]

On Fri, Jun 7, 2013 at 7:49 AM, Thomas Narten  wrote:

> What the weekly stats really ought to tally up is the readers/postings
> ratio, so that folk would get more direct feedback as to whether what they
> are
> posting is actually being read...
>
> My strong suspicion would be that there is strong negative correlation
> between frequency of posts and actual readers of those posts...
>
> Also, I suspect that many people do not realize that a significant
> chunk of IETF contributers are no longer subscribed to the ietf list
> due to signal to noise ratio concerns...
>
>
So why not move the signal?
Put IETF Last Call mail on last-c...@ietf.org and leave this list for
everything else.

I don't really want people counting their bytes when they are concerned
about
a technical issue in an I-D.  It may take several exchanges for a
disagreement
to be resolved.  Social pressure to stay out of the top-N report could have
a negative impact on last call debates.


Thomas
>
>
Andy

Re: Last Call: (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice

[Donald Eastlake]

Hi SM,

On Fri, Jun 7, 2013 at 6:24 AM, SM  wrote:
>
> At 04:07 07-05-2013, The IESG wrote:
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
>>802 Parameters'
>>as Best Current Practice
>>
>> 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 2013-06-04. Exceptionally, comments may be
>
> Sorry for the late comments.  I'll defer to the authors on what to do
> about them.
>
> In Section 2.1.3:
>
>   "o  must be for standards purposes (either for an IETF Standard or
>   other standard related to IETF work),"
>
> The above is not that clear.  I suggest using "IETF Review".  BTW, the
> documentation requirement could also be fulfilled with "Specification
> Required".

I agree that it is not a precise, perfectly "clear", mechanical rule.
That is why there is a Expert to make judgements.

This part is unchanged from RFC 5342 and actual experience does not
indicate any problem. I believe that, since RFC 5342 came out, seven
code points have been allocated under these provisions, all for single
MAC addresses, and the only request I am aware of that has not yet
been submitted is also for a single MAC address. I think it is silly
to bother the whole IETF (or even the whole IESG) for the allocation
of a single value when over ten million are available. I think it is
enough just to bother the Expert.

> Section 2.3.2.1 mentions changes to RFC 2153.  I suggest having an
> "Updates:" for that RFC.

OK.

> In Section 3.1:
>
>   "o  the assignment must be for standards use (either for an IETF
>   Standard or other standard related to IETF work),"
>
> IETF Review (see previous comment about that) could be used.

See previous response.

> In Section 4:
>
>   "If different policies from those above are required for such a
>parameter, a BCP or Standards Track RFC must be adopted updating this
>BCP and specifying the new policy and parameter."
>
> "Standards Action" could be used for this.

I believe the statement is brief, clear, and unambiguous and do not
see any reason to change it.

> In Section 5.1 I suggest using "IESG Approval".  BTW, IESG Ratification of
> an Expert Review approval recommendation looks unusual to me.

I believe the provisions of Section 5.1 are fine. In the extremely
rare cases (perhaps once every five years or so?) where a request
would require IESG Ratification, prior review by the Expert would be
beneficial so the IESG would have the benefit of the Expert's opinion
before they consider the request.

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

> Regards,
> -sm

Re: Weekly posting summary for ietf@ietf.org

[Thomas Narten]

What the weekly stats really ought to tally up is the readers/postings
ratio, so that folk would get more direct feedback as to whether what they are
posting is actually being read...

My strong suspicion would be that there is strong negative correlation
between frequency of posts and actual readers of those posts...

Also, I suspect that many people do not realize that a significant
chunk of IETF contributers are no longer subscribed to the ietf list
due to signal to noise ratio concerns...

Thomas

Re: Weekly posting summary for ietf@ietf.org

[Ted Lemon]

On Jun 7, 2013, at 4:33 AM, Abdussalam Baryun  
wrote:
> I recommend to add a column for subjects (number of subjects),
> because the number of subject participated in is very important is
> such summary.

It has always been my assumption that the point of this summary was to give us 
all a reality check when we say too much on the IETF mailing list.   Saying 
things on the IETF mailing list is very expensive because it addresses the 
entire IETF; we should choose our words carefully, and say no more than is 
absolutely necessary.   So I think that total volume is really the most 
important metric—I was very upset a month or so ago when I noticed that I'd 
been the most voluminous poster, and I've tried to avoid being the top poster 
again since then.

Re: Liaison Statement From the IESG and IAB to ISO/IEC JTC1/SC6 on TISec

[Michael Richardson]

> "IAB" == IAB Chair  writes:
IAB> The Liaison statement can be found here:
IAB> https://datatracker.ietf.org/liaison/1258/ 

IAB> The Internet Society will forward this liaison statement to
IAB> ISO/IEC JTC1/SC6 on their letterhead.  This will carry more
IAB> weight than a statement just from the IESG and IAB because the
IAB> Internet Society holds a Class A liaison with SC6 on behalf of
IAB> the IETF. 

Thanks for this heads up.
The ASCII art diagrams in the PDF at:

https://datatracker.ietf.org/documents/LIAISON/liaison-2013-06-06-the-iesg-and-the-iab-isoiec-jtc1-sc6-liaison-from-the-isoc-to-isoiec-jtc1sc6-and-its-national-body-members-in-relation-to-iso-iecjtc1-sc6_n15618-attachment-1.pdf

are regretably formatted with non-constant size spaces, so the diagrams
are perhaps much less useful than they could be.  Perhaps this document
could also be made available in .txt format?

IAB> The TISec proponents have indicated that they believe that
IAB> TISec is different than IPsec.  This liaison is a response this
IAB> statement.  It points out how IPsec supports the same
IAB> functionality, and it encourages 

IAB> the TISec proponents to engage in the IETF process to specify
IAB> the use of their national algorithms in IPsec, as has been done
IAB> for other national algorithms. 

I concur strongly with the IAB view, thank you for this.

-- 
]   Never tell me the odds! | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works| network architect  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



pgpHEwYj1bsWg.pgp
Description: PGP signature

Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Magnus Westerlund]

Hi Elwyn,

On 2013-06-07 14:26, Elwyn Davies wrote:
> On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote:
>> Hi Elwyn,
>>
>> Many thanks for the detailed review. We will address the nits you have
>> raised, but I cut them out of this reply to focus on the more
>> substantial issues you have brought up.
> .. and thanks for the quick response.
> 
>>
>> See inline below.
> OK.  I think the responses clear those issues.
> 
> I have done a little bit more on the Appendices and liaised a bit with
> Robert Sparks.  'Highlights':
> 
> Appendix F: I missed that the text/parameter format appeared in the
> examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
> definitions of these methods what encodings are acceptable for the
> message bodies that may go with these methods and their responses.

Exactly, that is intentional. These methods can use anything that has a
MIME type. Also it has HTTP's mechanisms for determining what formats
one supports.

> Clearly the new text/parameter MIME format is one.  Is it the only one?

It is the only one defined by IETF for this purpose. That is why it is
in the appendix so that RTSP users shall have something to define the
parameters they want in. However, they have to accept the limitations of
a basic text format.

> I guess you could use a application/json or an XML format but I guess
> these would also either have to be called out explicitly in the method
> descriptions or put in as feature extensions.  This needs to be
> clarified in the method descriptions (s13).  The upshot of all this is
> that I think Appendix F needs to be pulled back into Section 20 as
> currently it is the only way to encode the message bodies.

I can agree that the format negotiation for the bodies of
GET/SET_PARAMETER is not clear. I will look at proposing some
improvements of the text related to the handling of method bodies and
their format negotiation.

However, I am not pulling in Appendix F. It is an optional to use format
for parameter value pairs that can be used in these methods, it is not
required. Nor, does the specification define any parameters that are
transferred using this interface. The things that are in the appendix
are not core protocol, they represent either informational things, like
the examples and the state machine. The other appendices are normative
definitions of particular choices for things that can be combined or
used with RTSP, like RTP as media transport.

> 
> Appendix B: I appreciate that the state machine is illustrative and to
> an extent 'abstract'.  However, the tables are really written to
> describe the state machine in the server: the action column mostly
> describes the events that come into the server (apart from the notify
> actions) - sending these 'events' are actions in the client.  The 'real'
> state machine in the both the server and the client has a somewhat more
> complex form: I'd think that there was a STOPPED state in the server
> when the media has reached an end point and not been explictly paused
> and STARTING/PAUSING states in the client while the client waits for
> response to PLAY/PAUSE respectively.  I think a little bit more
> explanation about the dual nature of the columns would solve the
> problem.

There shouldn't be an issue to clarify this nature.

Cheers

Magnus Westerlund

--
Multimedia Technologies, Ericsson Research EAB/TVM
--
Ericsson AB| Phone  +46 10 7148287
Färögatan 6| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com
--

Re: Last Call: (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice

[SM]

At 04:07 07-05-2013, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE
   802 Parameters'
   as Best Current Practice

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 2013-06-04. Exceptionally, comments may be


Sorry for the late comments.  I'll defer to the authors on what to do 
about them.


In Section 2.1.3:

  "o  must be for standards purposes (either for an IETF Standard or
  other standard related to IETF work),"

The above is not that clear.  I suggest using "IETF Review".  BTW, 
the documentation requirement could also be fulfilled with 
"Specification Required".


Section 2.3.2.1 mentions changes to RFC 2153.  I suggest having an 
"Updates:" for that RFC.


In Section 3.1:

  "o  the assignment must be for standards use (either for an IETF
  Standard or other standard related to IETF work),"

IETF Review (see previous comment about that) could be used.

In Section 4:

  "If different policies from those above are required for such a
   parameter, a BCP or Standards Track RFC must be adopted updating this
   BCP and specifying the new policy and parameter."

"Standards Action" could be used for this.

In Section 5.1 I suggest using "IESG Approval".  BTW, IESG 
Ratification of an Expert Review approval recommendation looks unusual to me.


Regards,
-sm

Re: Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC

[Stewart Bryant]

On 07/06/2013 09:23, Abdussalam Baryun wrote:

Thanks for your respond below, AB


Thank you Richard and Abdussalam for reaching agreement
on this. I regard the issue as now closed.

Regards

Stewart Bryant
(speaking as responsible Area Director)

Re: Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Magnus Westerlund]

Hi Elwyn,

Many thanks for the detailed review. We will address the nits you have
raised, but I cut them out of this reply to focus on the more
substantial issues you have brought up.

See inline below.

On 2013-06-06 02:11, Elwyn Davies wrote:
> I am an additional Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> 
> .
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-mmusic-rfc2326bis
> Reviewer: Elwyn Davies
> Review Date: 5 June 2013
> IETF LC End Date: 5 JUne 2013
> IESG Telechat date: (if known) -
> 
> Summary:
> Almost ready.  Generally this is an excellent and well written document,
> particularly given its size.  There are a few minor issues to sort out
> mainly at the nit level and some consistency issues to fix up.  The two
> issues that I have brought out below are really at what the IESG would
> call 'DISCUSS-DISCUSS' level.  The issue of URI scheme redefinition may
> well have already been cleared by the URI expert - the draft does not do
> itself any favours here by failing to explain what the syntax changes
> are in s4.2; this raises immediate red flags that only start to fade a
> couple of hundred pages later. The rudimentary nature of the pipeline
> mechanism is carried over from RTSP 1.0.  I'd like to be sure that this
> has been properly discussed in the WG as it looks pretty flaky to an
> outsider.  There are several inconsistencies between various lists of
> headers that need sorting out and there is no definition of
> Proxy-Authorization in the ABNF.
> 
> There are also a fairly large number of editorial nits but these are all
> localized and trivial to fix.  Finally I have't had time to review the
> appendices (maybe there will be a follow up).
> 
> Robert Sparks is the main gen-art reviewer for the document; he asked
> for additional eyes on the document given the size and his RAI
> background.  Having (just) seen his review, I think we have both picked
> up on the URI scheme and pipeline issues.  I am not sure that I concur
> with his view that there is significant normative material in the
> appendices - AFAICS the main protocol definition *is* in the main body
> of the document and the bits especiially in Appendices B and C are not
> the core of the protocol.  However this is based on a very cursory
> glance through something like 75 pages of the document.  However, I do
> concur with Robert's view that it needs a security expert to check the
> security stories.
> 
> Major(ish) issues:
> s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The 
> last sentence of para 1 states that the 'details of the syntax' of the 
> URIs 'have been changed'.  Is this a reasonable thing to do? Has this 
> been cleared with the URI expert reviewer?  I am not entirely clear what 
> the change involves and the draft doesn't explain exactly how the syntax 
> has been altered  and its consequences (if any) in s4.2.  Some details
> are finally given in s22.14.

These syntax changes where discussed in the reviews I got on the URI
list. That resulted in the explicitness in the template, but I forgot
about adding anything into Section 4.2. I see no issue with adding the
following clarification to Section 4.2:

   The details of the syntax of "rtsp" and "rtsps" URIs has been changed
   from RTSP 1.0.  These changes are:

   o  Support for IPV6 literal in host part and future IP literals
  through RFC 3986 defined mechanism.

   o  A new relative format to use in the RTSP protocol elements that is
  not required to start with "/".

   Neither should have any significant impact on interoperability.  If
   one is required to use IPv6 literals to reach an RTSP server, then
   that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
   IPv6 capable protocol.  Thus, RTSP 2.0 support will be needed anyway.
   The second change will only occur in RTSP messages, that are
   explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0
   only agent will not be required to parse this variant.

I hope this makes it clear that these syntax changes is unlikely to hurt
the interoperability.

> 
> 
> Minor issues:
> s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0
> model of sending requests and worrying about success of prior prior
> pipelined requests was the right answer.  I would have thought that it
> might have been helpful to provide qualifiers on the Pipelined-Requests
> header that allowed subsequent requests to be suppressed unless the
> previous command resulted in one of a given set of status codes with a
> 'reset' option to 'restart' the pipeline.  It strikes me that this would
> avoid some irritating need to work out how to recover from arbitrary
> failures in a command chain in a client.
> 

I assume you mean this Section 12 paragraph:

   If a pipelined request builds on the successf

Re: Weekly posting summary for ietf@ietf.org

[Abdussalam Baryun]

Hi thomas,

AB> Comment on the summary report>

 I recommend to add a column for subjects (number of subjects),
because the number of subject participated in is very important is
such summary.
 I think the pupose of this summary should be added as well in each
post, I don't know why, only I expect the purpose is that it informs
of work volume or overhead in such list.

AB

On 6/7/13, Thomas Narten  wrote:
> Total of 146 messages in the last 7 days.
>
> script run at: Fri Jun  7 00:53:03 EDT 2013
>
> Messages   |  Bytes| Who
> +--++--+
>  10.27% |   15 |  9.96% |   125797 | abdussalambar...@gmail.com
>   4.11% |6 |  6.44% |81389 | adr...@olddog.co.uk
>   5.48% |8 |  3.76% |47556 | mo...@necom830.hpcl.titech.ac.jp
>   4.11% |6 |  4.30% |54259 | war...@kumari.net
>   3.42% |5 |  3.58% |45181 | john-i...@jck.com
>   3.42% |5 |  3.28% |41450 | l.w...@surrey.ac.uk
>   3.42% |5 |  3.16% |39894 | d...@dcrocker.net
>   3.42% |5 |  2.36% |29749 | ra...@psg.com
>   2.74% |4 |  2.53% |31911 | carlosm3...@gmail.com
>   2.74% |4 |  2.18% |27483 | arturo.ser...@gmail.com
>   1.37% |2 |  3.38% |42690 | ron.even@gmail.com
>   2.74% |4 |  1.86% |23539 | m...@mnot.net
>   1.37% |2 |  3.15% |39833 | simo.veikkolai...@nokia.com
>   2.05% |3 |  1.88% |23809 | scott.b...@gmail.com
>   2.05% |3 |  1.68% |21225 | s...@resistor.net
>   2.05% |3 |  1.62% |20488 | ted.le...@nominum.com
>   1.37% |2 |  2.29% |28971 | doug.mtv...@gmail.com
>   2.05% |3 |  1.54% |19411 | jmamo...@gmail.com
>   0.68% |1 |  2.80% |35397 | elw...@folly.org.uk
>   2.05% |3 |  1.37% |17285 | iab-ch...@iab.org
>   0.68% |1 |  2.66% |33542 | cb.li...@gmail.com
>   1.37% |2 |  1.73% |21883 | barryle...@computer.org
>   1.37% |2 |  1.64% |20761 | jcur...@istaff.org
>   1.37% |2 |  1.50% |18953 | brian.e.carpen...@gmail.com
>   1.37% |2 |  1.44% |18207 | ulr...@herberg.name
>   1.37% |2 |  1.37% |17302 | hartmans-i...@mit.edu
>   1.37% |2 |  1.35% |17078 | aeop...@gmail.com
>   1.37% |2 |  1.27% |16048 | m...@blackops.org
>   1.37% |2 |  1.10% |13834 | spencerdawkins.i...@gmail.com
>   1.37% |2 |  1.09% |13711 | chris.dearl...@baesystems.com
>   1.37% |2 |  1.06% |13376 | joe...@bogus.com
>   1.37% |2 |  0.94% |11882 | c...@tzi.org
>   1.37% |2 |  0.92% |11641 | to...@isi.edu
>   0.68% |1 |  1.60% |20151 | rjspa...@nostrum.com
>   1.37% |2 |  0.88% |11081 | jari.ar...@piuha.net
>   1.37% |2 |  0.87% |10956 | fg...@si6networks.com
>   0.68% |1 |  0.95% |12013 | ke-oog...@kddi.com
>   0.68% |1 |  0.88% |11066 | nar...@us.ibm.com
>   0.68% |1 |  0.73% | 9244 | og...@earthlink.net
>   0.68% |1 |  0.67% | 8504 | framefri...@gmail.com
>   0.68% |1 |  0.66% | 8340 | d3e...@gmail.com
>   0.68% |1 |  0.63% | 7996 | david.bl...@emc.com
>   0.68% |1 |  0.63% | 7948 | yb...@panix.com
>   0.68% |1 |  0.62% | 7882 | daedu...@btconnect.com
>   0.68% |1 |  0.61% | 7654 | i...@cdl.asgaard.org
>   0.68% |1 |  0.61% | 7651 | yi.ji...@gmail.com
>   0.68% |1 |  0.60% | 7579 | elw...@dial.pipex.com
>   0.68% |1 |  0.59% | 7486 | ma...@isc.org
>   0.68% |1 |  0.55% | 6960 | d...@cridland.net
>   0.68% |1 |  0.55% | 6886 | aman...@verisign.com
>   0.68% |1 |  0.53% | 6748 | rwfra...@gmail.com
>   0.68% |1 |  0.52% | 6615 | bmann...@isi.edu
>   0.68% |1 |  0.52% | 6609 | j...@mercury.lcs.mit.edu
>   0.68% |1 |  0.51% | 6418 | stephen.farr...@cs.tcd.ie
>   0.68% |1 |  0.50% | 6367 | do...@dougbarton.us
>   0.68% |1 |  0.50% | 6353 | p...@cypherpunks.ca
>   0.68% |1 |  0.50% | 6328 | f...@cisco.com
>   0.68% |1 |  0.49% | 6164 | p...@frobbit.se
>   0.68% |1 |  0.45% | 5654 | y...@checkpoint.com
>   0.68% |1 |  0.44% | 5502 | nscl...@gmx.de
>   0.68% |1 |  0.41% | 5235 | c...@a.org
>   0.68% |1 |  0.41% | 5212 | pe...@akayla.com
>   0.68% |1 |  0.40% | 5074 | wjh...@hardakers.net
> +--++--+
> 100.00% |  146 |100.00% |  1263211 | Total
>
>

Re: Last Call: (Use of OSPF-MDR in Single-Hop Broadcast Networks) to Experimental RFC

[Abdussalam Baryun]

Hi Richard,

I send to the author of an IETF document a message but it was not
answered. I beleive that the question from the community was ignored,
I hope you understand the importance of community questions. Why does
the IETF name its documents RFCs, any one from the community can ask
questions even after the RFC is produced, so we SHOULD NOT be stoped
to comment on any document and the IETF SHOULD try to answer
communities questions, otherwise IETF SHOULD NOT request comments.
comments below,

On 6/7/13, Richard Ogier  wrote:
> AB,
>
> As Joel pointed out, your questions should have been raised during the
> OSPF WG Last Call, which you did not participate in. You
> (inappropriately) posted questions on the MANET WG list after the OSPF
> WGLC was complete, and several people responded, most of them stating
> that RFC 5444 is not required for this document:

Please note that I got a message from IETF post or an AD post in MANET
WG, so I responded, and asked the author by their address (it was
appropriate/reasonable reaction). I may agree that I should send to
the origin WG, which I learn now, but only if that WG is open to
questions. I know I don't work in OPSF WG, but that does not mean any
one can stop me from commenting or asking questions outside that
blocked-WG. My questions were before the IETF last call (which is
enough).
>
> http://www.ietf.org/mail-archive/web/manet/current/msg15403.html
> http://www.ietf.org/mail-archive/web/manet/current/msg15406.html
> http://www.ietf.org/mail-archive/web/manet/current/msg15407.html
> http://www.ietf.org/mail-archive/web/manet/current/msg15408.html
>
> Although I should not be required to respond to your questions at this
> point,

I thought that within the IETF last call of the I-D, all the community
questions and comments are answered as long as the last call did not
end. Furthermore, the OPSF WG is blocking me (so no one unsubscribed
from the community can comment on the document) from sending my
thoughts yesterday even after I subscribed.

Thanks for your respond below,

AB
> I will provide a few additional reasons why RFC 5444 and DLEP are
> not relevant for this document. (These reasons also apply to the
> parallel document draft-ietf-ospf-manet-single-hop-or-02.)
>
> 1. This draft does not propose a new interface, it only describes how
> the interface previously specified in RFC 5614 (and RFC 5820 for the
> other draft) can be configured in the special case of a single-hop
> MANET. Therefore, your comments should have been directed to RFC 5614
> (and RFC 5820).
>
> 2. RFCs 5614 and 5820 describe MANET extensions to OSPF, and one of the
> goals was to minimize changes to OSPF, so we decided to use OSPF packet
> formats (with minimal changes), rather than MANET packet formats that
> were designed without OSPF in mind. (This point is also made in the last
> message listed above.)
>
> On the other hand, these are experimental documents, so your questions
> about using RFC 5444 and DLEP may be valid for future modifications to
> the proposed MANET extensions of OSPF (both RFCs 5614 and 5820). But
> they are not valid for draft-ietf-ospf-manet-single-hop-mdr or
> draft-ietf-ospf-manet-single-hop-or, not only because these two drafts
> have already completed WG Last Call, but also because they only describe
> how to configure RFCs 5614 and 5820 for the special case of a single-hop
> network.
>
> Richard
>
> On 6/6/13 3:15 AM, Abdussalam Baryun wrote:
>
>  > I send my request to the editors including questions but no reply from
>  > them to me. The thread [1] raised some issues, which is not mentioned
>  > in the I-D. The message [2] was ignored not answered (this is last
>  > reminder). The message [3] proposes using RFC5444 into this I-D, or
>  > raise the question of why not using MANET packet format within MANET
>  > domains (I need an answer).
>  >
>  > [1] http://www.ietf.org/mail-archive/web/manet/current/msg15400.html
>  > [2] http://www.ietf.org/mail-archive/web/manet/current/msg15412.html
>  > [3] http://www.ietf.org/mail-archive/web/manet/current/msg15418.html
>  >
>  > The I-D SHOULD not go forward if it still ignores the IETF community
> questions.
>  >
>  > Regards
>  > AB
>  >
>  > On 6/5/13, The IESG  wrote:
>  >> The IESG has received a request from the Open Shortest Path First
> IGP WG
>  >> (ospf) to consider the following document:
>  >> - 'Use of OSPF-MDR in Single-Hop Broadcast Networks'
>  >>  as Experimental 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 2013-06-19. 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
>  >>
>  >>
>  >> RFC 5614 (OSPF-MDR) extends OSPF to support mobile ad hoc networks
>  >> (MANETs) by specifying its operation on the new