RE: I-D Action: draft-crocker-id-adoption-02.txt

[Adrian Farrel]

Thanks Lloyd,

I doubt that we should make commentary on IRTF practices, but you are right that
it would help to clarify "This document applies to the IETF stream only (i.e.,
not the IAB, IRTF, or Independent streams)"

Thanks,
Adrian

> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> l.w...@surrey.ac.uk
> Sent: 03 June 2013 02:52
> To: brian.e.carpen...@gmail.com; ietf@ietf.org
> Subject: RE: I-D Action: draft-crocker-id-adoption-02.txt
> 
> I'd argue that the draft also needs to discuss IRTF processes, such as they
are.
> 
> though the IRTF groups are sufficiently similar to IETF WGs that you might
think
> the same processes apply, having a draft being adopted by an IRTF group means
> far less, for example, and there appear to be other differences.
> 
> At the very least, a 'this doesn't cover IRTF research groups, where practices
> very widely' is needed. 
> 
> Lloyd Wood
> http://sat-net.com/L.Wood/
> 
> 
> 
> From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Brian E
> Carpenter [brian.e.carpen...@gmail.com]
> Sent: 03 June 2013 00:27
> To: IETF discussion list
> Subject: Re: I-D Action: draft-crocker-id-adoption-02.txt
> 
> Hi,
> 
> My main positive comment is that it's a good idea to document guidelines
> in this area, and that (viewed as guidelines) I largely agree with
> the draft.
> 
> My main negative comment is that although the draft says it's not a
> formal process document, its language in many places belies that.
> For example:
> 
> > 2. Adoption Process
> >
> >
> > 2.1. Formal Steps
> >
> >
> >To adopt a new working group document, the chairs need to:
> 
> would be better phrased as:
> 
>  2. Adoption Guidelines
> 
>  2.1. Typical Steps
> 
> To adopt a new working group document, the chairs often:
> 
> I'd suggest a careful pass through the text, removing instances
> of words like "process", "formal" and "need", and emphasising words
> like "guideline" and "typical" and "might".
> 
> Now some minor comments:
> 
> >The convention for
> >identifying an I-D formally under the ownership of a working group is
> >by the inclusion of "ietf" in the second field of the I-D filename
> >and the working group name in the third field,
> 
> It's a useful convention but *not* a requirement afaik.
> 
> >Note
> >that from time to time a working group will form a design team to
> >produce the first version of a working group draft.
> 
> I think that's slightly wrong. A design team draft is *not*
> automatically a WG draft. I think this is more accurate:
> 
>Note
>that from time to time a working group will form a design team to
>produce the first version of a document that may be adopted as
>a working group draft.
> 
> That's an important difference - we've seen cases where design teams
> falsely believed that they had been delegated authority by the WG.
> 
> >  *  Is there strong working group support for the draft?
> 
> I think that's going a bit far. Actually a WG might adopt
> a draft because there is support for the *topic* but not for
> the details of the draft as it stands. Indeed, one objective of
> adopting a draft is so that the WG as a whole obtains control
> of the contents - so that they can change it.
> 
> >   *  What is the position of the working group chairs, concerning
> >  the draft?
> >
> > [[editor note: I am not sure this is relevant.  Indeed is
> > might be specifically not relevant.  /a]]
> 
> Actually I'd go the other way: the WG chairs' job at that point is to
> judge the WG's opinion of the draft, not their own opinion. (At least
> once, as a WG chair, I had to declare adoption of a draft to which
> both I and my co-chair were strongly opposed.)
> 
> > 5.1. Individual I-Ds Under WG Care
> ...
> 
> OK, but there are in fact four possible outcomes for such a draft
> 
> 1. As you describe;
> 2. The document proceeds as an individual submission to the IESG
>without continued WG discussion;
> 3. The document proceeds as an Independent Submission to the RFC Editor;
> 4. The document is abandoned.
> 
> Regards
>Brian

Re: [IETF] Issues in wider geographic participation

[Jari Arkko]

Randy, Warren,

>> One (IMO) good idea that was mentioned recently (sorry, I cannot
>> remember by whom, may have been Jim Martin) was for someone from the
>> IETF to present a short summary of interesting work at NOG meetings.
> 
> this has been done many times.  imiho, it has not stirred up much useful
> interaction unless the ietfer says something really st00pid.  then it
> gets amusing.

I have found that generic "this is happening" informational is usually not so 
interesting. Whereas discussion on specific topics has been far more 
interesting… sessions that talk about some IETF WG technology, operator's 
problems in that area, and someone's experience in deploying the stuff are very 
interesting IMO.

Jari

Re: [IETF] RE: Time in the Air

[Dick Franks]

On 31 May 2013 20:56, Carlos M. Martinez  wrote:

> You are right, Wellington is almost 7 degrees south of Montevideo,
> although I hope it's better served by airlines :D
>

also nearer the equator than most of Europe; a geographical fact of life
that has been conveniently ignored in the discussion thus far!
(with the conspicuous exception of Mark Nottingham's numerical attack on
the topic).

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

[Jiazi Yi]

Hi, 

I think it's OK to add an informative reference to draft-ietf-nhdp-olsrv2-sec, 
which serves as a pointer to the related work going on, and possible 
countermeasures to the threats. 

best

Jiazi

On Jun 3, 2013, at 07:35 , Ulrich Herberg  wrote:

> Hi Adrian,
> 
> I personally agree that adding an informational ref to 
> draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my 
> co-authors.
> 
> Thanks
> Ulrich
> 
> On Sunday, June 2, 2013, Adrian Farrel wrote:
> Hi Abdussalam,
> 
> I think it is a reasonable suggestion for this I-D to make a forward reference
> to draft-ietf-manet-nhdp-olsrv2-sec
> Although this work is clearly scoped to NHDP (RFC 6130) as currently 
> specified,
> it is worth an informational reference to note that there is work in progress
> that seeks to update NHDP to counter a number of security threats described in
> this document.
> 
> I do not think, however, that this I-D should attempt to describe the 
> situation
> with NHDP after the inclusion of protocol work that has not yet been 
> completed.
> Contrary to your suggestion, I think this I-D motivates updates to 6130 and it
> would be wrong to review this document in the context of changes being made to
> address this document.
> 
> Thanks,
> Adrian
> 
> > I think if we got an effort in IETF to update NHDP [RFC6130] as draft
> > [1] does, why this reviewed I-D of threats does not include [1] in its
> > references to be reviewed before reviewing this NHDP-threat I-D? I
> > suggest to include draft [1] in References section, IMHO, any updates
> > to RFC6130 should be considered by the community while reviewing this
> > I-D.
> >
> > [1] draft-ietf-manet-nhdp-olsrv2-sec-02
> 

Re: I-D Action: draft-crocker-id-adoption-02.txt

[Dave Crocker]

On 6/3/2013 1:27 AM, Brian E Carpenter wrote:

My main negative comment is that although the draft says it's not a
formal process document, its language in many places belies that.
For example:

...

I'd suggest a careful pass through the text, removing instances
of words like "process", "formal" and "need", and emphasising words
like "guideline" and "typical" and "might".


ack.



Now some minor comments:


The convention for
identifying an I-D formally under the ownership of a working group is
by the inclusion of "ietf" in the second field of the I-D filename
and the working group name in the third field,


It's a useful convention but *not* a requirement afaik.


Times change.  It's now a requirement:

   "If the document is accepted as a working
   group document, then it will have the draft-ietf- I-D
   filename and will be announced on the working group mailing list by
   the IETF Secretariat. "

--  http://www.ietf.org/ietf-ftp/1id-guidelines.txt



Note
that from time to time a working group will form a design team to
produce the first version of a working group draft.


I think that's slightly wrong. A design team draft is *not*
automatically a WG draft. I think this is more accurate:

Note
that from time to time a working group will form a design team to
produce the first version of a document that may be adopted as
a working group draft.

That's an important difference - we've seen cases where design teams
falsely believed that they had been delegated authority by the WG.


I think what I wrote doesn't mean what you took from it, but of course 
it's worth rewording, to avoid that possibility.


And to broaden its scope a bit, perhaps:

   Note that one way of formulating the first version of a working 
group draft is for the group to commission a design team, or even for 
the design team to self-organize and offer its output for working group 
consideration.




  *  Is there strong working group support for the draft?


I think that's going a bit far. Actually a WG might adopt
a draft because there is support for the *topic* but not for
the details of the draft as it stands. Indeed, one objective of
adopting a draft is so that the WG as a whole obtains control
of the contents - so that they can change it.


Yeah.  Wording is off.  Meant what you suggest, not literally what was 
written.  Will modify accordingly.




   *  What is the position of the working group chairs, concerning
  the draft?

 [[editor note: I am not sure this is relevant.  Indeed is
 might be specifically not relevant.  /a]]


Actually I'd go the other way: the WG chairs' job at that point is to
judge the WG's opinion of the draft, not their own opinion. (At least
once, as a WG chair, I had to declare adoption of a draft to which
both I and my co-chair were strongly opposed.)


moved to the next list, of stuff that's inappropriate...





5.1. Individual I-Ds Under WG Care

...

OK, but there are in fact four possible outcomes for such a draft

1. As you describe;
2. The document proceeds as an individual submission to the IESG
without continued WG discussion;
3. The document proceeds as an Independent Submission to the RFC Editor;
4. The document is abandoned.



mumble. yeah.

but i hope we don't spend too much energy on this topic, given how rare 
it is.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

RE: Time in the Air

[Dearlove, Christopher (UK)]

Lloyd Wood
> quiet time on a plane can be productive time.

Economy class or something better?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearl...@baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, 
Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

Re: Not Listening to the Ops Customer

[Noel Chiappa]

> From: "cb.list6" 

> the emergent complex dynamical system we call the internet ... which is
> almost completely zero compliant to the e2e principle. Not that e2e is
> the wrong principle, but ipv4 could not support it as of 10+ years ago.
> Hence, nearly every internet node is behind a stateful device
> ...
> Yet, corners of the ietf call this real world internet of middleboxes
> as broken. As some of it is broken, so you have things ... to bust
> through it. Mutation happens.
> That said, the teaching moment here is look back and realize the
> internet was not engineered, if was emerged.
> Given that the internet is not engineered ... how do we make it go
> fast, bigger, better given the few levers we have.

Exactly. The Internet is evolving, and can we push it in a better direction,
and if so, how?

In all of this, the bottom line, to me, is that we have to be aware of the
limits of our power. Mandating forklift replaces is just a non-starter. By
and large, new stuff has to interoperate to the maximum extent possible with
unmodified 'stuff'; an approach that don't require _any_ host modifications
is almost a sine qua non.

And it was long (and remains) a truism of system design that security can't
be added at the last stages - it has to be 'baked in' all the way through the
design process. The same is true, now, of deployment and interoperability.


I persist in thinking that those 32-bit names are continuing their evolution
into local-scope names, with translation at naming region boundaries. How can
we improve that - reduce the brittleness of the middleboxes you refer to, by
making their data more visible (and thus replicable, etc)?

And we still need global namespaces. DNS names are slowly becoming more key
(the Web now makes them a key namespace at the protocol level, not just the
content), but what else? At one point the IETF considered trying to craft a
new endpoint namespace (through the NSRG, if I have remembered the name
correctly), but I think in retrospect that's a non-starter - changing TCP
(which is what that would require) is not really an option (see point 1).

Within that 'deployable' envelope, I am now back to where I was almost 30
years ago, which is that _probably_ the thing to deploy is a new location
namespace, for use by the path-selection (since only _some_ routers have to
know about that). That's not a namespace the Internet has now, and so we'd be
less constrained in doing so, and it's one the Internet really needs.

Noel

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

[Abdussalam Baryun]

I would hope that IETF add my name in the acknowledgement section of the
I-D. I complained to AD about that my efforts in WGLC was not acknowledged
by editors even after my request, however, I did not stop reviewing (trying
not be discouraged) which I will complete on 6 June with the final
comments. Therefore, this message (can be added as a comment on the I-D) is
an objection to section 8 that ignores acknowledge input/review effort
related to the I-D.

AB


On Mon, Jun 3, 2013 at 6:35 AM, Ulrich Herberg  wrote:

> Hi Adrian,
>
> I personally agree that adding an informational ref to
> draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my
> co-authors.
>
> Thanks
> Ulrich
>
>
> On Sunday, June 2, 2013, Adrian Farrel wrote:
>
>> Hi Abdussalam,
>>
>> I think it is a reasonable suggestion for this I-D to make a forward
>> reference
>> to draft-ietf-manet-nhdp-olsrv2-sec
>> Although this work is clearly scoped to NHDP (RFC 6130) as currently
>> specified,
>> it is worth an informational reference to note that there is work in
>> progress
>> that seeks to update NHDP to counter a number of security threats
>> described in
>> this document.
>>
>> I do not think, however, that this I-D should attempt to describe the
>> situation
>> with NHDP after the inclusion of protocol work that has not yet been
>> completed.
>> Contrary to your suggestion, I think this I-D motivates updates to 6130
>> and it
>> would be wrong to review this document in the context of changes being
>> made to
>> address this document.
>>
>> Thanks,
>> Adrian
>>
>> > I think if we got an effort in IETF to update NHDP [RFC6130] as draft
>> > [1] does, why this reviewed I-D of threats does not include [1] in its
>> > references to be reviewed before reviewing this NHDP-threat I-D? I
>> > suggest to include draft [1] in References section, IMHO, any updates
>> > to RFC6130 should be considered by the community while reviewing this
>> > I-D.
>> >
>> > [1] draft-ietf-manet-nhdp-olsrv2-sec-02
>>
>>

RE: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05

[Roni Even]

Hi Simo,

For the PSTN case the document explain how to construct the m-line PSTN is
used based on the ccap using port 9. This is not specified for the ATM case.
So if it is not mentioned it should be clear that using  ccap for ATM is not
specified and need another document

Roni

 

From: simo.veikkolai...@nokia.com [mailto:simo.veikkolai...@nokia.com] 
Sent: 31 May, 2013 1:14 PM
To: ron.even@gmail.com;
draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org
Cc: ietf@ietf.org; gen-...@ietf.org
Subject: RE: Gen-ART LC review of
draft-ietf-mmusic-sdp-miscellaneous-caps-05

 

Hello Roni,

Please see my answer below prefixed with [SV].

 

From: ext Roni Even [mailto:ron.even@gmail.com] 
Sent: 29. toukokuuta 2013 21:13
To: draft-ietf-mmusic-sdp-miscellaneous-caps@tools.ietf.org
Cc: ietf@ietf.org; gen-...@ietf.org
Subject: Gen-ART LC review of draft-ietf-mmusic-sdp-miscellaneous-caps-05

 

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

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

Document: draft-ietf-mmusic-sdp-miscellaneous-caps-05

Reviewer: Roni Even

Review Date:2013-5-29

IETF LC End Date: 2013-6-4

IESG Telechat date: 

 

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

 

 

Major issues:

 

Minor issues:

1.   I can understand from the draft that when you have IP and PSTN
nettype it is requires that the ccap will be for the PSTN. What happens if
you want to have the ccap nettype as ATM to be used with IP in the c=

 

[SV] If either endpoint does not support ATM, the "c=" line with the ATM
address would not get used (either it is not offered, or the Answerer
removes that from the SDP configurations). In case both endpoints actually
support and want to use ATM as alternative to IP based bearer, the
conventions in RFC3108 would need to be followed when crafting the SDP
configurations. That said, I haven't taken a detailed look at RFC3108 to see
if the ATM based media can be negotiated using the SDP Capability
Negotiation framework and its current extensions.

 

Simo

 

Nits/editorial comments: