Re: Last Call: (Multicast Protocol for Low power and Lossy Networks (MPL)) to Proposed Standard

[Ralph Droms]

draft-ietf-roll-trickle-mcast-05 and draft-ietf-6man-multicast-scopes-00 are in 
conflict with each other.

From draft-ietf-roll-trickle-mcast-05:

   When
   used with MPL, Realm-Local scope is administratively defined and used
   to define the boundaries of multicast message dissemination by MPL.

From draft-ietf-6man-multicast-scopes-00:

   Realm-Local scope is the largest scope that is automatically
   configured, i.e., automatically derived from physical
   connectivity or other, non-multicast-related configuration.

Specifically, "administratively defined" seems to me to be in direct
conflict with "automatically configured". 

I suggest fixing the problem with two updates.  First, the definition
of "scop 3" in an IP-over-IEEE802.15.4 needs to be published, based on
this text from draft-ietf-6man-multicast-scopes-00: 

   The definition of any Realm-Local scope for a particular network
   technology should be published in an RFC.

I suggest:

   When used in an IP-over-IEEE802.15.4 network, "scop 3" is defined
   to include all interfaces sharing a PAN ID.

This text could be added to draft-ietf-roll-trickle-mcast-05, or to
draft-ietf-6man-multicast-scopes-00 or published separately in yet
another "world's shortest RFC".

Second, draft-ietf-roll-trickle-mcast-05 should be changed to read:

   When used with MPL, Realm-local scope is defined according to the
   underlying network technology; for example, [cite the
   IP-over-IEEE802.15.4 definition].

As a further refinement, I suggest text be added to
draft-ietf-roll-trickle-mcast-05 to the effect of:

   "scop 4" can also be used with MPL to cover deployments that use
   administratively defined scopes that cover, for example, subnets
   based on different underlying network technologies.

- Ralph

PS I originally posted about this issue to the rool WG mailing list:
http://www.ietf.org/mail-archive/web/roll/current/msg08188.html.
After a discussion with Kerry Lynn, I made a change to the definition
of scop 3 for IEEE802.15.4.

Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

[Ralph Droms]

On Oct 3, 2013, at 3:46 PM, Jaap Akkerhuis  wrote:

> 
>but the "To Subscribe" pointer is busted.
> 
> According to  the list is supposed
> to be .

mdns...@ietf.org was used for the two BoFs.  The WG will be dnssd, and the 
mailing list will be dn...@ietf.org (which, I air, is not what is shown in the 
charter header).

- Ralph

> 
>jaap
> ___
> mdnsext mailing list
> mdns...@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext

Re: NIST and NASA documents

[Ralph Droms]

On Oct 3, 2013, at 7:34 AM 10/3/13, Alexandru Petrescu 
 wrote:

> Le 03/10/2013 13:02, Dearlove, Christopher (UK) a écrit :
>> One draft I'm working on references some standard NIST cryptographic
>> documents. (RFCs don't include everything we need.)  I need to check
>> some details therein. Unfortunately the current US government
>> shutdown has taken NIST's website, including those documents,
>> offline. And (not considering this possibility) I didn't download
>> copies of them.
>> 
>> Any link to where copies of such documents are kept would be useful.
>> (Of course I haven't been able to check the copyright on them to
>> know if that's legal, so there may be no appropriate site.)
>> 
>> Otherwise, consider the above an observation.
>> 
> 
> Same here - I have problems accessing documents at NASA about IP network
> mobility.
> 
> The error message says:
> "Due to the lapse in federal government funding, this website is not
> available. We sincerely regret this inconvenience. For information about
> available government services, visit USA.gov."
> 
> (roland.grc.nasa.gov/ redirects to notice.usa.gov/)
> 
> Whereas I could find the document in Google's cache, I am dubious
> about this situation.
> 
> I would have not imagined that documents in a US gov website would
> become unavailable - for political reasons?  I would imagine engineering
> problems like routing system failures, Internet meltdown...

OK, so I'm not going to take a stand about the politics involved.  Trying to 
avoid wearing out my delete key, can we agree that the situation is a bummer, 
there's nothing we can do about it and we have a way to route around the 
damage.  Nothing more to contribute here, please move along...

Thanks and this will be my last post in this thread...

- Ralph

> 
> Alex
> 

Re: NIST documents

[Ralph Droms]

Try Wayback, http://archive.org

- Ralph

On Oct 3, 2013, at 7:02 AM 10/3/13, "Dearlove, Christopher (UK)" 
 wrote:

> One draft I'm working on references some standard NIST cryptographic 
> documents. (RFCs don't include everything we need.)  I need to check some 
> details therein. Unfortunately the current US government shutdown has taken 
> NIST's website, including those documents, offline. And (not considering this 
> possibility) I didn't download copies of them.
> 
> Any link to where copies of such documents are kept would be useful. (Of 
> course I haven't been able to check the copyright on them to know if that's 
> legal, so there may be no appropriate site.)
> 
> Otherwise, consider the above an observation.
> 
> -- 
> 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: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe

[Ralph Droms]

On Sep 16, 2013, at 9:20 AM 9/16/13, "Romascanu, Dan (Dan)" 
 wrote:

> Hi, 
> 
> I have doubts myself, doubts that I shared with the IESG that this question 
> is really needed. Asking this question at the end of the process after the 
> conformance with BCP 78 and BCP 79 was explicitly declared with each version 
> of the I-D submitted seems redundant.

On the other hand, I believe there have been cases in which asking this 
question resulted in disclosures that might not otherwise have been posted.

Redundancy in this case doesn't seem particularly costly or otherwise onerous 
and, in my opinion, has proved valuable in the past.

- Ralph

> It is probably intended to cover some corner cases where contributors forgot 
> particular disclosures, or disclosures happened after the last I-D revision 
> was submitted, or some of the authors on the authors list were not involved 
> directly in the latest submitted revisions of the I-D. As WG chair however, 
> as long as the question is formulated under its current format in the 
> shepherd write-up form, I feel that I cannot responsibly answer to it without 
> asking the authors.
> 
> To quote Gonzalo: Responding with a "yes, per the draft's boilerplate" should 
> take only a few seconds
> 
> Regards,
> 
> Dan
> 
>> -Original Message-
>> From: Gonzalo Camarillo [mailto:gonzalo.camari...@ericsson.com]
>> Sent: Monday, September 16, 2013 3:04 PM
>> To: Glen Zorn
>> Cc: Romascanu, Dan (Dan); Qin Wu; draft-ietf-xrblock-rtcp-xr-
>> qoe@tools.ietf.org; Shida Schubert; rai-...@tools.ietf.org; The
>> IESG; ietf@ietf.org
>> Subject: Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
>> 
>> Hi Glen,
>> 
>> as I mentioned in another email, that question is just a reminder. In
>> the past, it has happened that even long-time IETF participants with a
>> lot of experience had forgotten about a particular disclosure until they
>> received the reminder.
>> 
>> Responding with a "yes, per the draft's boilerplate" should take only a
>> few seconds of your time.
>> 
>> Cheers,
>> 
>> Gonzalo
>> 
>> On 16/09/2013 2:35 PM, Glen Zorn wrote:
>>> On 09/15/2013 11:06 PM, Romascanu, Dan (Dan) wrote:
 Hi,
 
 Qin is correct. Glen's way of responding does not help.
>>> 
>>> Apparently there is no way that would be helpful (see below).
>>> 
 
 The wording of this question is not a choice. As WG chairs we are
 required to answer the following question which is part of the
 Shepherd write-up as per the instructions from the IESG
 http://www.ietf.org/iesg/template/doc-writeup.txt:
 
> (7) Has each author confirmed that any and all appropriate IPR
 
 disclosures required for full conformance with the provisions of BCP
 78
 
 and BCP 79 have already been filed. If not, explain why.
 
 We have no choice but to relay the question to the authors.
>>> 
>>> I see, just following orders.
>>> 
 
 Glen, if you believe that this question should not be part of the
 write-up, I think that you should take the issue with the IESG.
>>> 
>>> I have, and am continuing to do so (see the CC list).
>>> 
 
 In the current situation, unless I receive different instructions
 from the ADs, I have no choice but to send this document to the IESG
 mentioning that I did not receive an explicit confirmation.
 
>>> 
>>> Really?  I have no idea, really, how to respond to that statement but
>>> I'll try anyway.  The explicit statement of conformance to both BCP 78
>>> and BCP 79 were clearly contained in each and every revision of the
>>> draft; of course, I know that you are a busy person, and the IESG is
>>> even busier, so you can't be expected to read every draft posted.  I
>>> spent my time emailing the pertinent sections of
>>> draft-ietf-xrblock-rtcp-xr-qoe-00 through
>>> draft-ietf-xrblock-rtcp-xr-qoe-09 to ensure that you were aware that I
>>> and my co-authors had explicitly stated that the drafts in question
>>> conformed to the relevant BCPs in every case.  As I'm quite certain
>>> that you can read, I believe that you _are_ aware of that, so how to
>>> understand your statement that "I have no choice but to send this
>>> document to the IESG mentioning that I did not receive an explicit
>>> confirmation"?  It looks like I have no choice but to believe that you
>>> (and the IESG) think that we are liars who will confess only under
>>> direct questioning, like 8-year-old children suspected of some prank.
>>> This isn't merely obnoxious, it's insulting and highly offensive.
>>> 
 
>>> 
 Regards,
 
 Dan
 
 
 
 
> -Original Message-
> From: Qin Wu [mailto:bill...@huawei.com]
> Sent: Saturday, September 14, 2013 8:45 AM
> To: Glen Zorn
> Cc: Romascanu, Dan (Dan); draft-ietf-xrblock-rtcp-xr-
> qoe@tools.ietf.org
> Subject: RE: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe
> 
> Hi,Glen:
> Would you like to not bother I

Re: 6tsch BoF

[Ralph Droms]

On Aug 1, 2013, at 3:30 PM, Andy Bierman  wrote:

> On Thu, Aug 1, 2013 at 4:24 AM, Yoav Nir  wrote:
>> 
>> On Aug 1, 2013, at 11:14 AM, Andy Bierman  wrote:
>> 
>>> Hi,
>>> 
>>> Isn't it obvious why humming is flawed and raising hands works?
>>> (Analog vs. digital).  A hand is either raised or it isn't.
>>> The sum of all hands raised is comparable across tests.
>>> The sum of the amplitude of all hums is not.
>> 
>> Hums are better as they give greater weight to people who are more vocally 
>> in support (or in opposition) to the assertion.
> 
> Please provide some evidence that a loud hum means the person is more
> committed to work on an item.
> 
> Favoring loud humming is subject to cultural bias.

As is identifying oneself with a position by raising one's hand.  I can imagine 
as much - my uninformed opinion would be more - cultural bias effect on a show 
of hands as on a hum.

> Some cultures are more inclined to raise their voice than others.
> Some people have naturally louder voices than others.
> Measuring volume may introduce bias in favor of loud men and against
> soft-spoken women, for example.

And a show of hands may introduce bias against women preferring anonymity.

- Ralph

> 
> This cultural bias is not compatible with increased inclusiveness.
> 
> 
> Andy
> 
>> Research shows([1]), that the one humming loudly for acceptance, will also 
>> volunteer to review and contribute code. The one humming loudly against is 
>> going to jump up to the mike in all future meetings and tell the group that 
>> they're doing the wrong thing. Those who hum softly will go back to reading 
>> their email.
>> 
>> Yoav
>> 
>> [1] citation needed
>> 

Re: 6tsch BoF

[Ralph Droms]

On Aug 1, 2013, at 11:14 AM 8/1/13, Andy Bierman  wrote:

> Hi,
> 
> Isn't it obvious why humming is flawed and raising hands works?
> (Analog vs. digital).  A hand is either raised or it isn't.
> The sum of all hands raised is comparable across tests.

The repeatable test gives *an* answer, but is not necessarily the answer that 
best reflects the sentiment of those answering the question.

A relatively imprecise thermometer that gives a reading close to the measured 
temperature is more useful than a digital thermometer that gives a precise but 
highly inaccurate reading.

- Ralph

> The sum of the amplitude of all hums is not.
> 
> 
> Andy
> 
> On Thu, Aug 1, 2013 at 1:50 AM, Ralph Droms  wrote:
>> 
>> I found the process in the 6tsch BoF (Tue 1520) for asking about taking on 
>> the work discussed in the BoF to be thought-provoking.
>> 
>> Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
>> that the IETF should address?"  First, the chairs asked for a hum.  From my 
>> vantage point (middle of the room), the hum was pretty close to equal, 
>> for/against.  I reviewed the audio 
>> (http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
>> starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
>> decided they needed more information than they could extract from the hum, 
>> so they asked for a show of hands.  From the audio record, there were "a 
>> lot" for (which matches my recollection) and "a handful" against (my memory 
>> is that no hands showed against).  There was a request to ask for a show of 
>> hands for "how many don't know".  The question was asked, and the record 
>> shows "a dozen".
>> 
>> So, there was apparently a complete change in the answer to the question 
>> based on humming versus voting.  There may also have been some effect from 
>> asking, after the fact, for a show of hands for "don't know".
>> 
>> I'm really curious about the results, which indicate that, at least in this 
>> case, the response to the question is heavily dependent on the on the mode 
>> used to obtain the answers to the question (which we all know is possible).  
>> In particular, the effect of humming versus show of hands was pretty 
>> obvious.  draft-resnick-on-consensus gives several reasons why humming is 
>> preferred over a show of hands.  From this example, it seems to me to be 
>> worth considering whether a more honest and accurate result is obtained 
>> through humming rather than a show of hands.
>> 
>> The other question raised in my mind is why the initial result from the hum, 
>> which did not have a consensus either way, was not sufficient.  "Roughly the 
>> same response" for/against the question would seem to me to be as valid a 
>> result as explicit consensus one way or the other, and the act of taking a 
>> show of hands to survey the appeared to treat the hum as irrelevant, rather 
>> than highly significant.
>> 
>> - Ralph
>> 

6tsch BoF

[Ralph Droms]

I found the process in the 6tsch BoF (Tue 1520) for asking about taking on the 
work discussed in the BoF to be thought-provoking.

Toward the end of the BoF, the chairs asked the question "1. Is this a topic 
that the IETF should address?"  First, the chairs asked for a hum.  From my 
vantage point (middle of the room), the hum was pretty close to equal, 
for/against.  I reviewed the audio 
(http://www.ietf.org/audio/ietf87/ietf87-bellevue-20130730-1520-pm2.mp3, 
starting about 1:22), and heard a slightly louder hum "for".  The BoF chairs 
decided they needed more information than they could extract from the hum, so 
they asked for a show of hands.  From the audio record, there were "a lot" for 
(which matches my recollection) and "a handful" against (my memory is that no 
hands showed against).  There was a request to ask for a show of hands for "how 
many don't know".  The question was asked, and the record shows "a dozen".

So, there was apparently a complete change in the answer to the question based 
on humming versus voting.  There may also have been some effect from asking, 
after the fact, for a show of hands for "don't know".

I'm really curious about the results, which indicate that, at least in this 
case, the response to the question is heavily dependent on the on the mode used 
to obtain the answers to the question (which we all know is possible).  In 
particular, the effect of humming versus show of hands was pretty obvious.  
draft-resnick-on-consensus gives several reasons why humming is preferred over 
a show of hands.  From this example, it seems to me to be worth considering 
whether a more honest and accurate result is obtained through humming rather 
than a show of hands.

The other question raised in my mind is why the initial result from the hum, 
which did not have a consensus either way, was not sufficient.  "Roughly the 
same response" for/against the question would seem to me to be as valid a 
result as explicit consensus one way or the other, and the act of taking a show 
of hands to survey the appeared to treat the hum as irrelevant, rather than 
highly significant. 

- Ralph

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

[Ralph Droms]

On May 16, 2013, at 5:58 PM 5/16/13, Keith Moore  
wrote:

> On 05/16/2013 04:46 PM, Yoav Nir wrote:
>> The time for asking whether the group has considered making this field fixed 
>> length instead of variable, or whether RFC 2119 language is used in an 
>> appropriate way, or whether the protocol is extensible enough is at IETF 
>> last call. 
> 
> Actually the time for asking these questions is long before IETF-wide Last 
> Call.  We need widespread review of proposals for standards-track documents 
> long before a WG thinks it's finished with those documents.   It's a gaping 
> hole in our process.

Hear, hear.

> 
> Fix that problem, and most of the conflicts between IESG and WGs that 
> surround DISCUSS votes will go away.

Well, you might be a little optimistic here, but I agree in theory.

> 
> Keith
> 

- Ralph

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

[Ralph Droms]

Dave - I hope you'll indulge my selective quoting as I have a couple of 
specific points to address.  My apologies if I end up quoting you out of 
context...

On May 16, 2013, at 12:23 PM 5/16/13, Dave Crocker  wrote:

> [...]
> 
> So here's a simple proposal that pays attention to AD workload and includes a 
> simple efficiency hack:
> 
> When the IETF Last Call is issued, wait a few days, to see whether any 
> serious issues are raised by the community.  The really serious ones usually 
> are raised quickly.  If there are none, it's pretty certain the document will 
> advance to an IESG vote.  That leaves 7-10 days of IETF Last Call for ADs to 
> get educated and ask questions, just like everyone else.
> 
> Jari has expressed the goal of having AD concerns be raised more publicly.  
> Moving AD review and comment to the IETF Last Call venue nicely accomplishes 
> this, too.

I just posted elsewhere a suggestion to move this review even earlier, to WG 
last call.  Accomplishes most of the same ends, while putting the discussion in 
front of the IETF participants who are, presumably, most invested in the 
resulting document.

> 
> 
> [...]
> In terms of quality assurance, the idea that we have a process that relies on 
> the sudden insight of a single AD, at the end of a many-month process, is 
> broken.  It's fine if that person sees something that everyone else has 
> missed until then, but that is quite different from designing a process that 
> is claimed to rely on it.

As you and I have discussed in person, I am 100% in agreement with this 
comment.  As much as I liked to think of myself, when I was an AD, as a 
rock-god Network Expert with complete and in-depth insight into every document 
I reviewed, I know the reality was that any problems I might have found were 
related to the old observation that "even a blind squirrel finds an acorn 
occasionally".
> 
> And of course, the reality is that we allow bad specs out the door all the 
> time; we just allow fewer of them than many/most other standards bodies...

You're such an optimist.

- Ralph

> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

[Ralph Droms]

On May 16, 2013, at 5:00 PM 5/16/13, "Fred Baker (fred)"  wrote:

> 
> On May 16, 2013, at 9:40 AM, Adrian Farrel  wrote:
> 
>> On the whole, I am told that if an AD weighs in with her comments during 
>> working
>> group last call, her fearsome personality may overwhelm some of the WG
>> participants and she may dominate the WG consensus.
> 
> There may be places where that happens, but I would be surprised if it 
> happened in my working group. I think it is fair to say that the AD (or an 
> IAB member, or someone who has recognized expertise on the topic) is likely 
> to be listened to more carefully than some others might. Heck, I'm careful 
> when I make a technical comment on a document in my working group, flagging 
> it with "" to ensure that it is seen as intended - a comment by a 
> competent practitioner of the art, not a process remark or an attempt to 
> trump some other view. Speaking personally, I would prefer to see those 
> comments in the WGLC, not IETF Last Call, if we can make that happen. For 
> example, I'd like to get directorate reviews done (gen-art, security 
> directorate, etc) in the timeframe of WGLC.

I think Fred is returning to an earlier theme here, when he asks for earlier 
review.

Perhaps, as has been already suggested in this thread, we should think about 
SIRSbis? 

First, from draft-carpenter-icar-sirs-01:

 The procedure described in this document is intended to
 solve, or palliate, a number of related problems that
 have been observed in the IETF process [PROBLEM]:

  *submission of documents to the IESG that
   still have significant problems (leading
   to delay)

  *failure to detect fundamental problems
   and Internet- wide issues at an early
   stage

 Particularly because of the second point, it is
 impossible to resolve these problems simply by
 giving additional responsibility to working groups
 themselves. An additional procedure is needed.

In my opinion, it's important to assign responsibility (and accountability) to 
all WGs for producing publication-ready documents.  I agree that some 
additional work is needed before WGs send documents to the IESG.  Perhaps we 
can accomplish these goals through reorganizing the work we are 

I suggest we might want to combine the need for more responsibility with the 
discussion of a new "really close to being ready" document state.  However, 
rather than a new document state, suppose we codify the expectation that a 
document that has passed WG last call is essentially ready-to-publish?  
Correspondingly, any significant problems found in a document after WG last 
call would be considered a serious defect.

   Discussion:  I realize that, elsewhere in this thread, it has been
   asserted (or at least implied), that WGs already have this responsibility
   and DISCUSSes on document are usually unnecessary.  In practice, while
   there may still be unnecessary DISCUSSes, my experience as AD was that
   most DISCUSSes were appropriate and each one referred to a problem that
   the WG had missed.

Let's get all the expert review possible - directorate, AD, cross-area - in the 
WG last call review.  What pops out *should* be ready for publication.  Any 
issues raised by these reviews in WG last call will be exposed to and can be 
discussed by the WG at large, rather than being buried in the noise of IETF 
last call discussions or being fixed in more focused discussions among the IESG 
and the document authors.  This procedure diverges some from 
draft-carpenter-icar-sirs-01, in that it doesn't add a new form of review 
process.  Instead, it reschedules reviews that were going to take place anyway 
earlier in the process, so there is little or no new work added to the document 
publication process.

Perhaps the WG chairs would want to assign document shepherds earlier in the 
process, as well, investing the document shepherds with the responsibility of 
getting the right reviews and advising the WG chairs as to the readiness of the 
document for advancement.

Any WGs willing to volunteer as experimental subjects?  There is really no new 
process to invent ... it's mostly a matter of realigning expectations and 
responsibilities out to 

- Ralph

Re: call for ideas: tail-heavy IETF process

[Ralph Droms]

On May 15, 2013, at 10:39 AM 5/15/13, Joe Touch  wrote:

> 
> 
> On 5/14/2013 9:54 PM, Keith Moore wrote:
>> Publishing broken or unclear documents is not progress.
>> 
>> Keith
> 
> Broken, agreed.
> 
> Unclear, nope - please review the NON-DISCUSS criteria, notably:
> 
> The motivation for a particular feature of a protocol is not clear enough. At 
> the IESG review stage, protocols should not be blocked because they provide 
> capabilities beyond what seems necessary to acquit their responsibilities.
> 
> The DISCUSS isn't there to make documents "better" - that's for COMMENTs. A 
> DISCUSS there to catch a set of problems and to *block* the document's 
> progress until that problem is resolved.

I'll agree with you *if* you consider an unclear description of a feature of a 
protocol, severe enough that reader of the specification are not able to build 
interoperable implementations, as a problem for which a DISCUSS can be posted.

In my opinion, there are many ways in which document can be unclear beyond the 
"motivation for a particular feature of a protocol is not clear enough."  

- Ralph

> 
> Joe

Re: call for ideas: tail-heavy IETF process

[Ralph Droms]

On May 3, 2013, at 8:59 AM 5/3/13, Thomas Narten  wrote:

> Just a few points...
> 
> Michael Richardson  writes:
> 
>> I'll repeat what has been said repeatedly in the newtrk and related
>> discussions.  The step from ID to "RFC" is too large because we are
>> essentially always aiming for "STD" rather than "PS".
> 
>> If we are unwilling to bring "RFC" back to a place were it does not
>> equal STD, then we need to create a new category of document which
>> amounts to "fully baked ID".  Things like IANA allocations could occur
>> at that point.
> 
>> In the days of dot-boom it was not unusual to see widespread
>> implementation very early in the ID process and even interop and
>> experimental deployment.   While this still occurs for quite a number of
>> things (and sometimes it's a problem that the ID can not be changed as a
>> result), there is an equal amount of "wait for the RFC to come out".
> 
> I suspect there is a bit of rose colored reminiscing of history.
> 
> The world has changed, significantly.
> 
> For example, there has been massive consolidation in industry. There
> simply are fewer entities doing implementations today. 15 years ago,
> it was common to see a half dozen or more implementations from
> different (often smaller) entities, even before a document got out of
> a WG. Nowadays, the cost of doing an implementation (for a company) is
> in some sense much higher, and business realities make companies
> *very* selective in what they implement and put into a product.

Adding a little detail - those implementations have to be prototypes, with the 
implementing entities willing to make changes in the code prior to shipping 
product. Once the code has been shipped to customers, there is a lot of 
resistance to making changes to the specification.  

> I suspect that the notion that if the IETF published documents more
> quickly industry would implement them more quickly/frequently is
> wishful thinking.
> 
> Michael Richardson  writes:
>> It's what Carsten said.
> 
>> 1) this idea is baked enough for cross-area review to make sense.
>> 2) the protocol is not going to change significantly, one could
>>   implement.
>> 3) any future changes need thus to take into account impact on
>>   existing implementations... BUT that doesn't mean that we can't
>>   change things.
> 
> Like it or not, 2 and 3 are contradictory. From an interoperability
> perspective, the difference between "not change significantly" and
> "change a lot" is irrelevant once you have deployments. Change (in the
> behavior or wire format) is change and breaks interoperability, no
> matter how big or small.

Right, so declaring a document a "fully baked ID" might have the perverse 
effect of freezing specifications at a point where there are still problems.

The key issues are the investment in an implementation, the cost of updating an 
implementation and, perhaps most importantly, the cost of making changes to 
code that has been shipped in products.

> 
> Hannes Tschofenig  writes:
> 
>> b) There is no interest to research where delay really happen.
> 
> I don't think that is true. Jari has pointed to his work. I think
> there is actually quite a lot of understanding of where the delays
> are. But fixing them is really really hard. Blaming the "tail end" or
> "the IESG" for the problems has always been the easy target. The
> reality (IMO) is that the place where improvements are needed is
> within the WG and on having authors be more responsive. But history
> suggests there are no easy fixes here.
> 
> Randy Bush  writes:
> 
>>> A basic question, then, is whether we think these absolute numbers and
>>> these proportions of time are reasonable and appropriate for the IETF
>>> to be/remain effective?
> 
>> seems pretty reasonable to me.  from personal experience, the iesg and
>> rfced add useful value.
> 
> +1

It would be interesting to understand the cost of that useful value, and 
whether the same useful value could be provided elsewhere at reduced cost.

"Cost" in this case can be tricky - the useful value in IESG review comes at 
the cost of asking the members of the IESG to invest 10s of hours per week in 
careful review of every document.  That time requirement contributes to the 
notion that being an AD is a full time job, which in return reduces the 
diversity of the pool of candidates willing to volunteer for an AD position.

So, there is useful value, but can we get that same value by distributing the 
load out to the larger community?

> 
> Like everyone, I wish things moved more quickly, but every attempt
> I've ever seen that tries to speed things up ends up reducing the
> quality or having some other undesirable side effect.
> 
> The bottom line is that getting a good spec requires iteration, and
> reviews from a broad set of parties. That is best done
> *sequentially*. And given the limited cycles the (volunteer) community
> as a whole has, you can't easily change these dynamics. We've seen
> many attempts t

Re: Language editing

[Ralph Droms]

On May 2, 2013, at 9:47 PM 5/2/13, Dave Crocker  wrote:

> On 5/2/2013 4:13 PM, Peter Saint-Andre wrote:
>> Instead of imposing even more work on the RFC Editor team, I suggest
>> that you find someone in the WG, in your company, in the IETF
>> community (etc.) to help with the language issues. I did this recently
>> with a document in one of the WGs where I'm active and it worked quite
>> well (especially if the document is under source control and you can
>> just send a patch).
> 
> 
> +1
> 
> This goes beyond the simple-but-expensive matter of having the work done by 
> the RFC Editor.
> 
> With every opportunity, we should move work to the people who want its result.

Dave, I agree with you and you make a very important point, that applies 
broadly to this conversation.

In particular, it should be the responsibility of the interested parties to 
engage community support, and it should be the responsibility of the community 
to put effort into producing a document that meets requirements of basic 
writing quality.

> 
> IETF work that is successful has community support.  The community wants it 
> and demonstrates this by working on it.  That can (and I think should) 
> include ensuring basic writing quality.

If you'll allow me to dive into process issues and solution engineering 
briefly, these writing quality issues should be caught well before the document 
reaches the IESG, in the abstract to ensure that the responsibility (and the 
work) in producing publishable documents rests with the people who want the 
document published, and pragmatically because a DISCUSS position of "returned 
for improvement in writing quality" is at the edge of what can be handled 
through routine processes.

> 
> If the community does not have enough interest in the work to write it well, 
> it has bigger problems that won't be remedied by more RFC Editor effort...

Yup.

> 
> d/

- Ralph

> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: call for ideas: tail-heavy IETF process

[Ralph Droms]

On May 1, 2013, at 5:00 PM 5/1/13, Scott Brim  wrote:

> A draft does get cross-area review, at least once, often more than once.
> Some drafts in some WGs get it earlier than others, by explicit
> invitation.  Others don't get it until the latest they can, when they go
> to last call ... but a process point for cross-area review during WG
> handling, already exists.  It's just optional.  I did like SIRS, and the
> equivalent of SIRS exists -- in the informal relationships that are all
> through the IETF.
> 
> You can make the option more explicit, you could even make it mandatory,
> but doing so won't speed up draft processing at all and will probably
> make it slower.  One of the IETF's problems is not the problem under
> discussion but unconscious assumptions about the standards process.
> People think of last call as near the end of the process.  It's time to
> abandon that outdated view and recognize that so-called "last" call is
> not as close to the end as it used to be, that it's a bit closer to the
> middle ... and that that's really okay.  Really.  Some other SDOs have
> their process structured that way.  Let's rename "last call" to
> something like "IETF review" and stop giving people the wrong
> expectations.  Review outside the WG is vital, can be done repeatedly,
> and must be done by the whole IETF at least once.

At the same time, we have to emphasize that "IETF review" means "a significant 
group of people have to look at this document really, really carefully to make 
sure it's right and report the results of their review".  It doesn't mean 
"well, it looks OK and the IESG is going to give a really, really careful 
review anyway so I don't need to worry about it".

Perhaps some of the directorate reviews ought to happen much earlier in the 
process?

> 
> Scott

- Ralph

> 
> 

Re: call for ideas: tail-heavy IETF process

[Ralph Droms]

On May 1, 2013, at 1:59 PM 5/1/13, Dave Crocker  wrote:

> 
> The blog nicely classes the problem as being too heavy-weight during final 
> stages.  The quick discussion thread seems focused on adding a moment at 
> which the draft specification is considered 'baked'.
> 
> I think that's still too late.

...and not useful unless the diverse review and changes to the document take 
place much earlier in the process to make sure the document is "baked."  
Declaring done doesn't make it so.

> 
> Certainly it could be useful, but it's still very late in the process.

As Jari wrote, we often bury the heavy tail of the process in a limited 
discussion among IESG and the document authors.

The tail is heavy in two different ways:

* significant review and modification takes place in IESG review, after the WG 
and the IETF have declared the document done
* the burden of the review, managing the discussion, making sure any changes 
fix the problem and don't break anything else often falls on the IESG and even 
a single AD

> 
> Specification development usually does -- and certainly ought to -- formulate 
> basic design ideas or approaches that motivate the details in a 
> specification.  A good specification will include discussion of this, and I 
> think the typical and most significant hashing and re-hashing that happens in 
> later stages is about the design issues.
> 
> While basic design revisions can happen at any time in a process, I'll 
> suggest that a specification effort should be asked to document its 
> interesting design choices early, and circulate /these/ for external review, 
> iterating later if basic choices are changed.
> 
> I suspect that an earlier exercise at summarizing functional goals and design 
> approaches and issues will have a number of benefits, beyond enabling earlier 
> external review.

Dave - excellent idea.  A summary that explains the "why" first, that promotes 
early cross-area review or otherwise expands the set of people that look at and 
understand the nature of the problem and the structure of the specification 
will allow for earlier review and lighter-weight correction of problems.

> 
> d/

- Ralph

> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: IETF Diversity Question on Berlin Registration?

[Ralph Droms]

On Apr 30, 2013, at 4:53 PM 4/30/13, David Meyer  wrote:

> 
> 
> On Tue, Apr 30, 2013 at 1:41 PM, Randy Bush  wrote:
> you don't need a weatherman to know which way the wind blows.
> -- bob dylan
> 
> we do not need measurements to know the ietf is embarrassingly
> non-diverse.  it is derived from and embedded in an embarrassingly
> non-diverse culture.
> 
> we need to do what we can to remedy this.  progress not perfection is
> our goal.
> 
> measurement may be useful to see if we are having effect and/or what
> things have effect (meeting locales, size of cookies, ...).
> 
> we should be asking the minorities and those struggling to particiate
> what we can do to help.
> 
> randy
> 
> Nicely said Randy. --dmm

Agreed - without consulting a weatherman, we've been having a discussion (among 
a rather un-diverse group of participants) about where we are, as opposed to 
asking the questions Randy suggests.

- Ralph

>  
> 

Re: recognition

[Ralph Droms]

On Mar 15, 2013, at 9:39 AM 3/15/13, Jari Arkko  wrote:

> I wanted to give recognition to someone. As Ralph Droms stepped down from the 
> IESG this week, he completed 24 continuous years of service in the leadership 
> of the IETF, with a dot on his badge. The last four years he has been one of 
> the INT ADs, and before that he chaired the DHC working group for 20 years 
> (!). Thank you Ralph for everything you have done! 
> 
> If you see Ralph in the hallway, please stop and thank him for his service 
> and contributions with DHCP and many, many other things.
> 
> The proceedings of the first meeting of the DHC WG are here: 
> http://www.ietf.org/proceedings/13.pdf (page 59).

Thank you, Jari.  It has been a privilege and a series of stimulating 
challenges to work in the IETF for all these years.  I've met and made many 
friends and worked with remarkable people accomplishing remarkable things.

I have every expectation to continue participating actively in the IETF ... way 
too much fun to stop now.

I happened to review the original dhc WG charter from IETF 13, and noticed this 
last line:

Estimated Timeframe for Completion: (to be determined)

- Ralph

> 
> Jari Arkko
> IETF Chair
> 

Re: Thoughts from a past experimental Nomcom selection for TSV Area Director

[Ralph Droms]

On Mar 14, 2013, at 8:08 AM, Eliot Lear  wrote:

> Dave,
> 
> Thank you for sharing your experiences in such an open way, and for your
> long and dedicated service to the Internet community.
> 
> Eliot

Unequivocally and enthusiastically +1

- Ralph

> 
> On 3/12/13 4:41 PM, David Harrington wrote:
>> Hi,
>> 
>> Many suggestions have been made about ways to resolve the issue of finding
>> suitable candidates for TSV Area Director, or adjusting the job to fit
>> available candidates.
>> 
>> In 2010, I started as TSV AD, after the Nomcom had serious trouble filling
>> the TSV AD spot. I was encouraged to put my name in as a candidate since I
>> had solid IETF experience, even though I had no experience with the TSV
>> area. Interviewing for the position really confirmed for me how little I
>> knew about transport, so I was very surprised when I was nominated. 
>> 
>> After two years in that specific role, I have some insights I would like to
>> impart to the Nomcom and the community, and especially to any candidates for
>> the role who have never served on IESG. I'll repeat some of what has already
>> been suggested, but I'll try to put these things together to help explain
>> some contextual relationships that exist.
>> 
>> I. the overall workload
>> 
>> I found IESG/AD work to be a fulltime position, as in 100%. My first year, I
>> worked anywhere from 60 to 90 hours per week. Of course, I had a lot of
>> remedial learning to do; honestly, technical on-the-job training for a whole
>> area while working to perform your IESG review work and other AD tasks is a
>> tremendous burden. You won't do this in 50% of a normal work week. My second
>> year, I cut back the number of hours to 50-60 hours a week and took some
>> vacation time, so I could have a life beyond IESG, and the quality of my
>> work and my queue management suffered seriously as a result. YMMV. My main
>> concern is that a candidate with no area background can fall behind quickly,
>> and possibly never catch up fully within a two-year term.
>> 
>> The workload has two parts - the IESG/steering/approval part, and the area
>> directing/managing part. I learned over time to split this generally by week
>> - one week IESG, the next week AD. Otherwise it becomes hard to prioritize
>> because it is very difficult to prioritize both (time-competing) parts
>> simultaneously, without favoring one or the other. The job requires you to
>> do both.
>> 
>> II. workload - IESG 
>> 
>> IESG work requires review of about 15 documents every two weeks; those
>> documents come from anywhere in the IETF. Many of those documents require
>> the reviewer to understand the normative references upon which the document
>> is built. Internet standardization is now quite mature, and much of the new
>> standards work is dependent on older standards. I came from the SEC area and
>> the NM side of the OPS area, and those can be somewhat isolated from TSV,
>> INT, RAI, and routing. If your background has been limited to working in one
>> or two areas, you may need to learn a LOT about the technical developments
>> and the existing standards in the other areas. If you have been an active
>> reviewer in one or more directorates, and/or have previous IESG experience,
>> that should help a lot, but I still found it a challenge even after
>> experience in multiple directorates; when you do a security review of a
>> congestion control document, you look for security issues, not congestion
>> control issues.
>> 
>> You'll need enough understanding of the TSV issues to be able to spot bad
>> transport-related decisions in documents coming from elsewhere in the IETF.
>> You (and your co-AD) are effectively the reviewer of last resort for TSV
>> issues. If you don't understand control loops, congestion control
>> techniques, etc., you will NEED to rely on your directorate for assistance
>> in this role.
>> 
>> If you pride yourself on the thoroughness of your reviews, as I did, get
>> over it; you won't have time for thorough reviews.
>> 
>> Some have commented on the "extra" stuff related to IESG work, such as
>> cross-SDO coordination, process tweaking, and so on. These definitely take
>> time, and they are important because that is part of the job. But other IESG
>> members can handle the bulk of this extra work while you're still learning
>> the area.
>> 
>> III. workload - AD
>> 
>> The AD for an area becomes the spokesman/shepherd for all documents coming
>> from their area. When you bring it to the IESG, you will be asked about the
>> quality of the document, the technical content, whether certain questions
>> were considered, what impact this might have to existing networks, how well
>> the document follows established guidelines for security, management,
>> operations, IANA assignments, XML usage, and so on. You should know those
>> guidelines exist and have already asked most of the relevant questions and
>> had them addressed before you put a document on the telechat agenda.

Re: Appointment of a Transport Area Director

[Ralph Droms]

On Mar 4, 2013, at 8:07 AM 3/4/13, "Eggert, Lars"  wrote:

> Hi,
> 
> On Mar 4, 2013, at 13:18, Eric Burger  wrote:
>> I will say it again - the IETF is organized by us.  Therefore, this 
>> situation is created by us.  We have the power to fix it.  We have to want 
>> to fix it.  Saying there is nothing we can do because this is the way it is 
>> is the same as saying we do not WANT to fix it.
> 
> what is "the fix"?

I think part of the fix is to consider more than just the IESG.  We need to 
take look at the work across the IETF that goes into producing our documents 
and see if we can redistribute or reduce that work to lessen the workload on 
ADs ... if the goal is, indeed, to reduce the time commitment on individual ADs.

> 
> The IETF is set up so that the top level leadership requires technical 
> expertise. It is not only a management job. This is a key differentiator to 
> other SDOs, and IMO it shows in the quality of the output we produce. The 
> reason the RFCs are typically of very good quality is that the same eyeballs 
> go over all documents before they go out.

But that model doesn't scale.  What about, for example, ensuring the quality in 
the documents as they come out of the WGs?, which distributes the work rather 
than concentrating it in IESG?

> This creates a level of uniformity that is otherwise difficult to achieve. 
> But it requires technical expertise on the top, and it requires a significant 
> investment of time.

Agreed.
> 
> I don't see how we can maintain the quality of our output if we turn the AD 
> position into a management job.
> Especially when technical expertise is delegated to bodies that rely on 
> volunteers. Don't get me wrong, the work done in the various directorates is 
> awesome, but it's often difficult to get them to apply a uniform measure when 
> reviewing, and it's also difficult to get them to stick to deadlines. They're 
> volunteers, after all. 
> 
> And, as Joel said earlier, unless we delegate the right to raise and clear 
> discusses to the directorates as well, the AD still needs to be able to 
> understand and defend a technical argument on behalf of a reviewer. If there 
> is a controversy, the time for that involvement dwarfs the time needed for 
> the initial review.

Sure, for any specific issue.  My personal experience is that I spend more time 
on the ordinary review processes than I do summing up the time on 
extra-ordinary technical arguments.

> 
> There is no easy fix. Well, maybe the WGs could stop wanting to publish so 
> many documents...
> 
> Lars  

- Ralph

Re: [ANCP] Last Call: (Applicability ofAccess Node Control Mechanism to PON based Broadband Networks)to Informational RFC

[Ralph Droms]

On Feb 8, 2013, at 4:07 PM 2/8/13, "GTW"  wrote:

> Ralph, for clarification ... is there more than the one IP disclosure at 
> http://datatracker.ietf.org/ipr/1734/  ?
> 
> 
> The term  "disclosures" lead me to believe there may be more than one

Good catch.  Typo on my part.  There is just the one disclosure.

- Ralph

> 
> George T. Willingmyre, P.E.
> President GTW Associates
> 
> -Original Message- From: Ralph Droms
> Sent: Friday, February 08, 2013 10:53 AM
> To: ietf@ietf.org
> Cc: a...@ietf.org
> Subject: Re: [ANCP] Last Call:  (Applicability ofAccess Node Control 
> Mechanism to PON based Broadband Networks)to Informational RFC
> 
> Note that this last call is a second last call, to gather comments on the 
> publication of the document considering the IPR disclosures that were 
> published late in the previous IETF last call.
> 
> - Ralph
> 
> On Feb 5, 2013, at 3:57 PM 2/5/13, The IESG  wrote:
> 
>> 
>> The IESG has received a request from the Access Node Control Protocol WG
>> (ancp) to consider the following document:
>> - 'Applicability of Access Node Control Mechanism to PON based Broadband
>>  Networks'
>>  as 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 2013-02-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
>> 
>> 
>>The purpose of this document is to provide applicability of the
>>Access Node Control mechanism to PON-based broadband access. The
>>need for an Access Node Control mechanism between a Network
>>Access Server (NAS) and an Access Node Complex (a combination of
>>Optical Line Termination (OLT) and Optical Network Termination
>>(ONT) elements) is described in a multi-service reference
>>architecture in order to perform QoS-related, service-related and
>>Subscriber-related operations. The Access Node Control mechanism
>>is also extended for interaction between components of the Access
>>Node Complex (OLT and ONT). The Access Node Control mechanism
>>will ensure that the transmission of information between the NAS
>>and Access Node Complex (ANX) and between the OLT and ONT within
>>an ANX does not need to go through distinct element managers but
>>rather uses a direct device-to-device communication and stays on
>>net. This allows for performing access link related operations
>>within those network elements to meet performance objectives.
>> 
>> 
>> 
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/
>> 
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/
>> 
>> 
>> The following IPR Declarations may be related to this I-D:
>> 
>>  http://datatracker.ietf.org/ipr/1734/
>> 
>> 
>> 
>> ___
>> ANCP mailing list
>> a...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ancp
> 

Re: [ANCP] Last Call: (Applicability of Access Node Control Mechanism to PON based Broadband Networks) to Informational RFC

[Ralph Droms]

Note that this last call is a second last call, to gather comments on the 
publication of the document considering the IPR disclosures that were published 
late in the previous IETF last call.

- Ralph

On Feb 5, 2013, at 3:57 PM 2/5/13, The IESG  wrote:

> 
> The IESG has received a request from the Access Node Control Protocol WG
> (ancp) to consider the following document:
> - 'Applicability of Access Node Control Mechanism to PON based Broadband
>   Networks'
>   as 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 2013-02-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
> 
> 
> The purpose of this document is to provide applicability of the
> Access Node Control mechanism to PON-based broadband access. The
> need for an Access Node Control mechanism between a Network
> Access Server (NAS) and an Access Node Complex (a combination of
> Optical Line Termination (OLT) and Optical Network Termination
> (ONT) elements) is described in a multi-service reference
> architecture in order to perform QoS-related, service-related and
> Subscriber-related operations. The Access Node Control mechanism
> is also extended for interaction between components of the Access
> Node Complex (OLT and ONT). The Access Node Control mechanism
> will ensure that the transmission of information between the NAS
> and Access Node Complex (ANX) and between the OLT and ONT within
> an ANX does not need to go through distinct element managers but
> rather uses a direct device-to-device communication and stays on
> net. This allows for performing access link related operations
> within those network elements to meet performance objectives.
> 
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/
> 
> 
> The following IPR Declarations may be related to this I-D:
> 
>   http://datatracker.ietf.org/ipr/1734/
> 
> 
> 
> ___
> ANCP mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ancp

Re: travel guide for the next IETF...

[Ralph Droms]

On Jan 4, 2013, at 2:55 AM 1/4/13, Ole Jacobsen  wrote:

> 
> You have been warned.
> 
> http://news.yahoo.com/video/request-ketchup-philly-cheesesteak-leads-001204299.html

I'm sorry - seeing the words "Philly cheesesteak" and "Subway" in the same 
title are such a non sequitor for this long-time Phillies, Eagles and Flyers 
fan that I couldn't bring myself to watch the video.

- Ralph

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

Re: NomCom: Call for Nominations - IAOC Mid-Term Vacancy

[Ralph Droms]

On Nov 20, 2012, at 10:43 AM 11/20/12, Suresh Krishnan wrote:

> Hi Eric,
> 
> On 11/20/2012 10:20 AM, Eric Gray wrote:
>> I think this is a point of confusion, anyway.
>> 
>> 
>> 
>> I thought the process was for the previous NomCom to be coopted to
>> address any
>> 
>> unexpected mid-term vacancies, rather than to add the burden to the current
>> 
>> NomCom.
> 
> The previous Nomcom stayed constituted until the Atlanta meeting. If the
> vacancy was announced before Atlanta, the previous Nomcom would have
> filled the position. Right now, there is only one constituted Nomcom and
> it has to fill the position.

Suresh has it right; from RFC 3777:

   The term of a nominating committee begins when its members are
   officially announced.  The term ends at the Third IETF (not three
   meetings), i.e., the IETF meeting after the next nominating
   committee's term begins.

- Ralph

> 
> Thanks
> Suresh
> 

Re: Just so I'm clear

[Ralph Droms]

I'm convinced the IAOC needs to be restored to full membership and I'm not 
convinced we need to bypass our existing recall process.  I would prefer that 
we exercise that process, but will accede to whatever process is judged to have 
consensus.

- Ralph

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

[Ralph Droms]

On Sep 11, 2012, at 6:54 AM, Eric Gray  wrote:

> I guess what you're saying is that "will" in this case is a statement of IEEE 
> RAC policy.

Yup ... Would s/will not/has adopted a policy not to/ clarify that part of the 
statement?

- Ralph

> 
> In that case, I understand your point...
> 
> -----Original Message-
> From: Ralph Droms [mailto:rdroms.i...@gmail.com] 
> Sent: Tuesday, September 11, 2012 6:43 AM
> To: Eric Gray
> Cc: Joe Touch; IETF Chair; IETF list discussion
> Subject: Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols
> Importance: High
> 
> 
> On Sep 11, 2012, at 6:30 AM 9/11/12, Eric Gray wrote:
> 
>> Ralph,
>> 
>>It cannot hurt to try to make this as unambiguous as possible.
>> 
>>The IETF cannot instruct the IEEE RAC not to assign an Ethertype to 
>> anyone who applies for it, assuming they otherwise comply with RAC 
>> requirements and are willing to pay for the assignment, if necessary.
> 
> Eric - As I understand the IESG statement, the intent is not to give any 
> instructions to the IEEE RAC.  I read the text I quoted in my e-mail:
> 
>  the IEEE RAC will not assign a new Ethertype to
>  a new IETF protocol specification that needs one until the IESG has
>  approved the protocol specification for publication as an RFC.
> 
> as a restatement of the IEEE RAC policy, which was included in the IESG 
> statement as explanation for this text:
> 
>  To let the IEEE RAC know that the IESG has approved an IETF protocol
>  specification for publication, all future requests for assignment of
>  Ethertypes for IETF protocol specifications will be made by the IESG.
> 
> which describes how the IESG will inform the IEEE RAC about which protocol 
> specifications meet the IEEE RAC policy.
> 
> - Ralph
> 
> 
>> 
>>However, the IETF can caution the RAC that any such assignment can 
>> only be (or
>> become) associated with an IETF protocol specification upon its 
>> approval and publication as an IETF RFC.
> 
> 
>> 
>> --
>> Eric
>> 
>> -Original Message-
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf 
>> Of Ralph Droms
>> Sent: Friday, September 07, 2012 12:15 PM
>> To: Joe Touch
>> Cc: IETF Chair; IETF list discussion
>> Subject: Re: Draft IESG Statement on Ethertype Assignments for IETF 
>> Protocols
>> 
>> 
>> On Sep 7, 2012, at 10:51 AM 9/7/12, Joe Touch wrote:
>> 
>>> Hi, all,
>>> 
>>> This statement seems fine, but it's worth noting that it would apply only 
>>> to  *IETF* protocol specs.
>> 
>> What did you have in mind as "noting"?  This text seems pretty clear to me 
>> as applying only to "IETF protocol specifications": 
>> 
>> the IEEE RAC will not assign a new Ethertype to  a new IETF protocol 
>> specification that needs one until the IESG has  approved the protocol 
>> specification for publication as an RFC.
>> 
>> 
>> 
>>> The IESG has, IMO, no authority to make such claims for independent 
>>> submissions (and what about IRTF ones?), and the IEEE should recognize that 
>>> such protocols are described by RFCs too.
>> 
>> Where do you see any such claims in this statement?  What would you change?
>> 
>> - Ralph
>> 
>>> 
>>> Joe
>>> 
>>> On 9/3/2012 5:02 PM, IETF Chair wrote:
>>>> The IESG is considering this IESG Statement.  Comments from the community 
>>>> are solicited.
>>>> 
>>>> On behalf of the IESG,
>>>> Russ
>>>> 
>>>> --- DRAFT IESG STATEMENT ---
>>>> 
>>>> Subject: Ethertype Assignments for IETF Protocols
>>>> 
>>>> The IEEE Registration Authority Committee (RAC) assigns Ethertypes.
>>>> (See http://standards.ieee.org/develop/regauth/ethertype/.)  Some 
>>>> IETF protocol specification make use of Ethertypes.  Since 
>>>> Ethertypes are a fairly scarce resource, the IEEE RAC will not 
>>>> assign a new Ethertype to a new IETF protocol specification that 
>>>> needs one until the IESG has approved the protocol specification for 
>>>> publication as an RFC.
>>>> 
>>>> To let the IEEE RAC know that the IESG has approved an IETF protocol 
>>>> specification for publication, all future requests for assignment of 
>>>> Ethertypes for IETF protocol specifications will be made by the IESG.
>>>> 
>>>> Note that playpen Ethertypes have been assigned in IEEE 802 [1] for 
>>>> use during development and experimentation.
>>>> 
>>>> 
>>>> [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
>>>>  IEEE standard for Local and Metropolitan Area Networks:
>>>>  Overview and Architecture -- Amendment 1: Ethertypes for
>>>>  Prototype and Vendor-Specific Protocol Development.
>>>> 
>>>> 
>> 
> 

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

[Ralph Droms]

On Sep 11, 2012, at 6:30 AM 9/11/12, Eric Gray wrote:

> Ralph,
> 
>   It cannot hurt to try to make this as unambiguous as possible.
> 
>   The IETF cannot instruct the IEEE RAC not to assign an Ethertype to 
> anyone who
> applies for it, assuming they otherwise comply with RAC requirements and are 
> willing to
> pay for the assignment, if necessary.  

Eric - As I understand the IESG statement, the intent is not to give any 
instructions to the IEEE RAC.  I read the text I quoted in my e-mail:

  the IEEE RAC will not assign a new Ethertype to
  a new IETF protocol specification that needs one until the IESG has
  approved the protocol specification for publication as an RFC.

as a restatement of the IEEE RAC policy, which was included in the IESG 
statement as explanation for this text:

  To let the IEEE RAC know that the IESG has approved an IETF protocol 
  specification for publication, all future requests for assignment of 
  Ethertypes for IETF protocol specifications will be made by the IESG.

which describes how the IESG will inform the IEEE RAC about which protocol 
specifications meet the IEEE RAC policy.

- Ralph


> 
>   However, the IETF can caution the RAC that any such assignment can only 
> be (or 
> become) associated with an IETF protocol specification upon its approval and 
> publication 
> as an IETF RFC.


> 
> --
> Eric
> 
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ralph 
> Droms
> Sent: Friday, September 07, 2012 12:15 PM
> To: Joe Touch
> Cc: IETF Chair; IETF list discussion
> Subject: Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols
> 
> 
> On Sep 7, 2012, at 10:51 AM 9/7/12, Joe Touch wrote:
> 
>> Hi, all,
>> 
>> This statement seems fine, but it's worth noting that it would apply only to 
>>  *IETF* protocol specs.
> 
> What did you have in mind as "noting"?  This text seems pretty clear to me as 
> applying only to "IETF protocol specifications": 
> 
>  the IEEE RAC will not assign a new Ethertype to
>  a new IETF protocol specification that needs one until the IESG has
>  approved the protocol specification for publication as an RFC.
> 
> 
> 
>> The IESG has, IMO, no authority to make such claims for independent 
>> submissions (and what about IRTF ones?), and the IEEE should recognize that 
>> such protocols are described by RFCs too.
> 
> Where do you see any such claims in this statement?  What would you change?
> 
> - Ralph
> 
>> 
>> Joe
>> 
>> On 9/3/2012 5:02 PM, IETF Chair wrote:
>>> The IESG is considering this IESG Statement.  Comments from the community 
>>> are solicited.
>>> 
>>> On behalf of the IESG,
>>> Russ
>>> 
>>> --- DRAFT IESG STATEMENT ---
>>> 
>>> Subject: Ethertype Assignments for IETF Protocols
>>> 
>>> The IEEE Registration Authority Committee (RAC) assigns Ethertypes.
>>> (See http://standards.ieee.org/develop/regauth/ethertype/.)  Some 
>>> IETF protocol specification make use of Ethertypes.  Since Ethertypes 
>>> are a fairly scarce resource, the IEEE RAC will not assign a new 
>>> Ethertype to a new IETF protocol specification that needs one until 
>>> the IESG has approved the protocol specification for publication as an RFC.
>>> 
>>> To let the IEEE RAC know that the IESG has approved an IETF protocol 
>>> specification for publication, all future requests for assignment of 
>>> Ethertypes for IETF protocol specifications will be made by the IESG.
>>> 
>>> Note that playpen Ethertypes have been assigned in IEEE 802 [1] for 
>>> use during development and experimentation.
>>> 
>>> 
>>> [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
>>>   IEEE standard for Local and Metropolitan Area Networks:
>>>   Overview and Architecture -- Amendment 1: Ethertypes for
>>>   Prototype and Vendor-Specific Protocol Development.
>>> 
>>> 
> 

Re: Draft IESG Statement on Ethertype Assignments for IETF Protocols

[Ralph Droms]

On Sep 7, 2012, at 10:51 AM 9/7/12, Joe Touch wrote:

> Hi, all,
> 
> This statement seems fine, but it's worth noting that it would apply only to  
> *IETF* protocol specs.

What did you have in mind as "noting"?  This text seems pretty clear to me as 
applying only to "IETF protocol specifications": 

  the IEEE RAC will not assign a new Ethertype to
  a new IETF protocol specification that needs one until the IESG has
  approved the protocol specification for publication as an RFC.



> The IESG has, IMO, no authority to make such claims for independent 
> submissions (and what about IRTF ones?), and the IEEE should recognize that 
> such protocols are described by RFCs too.

Where do you see any such claims in this statement?  What would you change?

- Ralph

> 
> Joe
> 
> On 9/3/2012 5:02 PM, IETF Chair wrote:
>> The IESG is considering this IESG Statement.  Comments from the community 
>> are solicited.
>> 
>> On behalf of the IESG,
>> Russ
>> 
>> --- DRAFT IESG STATEMENT ---
>> 
>> Subject: Ethertype Assignments for IETF Protocols
>> 
>> The IEEE Registration Authority Committee (RAC) assigns Ethertypes.
>> (See http://standards.ieee.org/develop/regauth/ethertype/.)  Some IETF
>> protocol specification make use of Ethertypes.  Since Ethertypes are a
>> fairly scarce resource, the IEEE RAC will not assign a new Ethertype to
>> a new IETF protocol specification that needs one until the IESG has
>> approved the protocol specification for publication as an RFC.
>> 
>> To let the IEEE RAC know that the IESG has approved an IETF protocol
>> specification for publication, all future requests for assignment of
>> Ethertypes for IETF protocol specifications will be made by the IESG.
>> 
>> Note that playpen Ethertypes have been assigned in IEEE 802 [1] for use
>> during development and experimentation.
>> 
>> 
>> [1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001).
>>IEEE standard for Local and Metropolitan Area Networks:
>>Overview and Architecture -- Amendment 1: Ethertypes for
>>Prototype and Vendor-Specific Protocol Development.
>> 
>> 

Re: [IAB] Draft Fees for Processing Legal Requests Policy

[Ralph Droms]

On Aug 2, 2012, at 11:07 AM 8/2/12, Eggert, Lars wrote:

> Looks good to me, but I agree with whoever suggested to increase the fees. I 
> think you could easily double or triple them.

I agree with Lars and the suggestion that the fees could be higher.

- Ralph

> 
> On Aug 2, 2012, at 9:47, IETF Administrative Director  wrote:
> 
>> A reminder of the deadline of 6 August for input.
>> Thanks
>> 
>> The IAOC is seeking community feedback on a proposed policy by the IAOC to 
>> impose 
>> fees to produce information and authenticate documents in response to 
>> subpoenas and 
>> other legal requests.
>> 
>> The IETF receives requests for information, documentation, authentication or 
>> other 
>> matters through subpoenas and less formal means that require manpower and 
>> materials 
>> to be expended.  These requests are on the rise. During the period 2005 to 
>> 2010 the IETF 
>> responded to nine subpoenas.  Since 2011 the IETF has received five 
>> subpoenas and three 
>> other legal requests for authenticated documents.  
>> 
>> Each such request is time sensitive and involves the IETF Counsel, the IAD, 
>> and members 
>> of the IAOC, who together form the Legal Management Committee, to rapidly 
>> analyze and 
>> identify the means for satisfying the request.  Often there is a need to 
>> retain outside counsel, 
>> especially in cases that might lead to depositions or court testimony. 
>> 
>> The IAOC believes a Schedule of Fees is an appropriate and reasonable means 
>> to recover 
>> costs associated with such efforts.
>> 
>> The draft policy entitled Draft Fee Policy for Legal Requests can be found 
>> at: 
>> 
>> Before adopting a policy the IAOC would like feedback on this before making 
>> a 
>> decision.  Comments appreciated to ietf@ietf.org by 6 August 2012.
>> 
>> Ray Pelletier
>> IETF Administrative Director
> 

Re: RFC 2119 terms, ALL CAPS vs lower case

[Ralph Droms]

On May 18, 2012, at 2:40 PM 5/18/12, Randy Bush wrote:

>> Dave Crocker's suggestion would minimize the number of words taken out
>> of our vocabulary:
> 
> for a language other than english.
> 
>> In addition to "clear and concise" we need precision and avoidance of
>> ambiguity.
> 
> wonderful rofl.  thanks.  mind if i put that in my public quotes file?

Always happy to entertain, even if unintentionally...

- Ralph

> 
> randy

Re: RFC 2119 terms, ALL CAPS vs lower case

[Ralph Droms]

On May 18, 2012, at 2:27 PM 5/18/12, Randy Bush wrote:

>> I recommend an errata to RFC 2119: "These words MUST NOT appear in a
>> document in lower case."
> 
> first, that is not an erratum, it is a non-trivial semantic change.

You are correct and point taken.  

> 
> second, do we not already have enough problems being clear and concise
> without removing common words from our language?

Dave Crocker's suggestion would minimize the number of words taken out of our 
vocabulary:

> I'd be inclined to change 2119 to reserve only Must, Should and May, 
> independent of case and for no other use, and release the other terms.


In addition to "clear and concise" we need precision and avoidance of ambiguity.

- Ralph


> 
> randy

Re: RFC 2119 terms, ALL CAPS vs lower case

[Ralph Droms]

On May 16, 2012, at 10:22 PM 5/16/12, Ned Freed wrote:

> 
>> On May 16, 2012, at 5:22 PM 5/16/12, ned+i...@mauve.mrochek.com wrote:
> 
>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119] when they
>  appear in ALL CAPS.  These words may also appear in this document in
>  lower case as plain English words, absent their normative meanings.
>>> 
 i like this a lot
>>> 
>>> I agree. In fact I just incorporated it into the media types registration
>>> update.
> 
>> To be sure of meaning and help confusion avoidance, I would prefer that the
>> key words not appear in the document in lower case and that authors use the
>> suggested replacement words (or break out the thesaurus?).
> 
> Preferring it is one thing; I'm OK with that. Making it some sort of
> hard-and-fast rule is another matter entirely. We have too many of those
> as it is.

Well, here's another example of imprecision in the written word.  What I meant 
is that my preference would be a requirement that RFC 2119 key words not appear 
in lower case at all.

Seems to me that precision of meaning overrides graceful use of the language.  
Making the requirement something like "RFC 2119 key words SHOULD NOT appear in 
lower case unless the lower case usage is clearly non-normative" means we have 
to think a lot harder about some details and (AD hat and reading glasses firmly 
in place) we have enough details to think about already.  So, I recommend an 
errata to RFC 2119: "These words MUST NOT appear in a document in lower case."

- Ralph

> 
>   Ned

Re: RFC 2119 terms, ALL CAPS vs lower case

[Ralph Droms]

On May 16, 2012, at 5:22 PM 5/16/12, ned+i...@mauve.mrochek.com wrote:

>>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>>   document are to be interpreted as described in [RFC2119] when they
>>>   appear in ALL CAPS.  These words may also appear in this document in
>>>   lower case as plain English words, absent their normative meanings.
> 
>> i like this a lot
> 
> I agree. In fact I just incorporated it into the media types registration
> update.

To be sure of meaning and help confusion avoidance, I would prefer that the key 
words not appear in the document in lower case and that authors use the 
suggested replacement words (or break out the thesaurus?).

- Ralph

> 
>   Ned

Re: TSVDIR review of draft-ietf-dhc-dhcpv4-bulk-leasequery

[Ralph Droms]

Joe, Kim...

On Feb 17, 2012, at 5:47 PM 2/17/12, Joe Touch wrote:

> Hi, Kim,
> 
> First, thank you for your detailed response to my quite lengthy review.
> 
> Some further clarifications and confirmations appear below.
> 
> Joe
> 
> On 2/17/2012 12:09 PM, Kim Kinnear wrote:
>> 
>> Joe,
>> 
>> Thank you for your review.
>> 
>> My responses are indented, below...
>> 
>> On Feb 13, 2012, at 5:00 PM, Joe Touch wrote:
>> 
>>> Hi, all,
>>> 
>> > I've reviewed this document as part of the transport area
>>> directorate's ongoing effort to review key IETF documents. These
>>> comments were written primarily for the transport area directors,
>>> but are copied to the document's authors for their information and
>>> to allow them to address any issues raised. The authors should
>>> consider this review together with any other last-call comments
>>> they receive. Please always CC tsv-...@ietf.org if you reply to or
>>> forward this review.
>>> 
>>> This request was received Feb. 2, 2012.
>>> 
>>> This document describes an extension to DHCPv4 for the bulk query
>>> andtransfer of current lease status over TCP.
>>> 
>>> The following transport issues were noted, and are significant:
>>> 
>>> UPDATES- The document updates DHCP with support for TCP, and as
>>> suchthis document seems like it should UPDATE RFC2131
>> 
>>  While this document clearly builds on RFC 2131, it
>>  doesn't actually change anything that anyone is doing
>>  that is currently based on RFC 2131.  My understanding of
>>  "updates" is that, in order to understand the first RFC
>>  (in this case, RFC 2131), you need to read all of the
>>  RFC's that "update" it.  That isn't the case here -- you
>>  can be very happy reading and implementing DHCPv4 by
>>  reading RFC 2131 and never have to know that DHCPv4 Bulk
>>  Leasequery exists.  In general, in the DHC WG, we seem to
>>  set a pretty high bar for what "udpates" another RFC.  I
>>  don't see that this document has met those requirements.
>>  But this isn't really my call.  I'll let Ralph Droms and
>>  the DHC WG chairs decide on this one, and I'll do
>>  whatever they tell me to do.
> 
> Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as per RFC 
> 2131 is changed by this doc. If DHCP fundamentally starts requiring TCP port 
> support, then this doc then changes the spec as described in 2131 IMO.

Joe - I don't see that this document fundamentally requires TCP port support 
for DHCP operation as described in RFC 2131.  This document describes a 
protocol that is closely related to but independent of RFC 2131, and a server 
based on RFC 2131 can perform all the DHCP functions in RFC 2131 without 
considering this document.  So, I can see your point but I disagree that this 
document updates RFC 2131.

> Here are the reasons I think it DOES modify DHCP:
> 
>   - Sec 10 requests option codes that extend the tables defined
>   in the original RFC
> 
> I couldn't locate a recommendation on whether DHCP servers MAY implement this 
> extension, SHOULD, or MUST (did I miss it? if not, it should be added). 
> Regardless, that too would be a reason for this as an update to 2131. It's 
> only NOT an update if this service is independent, IMO, and it doesn't read 
> that way to me.

There are other RFCs that add new, independent functions to DHCP without making 
changes to RFC 2131 (e.g., RFC 4388), which are not listed as updating RFC 2131.

- Ralph
> 

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

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Ralph Droms]

On Feb 11, 2012, at 12:27 AM 2/11/12, Doug Barton wrote:

> On 02/10/2012 20:44, Noel Chiappa wrote:
>>> From: Doug Barton 
>> 
>>> You snipped the bit of the my post that you're responding to where I
>>> specifically disallowed this as a reasonable argument.
>> 
>> What an easy way to win a debate: 'I hereby disallow the following
>> counter-arguments {A, B, C}, and since you have no other
>> counter-arguments, I win.'
>> 
>> Just because you don't think much of it, doesn't mean the rest of us have
>> to agree with you on that.
> 
> I understand that. Do you understand that I understand what you're
> saying, and I don't agree with you?
> 
>> 
>>> The new block's purpose is to make collisions impossible.
>> 
>> Ah, no.
>> 
>> If you were to say 'to make collisions very unlikely if it is used in the
>> way it is specified', then I could agree with that.
> 
> Ok, let's go with that. We already have a way to make collisions "very
> unlikely," don't use either of 192.168.[01]. Fortunately this method
> doesn't require allocation of a new block.

But, what we've been told by operators in the discussion about this draft is 
that "very unlikely" is not "sufficiently unlikely", and that no /10 within the 
set of RFC 1918 addresses makes the probability of a collision sufficiently 
unlikely.  You may disagree with that claim, but I think we have to respect it.

> So now what we're talking about is how much we're willing to pay to make
> the collisions how much more unlikely?

I would certainly feel more comfortable with better data, but it seems highly 
unlikely that we can generate it.

- Ralph

> 
>> But to take a
>> straw-man absolutist position like "impossible", and then knock it down
>> with great pomp:
>> 
>>> It cannot fulfill that purpose.
> 
> I was using shorthand (or argumentum ad absurdum if you prefer) to point
> out that given the fact that this new block can't fix the whole problem,
> and also given the fact that there are already solutions available that
> fix most of the problem for free, allocating the new block is a bad idea.
> 
>>> it's a very irresponsible way for an SDO to conduct themselves.
>> 
>> What, to say 'if you use this in a way that we specifically direct it not
>> be used, any problems are your fault'?
> 
> Again, you snipped the bit where I answered this. Go back and re-read my
> previous post if you're confused.
> 
>>> And that's assuming that this action doesn't have a cost, whereas
>>> the truth is that it has several, both direct and indirect.
>> 
>> And that would be...? How exactly does simply allocating a chunk of
>> address space - something the Internet engineering community does every
>> day - for a specific purpose "have a cost ... both direct and indirect"?
> 
> Again, I'm really trying not to dive back into the "should we" question,
> but just as an example, there are 4,096 /22s in a /10. That's 4k new
> SMBs that cannot get IPv4 space if this block is allocated.
> 
> If you want more, go look at the archives.
> 
>> If you're actually thinking of 'deploying CGNAT' in the text above, this
>> discussion is not about that. That's going to happen no matter what the
>> IETF says/does.
> 
> Yep, I get that.
> 
>> (Just like all those other NAT boxes the IETF huffed and
>> puffed until it turned blue in the face about.)
> 
> FWIW I always said that the IETF sticking its collective fingers in its
> ears and singing "la la la la la" instead of acknowledging the reality
> of NAT and trying to figure out how to do it right was a big mistake.
> 
>> This is only about allocating a chunk of address space.
> 
> I wish that were true. :)
> 
> 
> Doug
> 
> -- 
> 
>   It's always a long day; 86400 doesn't fit into a short.
> 
>   Breadth of IT experience, and depth of knowledge in the DNS.
>   Yours for the right price.  :)  http://SupersetSolutions.com/
> 
> ___
> 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: Consensus Call: draft-weil-shared-transition-space-request

[Ralph Droms]

On Dec 1, 2011, at 8:10 AM 12/1/11, Eliot Lear wrote:

> Ralph,
> 
> Where we ran into trouble the last time on this was that the OSS systems
> themselves that manage the edge devices needed to be able to actually
> communicate with those devices using the reserved space (reachability
> testing, what-have-you).  All that stuff runs on a variety of h/w,
> including Linux, Windows, and other.  But if ops want to use 240/4, I
> say have at it!  It's just sitting there, after all...

Got it.  I mistakenly inferred you were referring back to the discussion about 
adding 240.0.0.0/4 to the global address space pool...

- Ralph

> 
> Eliot
> 
> On 12/1/11 2:06 PM, Ralph Droms wrote:
>> On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote:
>> 
>>> Randy,
>>> 
>>> 
>>> On 11/30/11 6:09 AM, Randy Bush wrote:
>>>>> skype etc. will learn.  This does prevent the breakage it just makes
>>>>> it more controlled.  What's the bet Skype has a patched released
>>>>> within a week of this being made available?
>>>> cool.  then, by that logic, let's use 240/4.  the apps will patch within
>>>> a week.  ok, maybe two.
>>> As someone who tried to "Go There", I agree with you that 240/4 is not
>>> usable.  It would be fine in routers in short order, as it's fairly easy
>>> for ISPs to exert influence and get that code changed, but general
>>> purpose computing and all the OSS systems are a completely different
>>> kettle of fish.
>> Eliot - in the case of Shared CGN space, I think all that's needed is for 
>> the ISP routers between the CPEs and the CGN to forward 240.0.0.0/10 
>> traffic.  Those addresses will be hidden from the rest of the Internet by 
>> the CGN on one side and the subscriber GWs on the other side.  If this 
>> address space weren't hidden, RFC 1918 space (e.g., 10.64.0.0/10) or a /10 
>> reserved from public IPv4 space wouldn't work, either.
>> 
>> Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, 
>> and there would likely have to be some small amount of parallel RFC 1918 
>> space in the ISP core network for servers, hosts, etc.  Of course, I'm not 
>> an operator, so I'd be happy to hear why I'm confused.
>> 
>> - Ralph
>> 
>>> But that actually supports the notion that we need to use a different
>>> block of address space.  So does the argument that 10/8 et al are well
>>> deployed within SPs. 
>>> 
>>> You wrote also that:
>>> 
>>>> and all this is aside from the pnp, skype, ... and other breakage.
>>>> and, imiho, we can screw ipv4 life support.
>>> To keep this in the realm of the technical, perhaps you would say (a
>>> lot) more on how you think this would break IPv4?
>>> 
>>> For the record, I'm of two minds- I hate the idea that the SPs haven't
>>> gotten farther along on transition, and I also wonder whether a rapider
>>> deployment of something like 6rd would be better than renumbering all
>>> edges into this space.  On the other hand, that speaks nothing about all
>>> the content on v4 today, and that's where the pain point is.
>>> 
>>> Thanks,
>>> 
>>> Eliot
>>> ___
>>> 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: Consensus Call: draft-weil-shared-transition-space-request

[Ralph Droms]

On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote:

> Randy,
> 
> 
> On 11/30/11 6:09 AM, Randy Bush wrote:
>>> skype etc. will learn.  This does prevent the breakage it just makes
>>> it more controlled.  What's the bet Skype has a patched released
>>> within a week of this being made available?
>> cool.  then, by that logic, let's use 240/4.  the apps will patch within
>> a week.  ok, maybe two.
> 
> As someone who tried to "Go There", I agree with you that 240/4 is not
> usable.  It would be fine in routers in short order, as it's fairly easy
> for ISPs to exert influence and get that code changed, but general
> purpose computing and all the OSS systems are a completely different
> kettle of fish.

Eliot - in the case of Shared CGN space, I think all that's needed is for the 
ISP routers between the CPEs and the CGN to forward 240.0.0.0/10 traffic.  
Those addresses will be hidden from the rest of the Internet by the CGN on one 
side and the subscriber GWs on the other side.  If this address space weren't 
hidden, RFC 1918 space (e.g., 10.64.0.0/10) or a /10 reserved from public IPv4 
space wouldn't work, either.

Those subscriber GWs would have to handle 240.0.0.0/10 traffic correctly, and 
there would likely have to be some small amount of parallel RFC 1918 space in 
the ISP core network for servers, hosts, etc.  Of course, I'm not an operator, 
so I'd be happy to hear why I'm confused.

- Ralph

> 
> But that actually supports the notion that we need to use a different
> block of address space.  So does the argument that 10/8 et al are well
> deployed within SPs. 
> 
> You wrote also that:
> 
>> and all this is aside from the pnp, skype, ... and other breakage.
>> and, imiho, we can screw ipv4 life support.
> 
> To keep this in the realm of the technical, perhaps you would say (a
> lot) more on how you think this would break IPv4?
> 
> For the record, I'm of two minds- I hate the idea that the SPs haven't
> gotten farther along on transition, and I also wonder whether a rapider
> deployment of something like 6rd would be better than renumbering all
> edges into this space.  On the other hand, that speaks nothing about all
> the content on v4 today, and that's where the pain point is.
> 
> Thanks,
> 
> Eliot
> ___
> 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: Consensus Call: draft-weil-shared-transition-space-request

[Ralph Droms]

On Nov 30, 2011, at 9:41 PM 11/30/11, Victor Kuarsingh wrote:

> Ralph,
> 
> Please note the following report:
> 
> WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf)

Thanks for the reference. Do you have an easy pointer to retrieve the doc?  I'm 
curious about how the data was gathered and what conclusions are drawn.

- Ralph

> 
> Report suggested that all three RFC1918 blocks are well utilized.
> 
> Regards,
> 
> Victor K
> 
> 
> 
> On 11-11-30 9:19 PM, "Ralph Droms"  wrote:
> 
>> 
>> On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote:
>> 
>>> Daryl,
>>> 
>>> The problem described in the draft is that CPEs use 1918 space *and
>>> that many of them can't deal with the fact that there might be addresses
>>> on the outside interface that are the same as on the inside interface*.
>>> The claim was made by Randy, among others, that only 192.168/16 space
>>> was used by such unintelligent CPEs. I believe I have seen the claim
>>> that 10/8 space is also used in unintelligent equipment that can't deal
>>> with identical addresses inside and outside.
>> 
>> Another suggestion was the use of 10.64.0.0/10, with the argument that
>> some devices may use 10.0.0.0 but those devices tend to start numbering
>> with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in
>> 10.64.0.0/10.
>> 
>> Is there evidence that there are deployments today of devices that use
>> addresses in 10.64.0.0/10?
>> 
>> - Ralph
>> 
>>> Is there reason to believe that within the ISP network / back-office
>>> etc. that there is equipment that can't deal with 17.16/12 space being
>>> on both the inside and outside? I haven't seen anyone make that specific
>>> claim.
>>> 
>>> If we know that 172.16/12 used both inside and outside will break a
>>> significant amount of sites that CGNs will be used with, we can ignore
>>> this argument. But if not, then let's rewrite the document to say that
>>> CGNs should use 172.16/12 and that any device that wants to use
>>> 172.16/12 needs the ability to deal with identical addresses on the
>>> inside and the outside interface. Of course, all equipment should have
>>> always been able to deal with identical addresses inside and outside for
>>> all 1918 addresses anyway. But if we think the impact of using 172.16/12
>>> for this purpose will cause minimal harm, then there's no compelling
>>> reason to allocate new space for this purpose.
>>> 
>>> pr
>>> 
>>> On 11/30/11 3:04 PM, Daryl Tanner wrote:
>>>> It's not just about the CPE devices and customer LANs.
>>>> 
>>>> Address conflicts are also going to happen within the ISP network /
>>>> back-office etc. 172.16.0.0/12 is used there.
>>>> 
>>>> 
>>>> Daryl
>>>> 
>>>> 
>>>> On 30 November 2011 20:52, Brian E Carpenter
>>>>  wrote:
>>>> On 2011-12-01 09:28, Chris Grundemann wrote:
>>>> ...
>>>>> It is more conservative to share a common pool.
>>>> 
>>>> It suddenly occurs to me that I don't recall any serious analysis
>>>> of using 172.16.0.0/12 for this. It is a large chunk of space
>>>> (a million addresses) and as far as I know it is not used by default
>>>> in any common CPE devices, which tend to use the other RFC 1918 blocks.
>>>> 
>>>> I realise that ISPs with more than a million customers would have to
>>>> re-use this space, whereas a /10 would only bring this problem above 4M
>>>> customers, but at that scale there would be multiple CGN monsters
>>>> anyway.
>>>> 
>>>> Sorry to bring this up on the eve of the telechat.
>>> 
>>> -- 
>>> Pete Resnick 
>>> <http://www.qualcomm.com/~presnick/>
>>> 
>>> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>>> 
>> 
>> ___
>> 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: Consensus Call: draft-weil-shared-transition-space-request

[Ralph Droms]

On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote:

> Daryl,
> 
> The problem described in the draft is that CPEs use 1918 space *and that many 
> of them can't deal with the fact that there might be addresses on the outside 
> interface that are the same as on the inside interface*. The claim was made 
> by Randy, among others, that only 192.168/16 space was used by such 
> unintelligent CPEs. I believe I have seen the claim that 10/8 space is also 
> used in unintelligent equipment that can't deal with identical addresses 
> inside and outside.

Another suggestion was the use of 10.64.0.0/10, with the argument that some 
devices may use 10.0.0.0 but those devices tend to start numbering with 
10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in 10.64.0.0/10.

Is there evidence that there are deployments today of devices that use 
addresses in 10.64.0.0/10?

- Ralph

> Is there reason to believe that within the ISP network / back-office etc. 
> that there is equipment that can't deal with 17.16/12 space being on both the 
> inside and outside? I haven't seen anyone make that specific claim.
> 
> If we know that 172.16/12 used both inside and outside will break a 
> significant amount of sites that CGNs will be used with, we can ignore this 
> argument. But if not, then let's rewrite the document to say that CGNs should 
> use 172.16/12 and that any device that wants to use 172.16/12 needs the 
> ability to deal with identical addresses on the inside and the outside 
> interface. Of course, all equipment should have always been able to deal with 
> identical addresses inside and outside for all 1918 addresses anyway. But if 
> we think the impact of using 172.16/12 for this purpose will cause minimal 
> harm, then there's no compelling reason to allocate new space for this 
> purpose.
> 
> pr
> 
> On 11/30/11 3:04 PM, Daryl Tanner wrote:
>> It's not just about the CPE devices and customer LANs.
>> 
>> Address conflicts are also going to happen within the ISP network / 
>> back-office etc. 172.16.0.0/12 is used there.
>> 
>> 
>> Daryl
>> 
>> 
>> On 30 November 2011 20:52, Brian E Carpenter  
>> wrote:
>> On 2011-12-01 09:28, Chris Grundemann wrote:
>> ...
>> > It is more conservative to share a common pool.
>> 
>> It suddenly occurs to me that I don't recall any serious analysis
>> of using 172.16.0.0/12 for this. It is a large chunk of space
>> (a million addresses) and as far as I know it is not used by default
>> in any common CPE devices, which tend to use the other RFC 1918 blocks.
>> 
>> I realise that ISPs with more than a million customers would have to
>> re-use this space, whereas a /10 would only bring this problem above 4M
>> customers, but at that scale there would be multiple CGN monsters anyway.
>> 
>> Sorry to bring this up on the eve of the telechat.
> 
> -- 
> 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: [fun] [homegate] HOMENET working group proposal

[Ralph Droms (rdroms)]

On Jun 30, 2011, at 12:17 PM, "Stephen [kiwin] PALM"  wrote:

> It is not for "us" to decide when a user's network is not worth expending
> any more energy on. They have deployed their network...
> and do not want to expend any more energy themselves.  If their SP deploys
> IPv6 inelegantly, the user would have a lot of frustration/work.  Which
> will generate many expensive tech support calls... and potentially lost 
> customers.

Agreed that we need to avoid any disruptions of existing networks, devices and 
deployment scenarios.  I think we should avoid expending energy on *new* 
functions for IPv4.

- Ralph

> 
> It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that 
> users have.
> 
> regards, kiwin
> 
> On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote:
>> 
>> "Gone" isn't so important as "not worth expending any more energy on.". So 
>> I'm with Keith and would like to find some words like "when it doesn't take 
>> any more work."
>> 
>> - Ralph
>> 
>> On Jun 30, 2011, at 12:00 PM, "Fernando Gont"  wrote:
>> 
>>> On 06/30/2011 12:46 PM, Keith Moore wrote:
>>>> I'd like for this group to relax the "wherever possible" bit, so as to not 
>>>> preclude solutions where IPv6 can do a better job than IPv4.
>>>> 
>>>> IPv4 is a dinosaur gasping for its last breaths.
>>> 
>>> Just curious: when you expect IPv4 to be gone? (including "gone" from
>>> home and enterprise networks)
>>> 
>>> Thanks,
>>> --
>>> Fernando Gont
>>> e-mail: ferna...@gont.com.ar || fg...@acm.org
>>> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>>> 
>>> 
>>> 
>>> ___
>>> fun mailing list
>>> f...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/fun
>> ___
>> fun mailing list
>> f...@ietf.org
>> https://www.ietf.org/mailman/listinfo/fun
>> 
> 
> -- 
> Stephen [kiwin] Palm   Ph.D.  E:  p...@kiwin.com
> Senior Technical Director T: +1-949-926-PALM
> Broadcom Broadband Communications Group   F: +1-949-926-7256
> Irvine, California   W: http://www.kiwin.com
> Secondary email accounts:  stephenp...@alumni.uci.edu  p...@broadcom.com
> s.p...@ieee.org  p...@itu.ch  sp...@cs.cmu.edu  p...@ics.t.u-tokyo.ac.jp
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [fun] [homegate] HOMENET working group proposal

[Ralph Droms (rdroms)]

"Gone" isn't so important as "not worth expending any more energy on.". So I'm 
with Keith and would like to find some words like "when it doesn't take any 
more work."

- Ralph

On Jun 30, 2011, at 12:00 PM, "Fernando Gont"  wrote:

> On 06/30/2011 12:46 PM, Keith Moore wrote:
>> I'd like for this group to relax the "wherever possible" bit, so as to not 
>> preclude solutions where IPv6 can do a better job than IPv4.
>> 
>> IPv4 is a dinosaur gasping for its last breaths.
> 
> Just curious: when you expect IPv4 to be gone? (including "gone" from
> home and enterprise networks)
> 
> Thanks,
> -- 
> Fernando Gont
> e-mail: ferna...@gont.com.ar || fg...@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> ___
> fun mailing list
> f...@ietf.org
> https://www.ietf.org/mailman/listinfo/fun
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: HOMENET working group proposal

[Ralph Droms]

On Jun 30, 2011, at 12:51 AM, Melinda Shore  wrote:

> On 6/29/11 8:32 PM, Keith Moore wrote:
>> However it does not follow that home networks need NAT or private address 
>> space.  Those are hacks of the 1990s.  They always were shortsighted, and 
>> they turned out to be an operational disaster.  We can do better.
> 
> We can and should, but it's pretty clear that if the IETF
> were good at evangelizing we wouldn't be in this situation
> in the first place.  The focus really needs to be on producing
> good, secure protocols that work on the networks we've got.

...or the networks we can see coming in the near future.  ZigBee Alliance is 
driving an IPv6-based multi-link architecture through planned deployments of 
SE2.0 by several utilities.  BBF and CableLabs both expect IPv6, end-to-end 
connectivity 

Homenet will avoid breaking existing IPv4 deployments in the networks we've got 
today, but won't spend resources on unnecessary (in some cases impossible) 
feature parity.

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

Re: 25 or 6to4

[Ralph Droms]

Now that I've swapped back in some more recollections - yes, I did see Chicago 
perform it live when it was first released - I'm glad you finally cleared up 
the meaning behind the lyrics.  I always thought the lyrics somehow 
drug-related ... of course, we thought a lot of lyrics were drug-related then.

More recently I thought it was about reading drafts for a telechat.

- Ralph

On Jun 21, 2011, at 6:18 PM 6/21/11, Peter Saint-Andre wrote:

> I needed a diversion from reviewing draft-ietf-v6ops-6to4-to-historic
> and its associated IETF LC comments. Back to my IESG duties now... ;-)
> 
> On 6/21/11 4:14 PM, Ralph Droms wrote:
>> Wow.  An absolute tour de force from someone who *clearly* has too much time 
>> on his hands.
>> 
>> Thanks; made my day.  Well, except for now I've got that long-forgotten tune 
>> stuck in my head...
>> 
>> - Ralph
>> 
>> On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote:
>> 
>>> A bit of levity about migration to IPv6, with apologies to Robert Lamm
>>> and with thanks to Dan Wing and Joe Hildebrand...
>>> 
>>> ###
>>> 
>>> "Waiting for the break of day" (yes, the dawn will come with the
>>> universal deployment of IPv6)
>>> 
>>> "Searching for something to say" (how will we communicate once IPv4 is
>>> gone?)
>>> 
>>> "Flashing lights against the sky" (hoping for extraterrestrial
>>> intervention to solve the problem)
>>> 
>>> "Giving up I close my eyes" (ignoring IPv4 address exhaustion)
>>> 
>>> "Staring blindly into space" (have you ever read all the IPv6-related
>>> specifications in one sitting?)
>>> 
>>> "Getting up to splash my face" (February 3, 2011 was a wakeup call, no?)
>>> 
>>> "Wanting just to stay awake" (simply wishing for the Internet to keep
>>> working)
>>> 
>>> "Wondering how much I can take" (these v4 to v6 discussions are
>>> interminable, aren't they?)
>>> 
>>> "Should I try to do some more?" (pondering the idea of writing an
>>> Internet-Draft)
>>> 
>>> "25 or 6to4" (yes, port 25 is the answer -- perhaps the problem will
>>> solve itself if we all just send more email to ietf@ietf.org!)
>>> 
>>> ###
>>> 
> 

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

Re: 25 or 6to4

[Ralph Droms]

Wow.  An absolute tour de force from someone who *clearly* has too much time on 
his hands.

Thanks; made my day.  Well, except for now I've got that long-forgotten tune 
stuck in my head...

- Ralph

On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote:

> A bit of levity about migration to IPv6, with apologies to Robert Lamm
> and with thanks to Dan Wing and Joe Hildebrand...
> 
> ###
> 
> "Waiting for the break of day" (yes, the dawn will come with the
> universal deployment of IPv6)
> 
> "Searching for something to say" (how will we communicate once IPv4 is
> gone?)
> 
> "Flashing lights against the sky" (hoping for extraterrestrial
> intervention to solve the problem)
> 
> "Giving up I close my eyes" (ignoring IPv4 address exhaustion)
> 
> "Staring blindly into space" (have you ever read all the IPv6-related
> specifications in one sitting?)
> 
> "Getting up to splash my face" (February 3, 2011 was a wakeup call, no?)
> 
> "Wanting just to stay awake" (simply wishing for the Internet to keep
> working)
> 
> "Wondering how much I can take" (these v4 to v6 discussions are
> interminable, aren't they?)
> 
> "Should I try to do some more?" (pondering the idea of writing an
> Internet-Draft)
> 
> "25 or 6to4" (yes, port 25 is the answer -- perhaps the problem will
> solve itself if we all just send more email to ietf@ietf.org!)
> 
> ###
> 
> 
> ___
> 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: Liaison and request for review of ITU-T document

[Ralph Droms]

Brian - thanks for your review and comments.

- Ralph

On Jun 10, 2011, at 10:45 PM 6/10/11, Brian E Carpenter wrote:

> Ralph,
> 
> As far as I can tell this seems to describe some sort of a Layer 2 stateful
> per-flow QoS mechanism using new Ethertype headers. As such I don't see why
> the IETF would care. The point of it escapes me, since we have plenty of 
> reason
> to believe that such solutions are impractical and do not scale, but that 
> doesn't
> seem like our problem.
> 
> I only looked at this to check if it impacted current work in 6MAN on
> the IPv6 Flow Label, and there doesn't appear to be any impact or relevance.
> 
> Regards
>   Brian Carpenter
> 
> On 2011-06-08 08:27, Ralph Droms wrote:
>> The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a 
>> Draft Recommendation.  That liaison is available as 
>> https://datatracker.ietf.org/liaison/1054/.  The official liaison is 
>> available at https://datatracker.ietf.org/documents/LIAISON/file1232.pdf.
>> 
>> The liaison asks for IETF review of Draft Recommendation "Signalling 
>> protocols and procedures relating to Flow State Aware QoS control in a 
>> bounded sub-network of a NGN", which is available at 
>> https://datatracker.ietf.org/documents/LIAISON/file1231.pdf.  This note 
>> opens an IETF comment period on the document, ending midnight, anywhere on 
>> earth, 2011/7/5.  After the comment period, a summary will be prepared and 
>> returned in a liaison to ITU-T Q5/SG-11.
>> 
>> Of specific interest to the IETF are any ways in which the "signalling 
>> protocols and procedures" defined in the Draft Recommendation might interact 
>> with existing IETF Internet protocols.  We are especially interested in 
>> potential adverse interactions or interference with IETF Internet protocols. 
>>  The technical merits of the "signalling protocols and procedures" defined 
>> in the Draft Recommendation are of interest inasmuch as the IETF community 
>> might provide technical advice and recommendations to improve the Draft 
>> Recommendation itself.
>> 
>> Please respond with any comments on the Draft Recommendation to 
>> ietf@ietf.org.  Thanks in advance for your review of the Draft 
>> Recommendation.
>> 
>> - Ralph Droms, Internet Area Director
>>  for the IESG
>> 
>> 
>> ___
>> 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

Liaison and request for review of ITU-T document

[Ralph Droms]

The IETF has recently received a liaison from ITU-T Q5/SG-11 regarding a Draft 
Recommendation.  That liaison is available as 
https://datatracker.ietf.org/liaison/1054/.  The official liaison is available 
at https://datatracker.ietf.org/documents/LIAISON/file1232.pdf.

The liaison asks for IETF review of Draft Recommendation "Signalling protocols 
and procedures relating to Flow State Aware QoS control in a bounded 
sub-network of a NGN", which is available at 
https://datatracker.ietf.org/documents/LIAISON/file1231.pdf.  This note opens 
an IETF comment period on the document, ending midnight, anywhere on earth, 
2011/7/5.  After the comment period, a summary will be prepared and returned in 
a liaison to ITU-T Q5/SG-11.

Of specific interest to the IETF are any ways in which the "signalling 
protocols and procedures" defined in the Draft Recommendation might interact 
with existing IETF Internet protocols.  We are especially interested in 
potential adverse interactions or interference with IETF Internet protocols.  
The technical merits of the "signalling protocols and procedures" defined in 
the Draft Recommendation are of interest inasmuch as the IETF community might 
provide technical advice and recommendations to improve the Draft 
Recommendation itself.

Please respond with any comments on the Draft Recommendation to ietf@ietf.org.  
Thanks in advance for your review of the Draft Recommendation.

- Ralph Droms, Internet Area Director
  for the IESG


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

Re: draft-housley-two-maturity-levels

[Ralph Droms]

I'll take the contrarian position.

Demonstrate to me that the barriers for PS really are higher than they used to 
be.

- Ralph

On Oct 26, 2010, at 10:39 AM 10/26/10, Julian Reschke wrote:

> On 26.10.2010 16:31, Dave CROCKER wrote:
>> ...
>> This seems to be the core idea driving support for this specification.
>> 
>> Unfortunately, there is nothing in the proposed change that will affect
>> this goal.
>> 
>> The idea seems to be that "simplifying" the later part of the labeling
>> model will somehow cause those controlling production of an initial
>> version of a spec to get it produced more quickly.
>> ...
> 
> Maybe some of the current IESG members could offer their opinion about *why* 
> the barriers for PS appear to be much higher than they used to be?
> 
> Best regards, Julian
> ___
> 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: draft-housley-two-maturity-levels

[Ralph Droms]

Time for another contrarion position...

Tony, why do you say the most pressing problem is getting past the IESG, and 
what evidence do you have that we are "going to be attacking I-Ds".

- Ralph

 
On Oct 26, 2010, at 4:54 PM 10/26/10, Tony Hain wrote:

> [...]As many others have said, the most pressing problem is getting
> past the IESG in the first place, and given there is evidence they are going
> to be attacking I-Ds, it is clear that this document does nothing to help
> with the core problem.


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

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

[Ralph Droms]

Avygdor - can you tell me more about the implementations on which the document 
is based?

- Ralph


On Oct 27, 2010, at 2:50 AM 10/27/10, Avygdor Moise wrote:

> Dear Mr. St. Johns,
> 
> Respectfully, I think that it is not the purpose of the RFC to state what it 
> is not.
> The term "all known" cleanly relates to the authors' knowledge of known 
> implementations. Certainly there may be a few implementations that do not 
> follow this RFC, but the same is true nearly for any known Standard.
> Also the term "several proprietary C12.22 over IP implementations" is rather 
> strong in view of the history of the C12 Standards and the manner in which 
> they are implemented.
> 
> Avygdor Moise
> 
> - Original Message - From: "Michael StJohns" 
> To: "Ralph Droms" ; "Avygdor Moise" 
> Cc: "Ralph Droms" ; "Jonathan Brodkin" 
> ; "IETF Discussion" ; "IESG IESG" 
> 
> Sent: Tuesday, October 26, 2010 4:24 PM
> Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 
> TransportOver IP' to Informational RFC
> 
> 
>> Hi Ralph -
>> 
>> Exactly what I was getting at.  But a slight change in the wording you 
>> suggested to make things clear.
>> 
>> Instead as the first paragraph of the abstract or as an RFC editor note I 
>> suggest:
>> 
>> "This document is not an official submission on behalf of the ANSI C12.19 
>> and C12.22 working groups.  It was created by participants in those groups 
>> building on knowledge of several proprietary C12.22 over IP implementations. 
>>  The content of this document is an expression of a consensus aggregation of 
>> those implementations."
>> 
>> 
>> This, unlike your formulation, doesn't beg the question of whether or not 
>> "existing implementations"  and "all known" means "every single one 
>> including ones not publicly announced"
>> 
>> Thanks, Mike
>> 
>> 
>> At 05:34 PM 10/26/2010, Ralph Droms wrote:
>>> Combining an excellent suggestion from Donald and Avygdor's clarification 
>>> as to the official status of this document, I suggest an RFC Editor note to 
>>> add the following text as a new last paragraph in the Introduction:
>>> 
>>> This document was created by technical experts of the ANSI C12.22
>>> and ANSI C12.19 Standards, based on they first hand implementation
>>> knowledge of existing C12.22 implementations for the Internet.  It
>>> is not an official and approved submission on behalf of the ANSI
>>> C12.22 and ANSI C12.19 working groups.  The content of this document
>>> is an expression on the aggregate experience of all known
>>> implementations of ANSI C12.22 for the SmartGrid using the Internet.
>>> 
>>> - Ralph
>>> 
>>> On Oct 26, 2010, at 5:25 PM 10/26/10, Avygdor Moise wrote:
>>> 
>>>> Mr. St. Johns,
>>>> 
>>>> You ask: "Is this document an official and approved submission on behalf 
>>>> of the ANSI C12.22 and ANSI C12.19 working groups?"
>>>> Answer: No it is not.
>>>> 
>>>> The ANSI C12.22 and ANSI C12.19 standards do not define the Transport 
>>>> Layer interfaces to the network. They only define the Application Layer 
>>>> Services and content.
>>>> This RFC addressed the gap as it applies to transporting C12.22 APDUs over 
>>>> the Internet.  However technical experts that were involved in the making, 
>>>> deploying, testing and documenting the referred standards contributed to 
>>>> the making of this RFC.
>>>> 
>>>> ANSI, NEMA, NIST, SGIP, MC, IEEE, IETF, AEIC and EEI are fully aware of 
>>>> this effort and this RFC. The work was carried in plain view.
>>>> 
>>>> Avygdor Moise
>>>> - Original Message -
>>>> From: Michael StJohns
>>>> To: Avygdor Moise
>>>> Cc: ietf@ietf.org ; IESG IESG ; Jonathan Brodkin
>>>> Sent: Tuesday, October 26, 2010 2:58 PM
>>>> Subject: RE: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 
>>>> TransportOver IP' to Informational RFC
>>>> 
>>>> One simple question:  Is this document an official and approved submission 
>>>> on behalf of the ANSI C12.22 and ANSI C12.19 working groups?
>>>> 
>>>> 
>>>> The specific language in the IESG record (in the working group summary) is
>>>> 
>>>>

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

[Ralph Droms]

Combining an excellent suggestion from Donald and Avygdor's clarification as to 
the official status of this document, I suggest an RFC Editor note to add the 
following text as a new last paragraph in the Introduction:

  This document was created by technical experts of the ANSI C12.22
  and ANSI C12.19 Standards, based on they first hand implementation
  knowledge of existing C12.22 implementations for the Internet.  It
  is not an official and approved submission on behalf of the ANSI
  C12.22 and ANSI C12.19 working groups.  The content of this document
  is an expression on the aggregate experience of all known
  implementations of ANSI C12.22 for the SmartGrid using the Internet.

- Ralph

On Oct 26, 2010, at 5:25 PM 10/26/10, Avygdor Moise wrote:

> Mr. St. Johns,
>  
> You ask: "Is this document an official and approved submission on behalf of 
> the ANSI C12.22 and ANSI C12.19 working groups?"
> Answer: No it is not.
>  
> The ANSI C12.22 and ANSI C12.19 standards do not define the Transport Layer 
> interfaces to the network. They only define the Application Layer Services 
> and content.
> This RFC addressed the gap as it applies to transporting C12.22 APDUs over 
> the Internet.  However technical experts that were involved in the making, 
> deploying, testing and documenting the referred standards contributed to the 
> making of this RFC.
>  
> ANSI, NEMA, NIST, SGIP, MC, IEEE, IETF, AEIC and EEI are fully aware of this 
> effort and this RFC. The work was carried in plain view.
>  
> Avygdor Moise 
> - Original Message -
> From: Michael StJohns
> To: Avygdor Moise
> Cc: ietf@ietf.org ; IESG IESG ; Jonathan Brodkin
> Sent: Tuesday, October 26, 2010 2:58 PM
> Subject: RE: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 
> TransportOver IP' to Informational RFC
> 
> One simple question:  Is this document an official and approved submission on 
> behalf of the ANSI C12.22 and ANSI C12.19 working groups?
> 
> 
> The specific language in the IESG record (in the working group summary) is 
> 
> 
> "This document was created by technical experts of the ANSI
> C12.22
>   and ANSI C12.19 Standards, based on they first hand
> implementation
>   knowledge of existing C12.22 implementations for the Internet.
> Its
>   content is an expression on the aggregate experience of all known
>   implementations of ANSI C12.22 for the SmartGrid using the
>   internet."
> 
> 
> 
> "Created by Technical Experts of the ..."  is NOT the same as "This document 
> was created by (or is a product of) the ANSI C12.22 and C12.19 working groups"
> 
> If you're not paying attention, you might assume this was an official work 
> product of C12.22 and C12.19.
> 
> 
> Or is this in reality a C12.22 work product?  If so, why not say so?  Better 
> yet, why not have the ANSI liaison say so?
> 
> 
> The issue is not the qualifications of the contributors, nor the process for 
> creating the document, but whether or not this is a private contribution 
> rather than a standards body contribution.  The document is NOT clear on this 
> and reads like a standards body submission.  Given the authors involvement 
> with the C12 organization, a reasonable person might assume this is an 
> official submission even though the Working Group Notes seem to point to an 
> individual or private submission.  It seems reasonable to clarify which hat 
> is being worn in terms of submission.
> 
> 
> Mike
> 
> At 12:16 PM 10/26/2010, Avygdor Moise wrote:
>> Dear Nikos,
>> 
>> I believe that you appropriately addressed the comment and I are in complete 
>> agreement with your remarks.
>> 
>> I'd would also like to point out that Mr. St. Johns' concerns are also 
>> addressed on the IETF data tracker for this RFC ( 
>> http://datatracker.ietf.org/doc/draft-c1222-transport-over-ip/), on the IESG 
>> Write-ups tab. Specifically there is a Technical Summary, a Working Group 
>> Summary and a Document Quality section. These sections  fully disclose and 
>> document the origin and the processes used to produce this RFC Draft and the 
>> qualifications of the contributors.
>> 
>> Sincerely
>> Avygdor Moise
>> 
>> Chair: ASC C12 SC17, WG2 / ANSI C12.19;  IEEE SCC31 / WG P1377
>> Editor: ASC C12 SC17, WG1/ ANSI C12.22;  IEEE SCC31 / WG 1703
>> 
>>> -Original Message-
>>> From: ietf-boun...@ietf.org [ mailto:ietf-boun...@ietf.org] On Behalf Of
>>> ext Nikos Mavrogiannopoulos
>>> Sent: Tuesday, October 26, 2010 11:49 AM
>>> To: Michael StJohns
>>> Cc: i...@ietf.org; ietf@ietf.org
>>> Subject: Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22
>>> TransportOver IP' to Informational RFC
>>> 
>>> On Mon, Oct 25, 2010 at 7:39 PM, Michael StJohns 
>>> wrote:
>>> > Hi -
>>> > I'm confused about this approval.
>>> > As I read the draft and the approval comments, this document is an
>>> independent submission describing how to do C12.22 over IP. But the
>>> document is without context for "who does this" typical to an
>>> informational RFC.
>>>

Re: Review of draft-ietf-dna-simple

[Ralph Droms]

I think the issue is trying to describe the behavior from an implementation 
rather than functional perspective.  The goal is to ensure that only those 
addresses derived from prefixes in the RA are marked as operable.

- Ralph

On Aug 19, 2010, at 6:00 PM 8/19/10, Bernard Aboba wrote:

> In that scenario, it makes sense to me. 
> 
> However, if the RA advertises the same prefixes would there be a reason to
> mark all addresses as inoperable? 
> 
> -Original Message-----
> From: Ralph Droms [mailto:rdroms.i...@gmail.com] 
> Sent: Thursday, August 19, 2010 2:50 PM
> To: Bernard Aboba
> Cc: IETF Discussion
> Subject: Re: Review of draft-ietf-dna-simple
> 
> Bernard - this text is, in my opinion, intended to sync the internal data
> structures if the RA advertises different prefixes than the last time the
> host was attached to this link:
> 
>   On reception of a Router Advertisement the host MUST go through the
>   SDAT and mark all the addresses associated with the router (both
>   SLAAC and DHCPv6 acquired) as inoperable.
> 
> - Ralph
> 
> On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:
> 
>> Overall, I think the document the document looks good.  Some comments:
>> 
>> Section 2.4
>> 
>>   The host uses a combination of unicast
>>   Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
>>   and DHCPv6 message exchanges in order to determine whether previously
>>   encountered routers are present on the link, and if they are not,
>>   acquire the new configuration information.
>> 
>> [BA] Since DHCPv6 operation isn't affected, it might be more accurate to
> say the following:
>> 
>>   The host uses a combination of unicast
>>   Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs)
>>   in order to determine whether previously
>>   encountered routers are present on the link, in which case an
>>   existing configuration can be reused.  If previously encountered
>>   routers are not present then either IPv6 Stateless Address
> Autoconfiguration
>>   and/or DHCPv6 is used for configuration.  
>> 
>> 
>> Section 5.3
>> 
>>   o  Sending of neighbor discovery and/or DHCPv6 probes
>> 
>> [BA] When Simple DNA is used, neighbor discovery probes are always sent,
> and DHCPv6 operation is not affected.  So I'd change this to:
>> 
>> . Sending of neighbor discovery probes.
>> 
>> 
>> 5.7.2.  Receiving Router Advertisements
>> 
>>   On reception of a Router Advertisement the host MUST go through the
>>   SDAT and mark all the addresses associated with the router (both
>>   SLAAC and DHCPv6 acquired) as inoperable.  The host MUST then process
>>   the Router Advertisement as specified in Section 6.3.4. of [RFC4861].
>> 
>> [BA] I don't understand why the first sentence is necessary in the 
>> case where the addresses have already been confirmed via Neighbor probes.
>> 
>> Section 5.11
>> 
>>   If a response is received to any unicast Neighbor Solicitation or
>>   Router Solicitation message, pending retransmissions MUST be
>>   canceled.
>> 
>> [BA] Why should receipt of a response to a Neighbor Solicitation cancel
> pending retransmissions of a Router Solicitation?
>> 
>> ___
>> 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: Review of draft-ietf-dna-simple

[Ralph Droms]

I am OK with publication of the document if Bernard's comments are addressed.

- Ralph

On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:

> Overall, I think the document the document looks good.  Some comments:
>  
> Section 2.4
>  
>The host uses a combination of unicast
>Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
>and DHCPv6 message exchanges in order to determine whether previously
>encountered routers are present on the link, and if they are not,
>acquire the new configuration information.
>  
> [BA] Since DHCPv6 operation isn’t affected, it might be more accurate to say 
> the following:
>  
>The host uses a combination of unicast
>Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs)
>in order to determine whether previously
>encountered routers are present on the link, in which case an
>existing configuration can be reused.  If previously encountered
>routers are not present then either IPv6 Stateless Address 
> Autoconfiguration
>and/or DHCPv6 is used for configuration.  
>  
>  
> Section 5.3
>  
>o  Sending of neighbor discovery and/or DHCPv6 probes
>  
> [BA] When Simple DNA is used, neighbor discovery probes are always sent, and 
> DHCPv6 operation is not affected.  So I’d change this to:
>  
> · Sending of neighbor discovery probes.
>  
>  
> 5.7.2.  Receiving Router Advertisements
> 
>On reception of a Router Advertisement the host MUST go through the
>SDAT and mark all the addresses associated with the router (both
>SLAAC and DHCPv6 acquired) as inoperable.  The host MUST then process
>the Router Advertisement as specified in Section 6.3.4. of [RFC4861].
>  
> [BA] I don’t understand why the first sentence is necessary in the case where
> the addresses have already been confirmed via Neighbor probes. 
>  
> Section 5.11
>  
>If a response is received to any unicast Neighbor Solicitation or
>Router Solicitation message, pending retransmissions MUST be
>canceled.
>  
> [BA] Why should receipt of a response to a Neighbor Solicitation cancel 
> pending retransmissions of a Router Solicitation?
>  
> ___
> 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: Review of draft-ietf-dna-simple

[Ralph Droms]

Bernard - this text is, in my opinion, intended to sync the internal data 
structures if the RA advertises different prefixes than the last time the host 
was attached to this link:

   On reception of a Router Advertisement the host MUST go through the
   SDAT and mark all the addresses associated with the router (both
   SLAAC and DHCPv6 acquired) as inoperable.

- Ralph

On Aug 18, 2010, at 6:19 PM 8/18/10, Bernard Aboba wrote:

> Overall, I think the document the document looks good.  Some comments:
>  
> Section 2.4
>  
>The host uses a combination of unicast
>Neighbor Solicitations (NSs), multicast Router Solicitations (RSs)
>and DHCPv6 message exchanges in order to determine whether previously
>encountered routers are present on the link, and if they are not,
>acquire the new configuration information.
>  
> [BA] Since DHCPv6 operation isn’t affected, it might be more accurate to say 
> the following:
>  
>The host uses a combination of unicast
>Neighbor Solicitations (NSs) and multicast Router Solicitations (RSs)
>in order to determine whether previously
>encountered routers are present on the link, in which case an
>existing configuration can be reused.  If previously encountered
>routers are not present then either IPv6 Stateless Address 
> Autoconfiguration
>and/or DHCPv6 is used for configuration.  
>  
>  
> Section 5.3
>  
>o  Sending of neighbor discovery and/or DHCPv6 probes
>  
> [BA] When Simple DNA is used, neighbor discovery probes are always sent, and 
> DHCPv6 operation is not affected.  So I’d change this to:
>  
> · Sending of neighbor discovery probes.
>  
>  
> 5.7.2.  Receiving Router Advertisements
> 
>On reception of a Router Advertisement the host MUST go through the
>SDAT and mark all the addresses associated with the router (both
>SLAAC and DHCPv6 acquired) as inoperable.  The host MUST then process
>the Router Advertisement as specified in Section 6.3.4. of [RFC4861].
>  
> [BA] I don’t understand why the first sentence is necessary in the case where
> the addresses have already been confirmed via Neighbor probes. 
>  
> Section 5.11
>  
>If a response is received to any unicast Neighbor Solicitation or
>Router Solicitation message, pending retransmissions MUST be
>canceled.
>  
> [BA] Why should receipt of a response to a Neighbor Solicitation cancel 
> pending retransmissions of a Router Solicitation?
>  
> ___
> 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: IETF Logo Wear

[Ralph Droms]

My recollection is that they were a gift from Craig Partridge...

- Ralph

On Aug 17, 2010, at 2:23 PM 8/17/10, Patrik Fältström wrote:

> 
> On 17 aug 2010, at 19.43, Fred Baker wrote:
> 
>> I actually really appreciated Marshall Rose's shirt from Danbury - 
>> 
>>"Internet Staff"
> 
> +1
> 
>   Patrik
> 
> ___
> 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: Ad Hoc BOFs

[Ralph Droms]

One of the contributors, in my opinion, to the evolution of an "ad hoc meeting 
in a bar" to "Bar Bof" as Fred defines it has been a series of small actions, 
intended to facilitate the organization ad hoc meetings, that have had the 
unintended consequence of increasing the apparent close relationship between a 
Bar BoF, an IETF meeting and the WG formation process:

Specifically:

* AD attendance at Bar Bofs
  Intention (at least speaking for myself): early awareness
  Unintended consequence: formal invitations and expected attendance
* scheduling unused meeting rooms during IETF meetings, usually
over lunch or after 
  Intention: avoid the overhead of finding a non-conficting
space for a meeting
  Unintended consequence: Extra admin overhead for IETF secretariat;
Bar BoFs look more like formally scheduled IETF events
* conversation about Bar BoF scheduling on IETF mailing lists
  Intention: 
  Unintended consequence: Bar BoFs are widely advertised and many
of attendees are in listen-only mode
* posting of Bar Bof logistics on an IETF wiki
  Intention: central location for Bar BoF logistics
  Unintended consequence: Bar BoFs look more like formally scheduled
IETF events

I will confess to describing a problem here without suggesting an associated 
solution.  It's hard to support banning any one of these actions taken 
individually.  Taken together, they seem to move us away from ad hoc meetings 
to an unplanned additional layer of formalism in our process.

- Ralph

On Jul 29, 2010, at 4:00 PM 7/29/10, Fred Baker wrote:

> [...]
> Let me explain what a Bar BOF is, and what it is not. Our formal BOFs are 
> scheduled with an AD, and are generally for formalizing a charter. The 
> assumption is that a prior ad hoc process, usually on a mailing list or via 
> telephone or conferencing systems has happened, and a work item has matured 
> to the point that we have interested people, proto-specifications or at least 
> problem statements, and so on.
> 
> The initiation point of that is often-but-not-always a handful of people 
> talking over a meal or in a bar on a topic, often having convened mere 
> moments before. Sketches might be drawn on napkins, and people that are 
> hungry or thirsty have a waiter/waitress at hand to deal with that. A Bar 
> BOF, as such small gatherings are called, is *not* a full-blown meeting of 
> perhaps hundreds of people placed at a mealtime but in a place that prevents 
> them from eating. It does not require powerpoint, and is not a catered event. 
> It is not ten minutes stolen from some other subject. Key concept: we respect 
> each other and each other's time, and so we meet in a place that has food and 
> drink, and we have an intimate conversation among people who will be 
> interested to carry on some work item. 
> 
> [...]
> 
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Advance travel info for IETF-78 Maastricht

[Ralph Droms]

So, with all this discussion, I'm still not clear what to expect.   
When I walk up to a train ticket kiosk in Schiphol, should I expect to  
be able to use my US-issued, non-chip credit card (AMEX, VISA - I  
don't care as long as *one* of them works), or should I have a fistful  
of Euros handy?


- Ralph

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

Re: [77all] No Host for IETF 77

[Ralph Droms]

I propose $40 for a seat at the table in the front of the meeting  
rooms, $20 for a seat toward the front with extra legroom and $100 for  
an exit row.


- Ralph

On Mar 22, 2010, at 5:46 PM 3/22/10, Dave CROCKER wrote:




Ever had a dot on your badge?  Well this is your chance.

...

You can buy a green dot at the
registration desk for your badge for $20.



Oh boy.

There's a model for the way to pursue this, from highway  
beautification sponsorship.


Might be interesting to walk down the IETF halls, with signs along  
the way, stating that this person or that person has has sponsored a  
segment of the hallway...


d/
--

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


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

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ralph Droms]

Christian - I think address selection is part but not all of the  
problem.


I would be happy to see a summary of current practice in dealing with  
simultaneous attachment to multiple networks.  How does an iPhone  
decide between its WiFi and dell interfaces?  How does an RG that can  
reach multiple next hop routers on its WAN interface select which  
router to forward to?  How does a laptop choose between its WiFi and  
wired interfaces?


- Ralph

On Apr 22, 2009, at 7:03 PM 4/22/09, Christian Vogt wrote:


On Apr 22, 2009, Margaret Wasserman wrote:

This topic, address selection, is not currently handled by  
applications.
In many cases, it is handled entirely by the stack (through  
ordering of
the destination ddresses in DNS replies and source address  
selection in
the IP stack), and in other cases the application chooses a  
destination

address with the stack choosing a source address.  There are certain
cases (sometimes in solutions to the problems that we are discussing
here) where applications do choose both the destination and sourece
address, but they are not common.



Margaret -

From a system perspective, you are certainly right:  Applications
typically do get help from the operating system in selecting their
addresses.  From an OSI layering perspective, though, address  
selection

still is performed at application layer.  In fact, if an application
wants to do a complete job, especially a peer-to-peer application, it
needs to select both source and destination address itself, possibly
after running STUN, TURN, or ICE.

My main point, though, was that we are talking about two orthogonal
issues -- conflicting configuration and address selection.  This holds
independently of the fact that an application may let the operating
system accomplish part or all of address selection.

Whether we take this to mean that both issues should be tackled in the
same working group is a different story.  I personally don't see the
orthogonality of the two issues as a reason not to tackle both  
issues in

the same working group.  We just ought to be aware that the issues are
separate, and the charter should describe them as such.  This said,
there might be work-load- or work-scope-specific reasons that suggest
splitting the work into separate working groups, like those brought up
by Lars, Sam, and Scott.  Those arguments should be discussed as well.

- Christian



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


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

Re: [mif] WG Review: Multiple InterFaces (mif)

[Ralph Droms]

I agree with Christian that there are two orthogonal issues.  Comments  
in line...


- Ralph

On Apr 22, 2009, at 1:19 AM 4/22/09, Christian Vogt wrote:


Folks -

It seems that folks are considering two related, yet still orthogonal
topics for inclusion in the MIF charter:

- Conflicts between configuration parameters.

- Issues with address selection.

(These two topics also span "issues with multiple network  
connections",

which has been brought up as well.)

The first topic talks about a problem of the network stack:  How are
conflicting parameters for host or interface configuration reconciled
with each other, or, if not reconcilable, which parameters win?  This
issue may come up if configuration parameters are received from  
multiple

sources, such as from any set of default routers, DHCP servers, and
manual configuration.  Hosts with multiple interfaces are more  
likely to
be confronted with this issue, but the issue may also come up for  
hosts

with a single interface.


Yes...this topic arises whenever there are multiple sources of  
"information", and those sources of information may be delivered over  
a single "interface".


I think the topic is modified by the existence of multiple  
"administrative domains".  We could hand-wave away the topic of  
conflicting information from multiple sources in a single admin domain  
as "misconfiguration".  Information from multiple admin domains might  
be conflicting, or might be appropriate only for traffic related to  
the admin domain.  Roughly speaking, there is a vague description of  
the related problem of per-interface and host-wide information  
supplied through DHCP.


The second topic talks about a problem of applications:  When  
initiating

a connection, which pair of source and destination address (and
consequently which pair of interfaces) should be used?  Again, this
issue may come up independently of whether a host has one or multiple
interfaces -- though the presence of multiple interfaces makes the  
issue

more difficult to tackle and, since it determines which interface pair
is used, also more important.


In some circumstances, the order of selection might be reversed: pick  
an interface (WiFi versus wired Ethernet) and then choose addresses.


Hm.  Perhaps that would be better expressed as "order of preference";  
some destination might not be reachable through one interface, even if  
that interface might be preferred for other reasons.



Both topics need work; the arguments that have been put forth clearly
show this.  And we have to make a decision whether to tackle either or
both of these topics in the MIF working group.  Personally, I feel  
that

the workload of both topics will be manageable for a single working
group.  Though, if we decide to tackle both, then the working group
charter would have to explicitly list these topics as two separate  
ones.

This would require some, but not much, rewriting of the charter.

In any case, the working group acronym could actually stay as is.  If
the working group will tackle both topics, we could re-use the acronym
for "Multiply Interface Addressing and Configuration".  If only one of
the topics will be tackled, then we could just remove from this the
words "and Configuration" or "Addressing and", respectively.

- Christian


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


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

Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00

[Ralph Droms]

Yup ... there is currently no way to provide authenticated, meaningful  
identification of the network(s) to which a host is attached.  Without  
that identification, it's pretty hard to write any reasonable policies.


- Ralph

On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote:


On 2009/4/13 Ralph Droms  wrote:

For example, would a host process
information received from a Starbucks network over its 802.11
interface differently from information received a home network over  
the 802.11 interface?


It's even more fun than that.   How do we reliably know that we are  
at Starbucks, and not at home?   The SSID?   That's not an  
authenticated token.   Currently Windows makes security decisions  
based on the SSID.   You could call this the best answer they could  
come up with for a problem with no good answers.   Or you could say  
that it instills the user with a false sense of security.   Either  
way, it's not something I'd be comfortable seeing in a protocol  
spec, so if the client is in fact to make decisions as you've  
suggested, we'd need a secure way of doing this.   I don't know  
enough about WPA Enterprise to know if there's a bidirectional  
authentication going on there - from the UI perspective it looks  
like it's one-way.




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

Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

[Ralph Droms]

Ted - I think it's just as likely for the RG to get different  
information from different interfaces (or different "administrative  
domains") as it is for a host to get get different information  
directly.  Traffic from the host, which is then forwarded by the RG to  
one of more than one possible interfaces or routers, might be affected  
by the configuration information from the "administrative domain"  
through which the traffic is forwarded.


Now, I admit I'm describing a hypothetical and abstract scenario.  I  
don't have a specific example of a situation in which a host might  
make decisions - either in the stack or in an application or ??? -  
about outbound traffic based on knowledge of how that traffic would be  
forwarded by the RG.


- Ralph

On Apr 13, 2009, at 5:11 PM 4/13/09, Ted Lemon wrote:

How realistic is it anyway that an RG would get different *relevant*  
options on its different interfaces?   This would seem to me to be  
an administrative error.   Of course the broadcast address and  
subnet mask options might be different, but it doesn't make sense to  
send the RG, e.g., different name servers for each interface.




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

Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

[Ralph Droms]

Hui - I think there is an issue for hosts with multiple interfaces  
triggered by Scott's comments about the container option: even if a  
host is physically aware that it has multiple interfaces, how does it  
take the characteristics of the networks behind those interfaces into  
account when it merges information?  For example, would a host process  
information received from a Starbucks network over its 802.11  
interface differently from information received a home network over  
the 802.11 interface?


- Ralph

On Apr 12, 2009, at 2:34 AM 4/12/09, Hui Deng wrote:


Hi, Scott,

Based on the current MIF charter proposal, it consider only host.
http://www.ietf.org/mail-archive/web/mif/current/msg00367.html
I am wondering whether RG is a kind of host?

Anyhow, this discussion benefit MIF for the future consideration how
to identify the source.

Many thanks

-Hui

2009/4/11 Scott Brim :

Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is "DHS"?


Sorry, DHCP server

The usual case - almost the only case today - is that there is a  
single

upstream service provider and a single source of DHCP options to be
passed along to the client.  In this scenario, there's no need to  
pass

along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding  
a tag
that would be passed along with the options so the subscriber  
client can
identify the source of each option.  But, what would the client do  
with
that information?  How would the client interpret it?  What is the  
syntax

and semantics of the tagging?

Taken a step farther, sourcing information might be required even if
there is no intermediate RG and the contained option is not in  
use.  How

does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty  
much

the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need to
document it.  If the information is merged at the RG server, then the
RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or added
later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott



On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

  I am concerned about multiple interface scenarios as are being
  discussed in MIF and 6MAN, where either the RG is multiply  
connected
  or the end device is.  For a discussion of the sort of problems  
that

  lead to this concern, see (for example) notes from the MIF BOF at
  IETF74.

  - There must be a way to associate options with a particular
upstream DHS they were obtained from, when the container is  
passed

to the RG server and perhaps to the end device.  This source
information may or may not be in the container itself --  
that's up
to the WG to decide.  If it is decided that the source  
information
will not be part of the container syntax, at least the fact  
that
it is necessary should be documented for people who  
ultimately do

specify how container options are passed.

  - The SP server may have its ideas of how a consumer device  
should

be configured, but it is not appropriate to say that the "SP
server MUST be able to control which DHCP options are  
transmitted
to the consumer device".  The RG server may need to make  
decisions
about information from multiple DHCP servers.  Perhaps you  
could

say that the SP server MUST be able to "provide information" to
the RG server.

Less significant:

  5.1 and 5.2

Alignment between the v4 and v6 descriptions would be better.  
The
v4 description has "code" in the diagram and says that "code"  
is
OPTION_CONT

Re: [dhcwg] Gen-ART review of draft-ietf-dhc-container-00

[Ralph Droms]

Mike - Can you give a little more detail?  I'm not sure I see how the  
RFC 3046 options - passed between a relay agent and a server - would  
interact with the container option.


BTW, please feel free to join the conversation at any time.  The SF  
meeting marked the 20th year anniversary of the first dhc WG meeting  
at IETF 13 in Cocoa Beach.  I was looking at the list of attendees ...  
and you were at that first meeting, so we welcome your input as a  
charter member.


Also, from the minutes of that first dhc WG meeting:

  We quickly decided to limit the scope of our discussion to "Internet
  participants" with only a single interface. This decision allowed us
  to avoid the "host versus gateway" and "multi-homed host" religious
  wars...

Guess we won't be able to duck the issue any more.

- Ralph

On Apr 11, 2009, at 4:00 PM 4/11/09, Michael StJohns wrote:

Sorry to stick my oar in, but does this or could this interact with  
the options specified in RFC3046 in an unexpected way?


At 01:41 PM 4/11/2009, Ralph Droms wrote:

Scott - even knowing "which interface which DHCP information came
from" may not be enough for a device with multiple interfaces.  Can
policies for merging information be written just based on the
characteristics of the interface - say, 3GPP versus 802.11, or IP
address of the interface - or does the device need to differentiate
between Verizon Wireless and Starbucks if I'm away from home?  Or
differentiate between my AT&T femtocell and my home WiFi network?

- Ralph

On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:


Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is "DHS"?


Sorry, DHCP server


The usual case - almost the only case today - is that there is a
single
upstream service provider and a single source of DHCP options to be
passed along to the client.  In this scenario, there's no need to
pass
along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding
a tag
that would be passed along with the options so the subscriber
client can
identify the source of each option.  But, what would the client do
with
that information?  How would the client interpret it?  What is the
syntax
and semantics of the tagging?

Taken a step farther, sourcing information might be required even  
if

there is no intermediate RG and the contained option is not in
use.  How
does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty
much
the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need  
to
document it.  If the information is merged at the RG server, then  
the

RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or  
added

later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott



On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

I am concerned about multiple interface scenarios as are being
discussed in MIF and 6MAN, where either the RG is multiply
connected
or the end device is.  For a discussion of the sort of problems
that
lead to this concern, see (for example) notes from the MIF BOF at
IETF74.

- There must be a way to associate options with a particular
 upstream DHS they were obtained from, when the container is
passed
 to the RG server and perhaps to the end device.  This source
 information may or may not be in the container itself -- that's
up
 to the WG to decide.  If it is decided that the source
information
 will not be part of the container syntax, at least the fact that
 it is necessary should be documented for people who ultimately do
 specify how container options are passed.

- Th

Re: Gen-ART review of draft-ietf-dhc-container-00

[Ralph Droms]

Scott - even knowing "which interface which DHCP information came  
from" may not be enough for a device with multiple interfaces.  Can  
policies for merging information be written just based on the  
characteristics of the interface - say, 3GPP versus 802.11, or IP  
address of the interface - or does the device need to differentiate  
between Verizon Wireless and Starbucks if I'm away from home?  Or  
differentiate between my AT&T femtocell and my home WiFi network?


- Ralph

On Apr 11, 2009, at 6:00 AM 4/11/09, Scott Brim wrote:


Excerpts from Ralph Droms on Fri, Apr 10, 2009 03:25:49PM -0400:

Scott raises an interesting point about identifying the source of
options when delivered to clients.

BTW, Scott - what is "DHS"?


Sorry, DHCP server

The usual case - almost the only case today - is that there is a  
single

upstream service provider and a single source of DHCP options to be
passed along to the client.  In this scenario, there's no need to  
pass

along any information identifying the source of the options.

To allow for a multihomed subscriber network, I can imagine adding  
a tag
that would be passed along with the options so the subscriber  
client can
identify the source of each option.  But, what would the client do  
with
that information?  How would the client interpret it?  What is the  
syntax

and semantics of the tagging?

Taken a step farther, sourcing information might be required even if
there is no intermediate RG and the contained option is not in  
use.  How

does a device with multiple interfaces make policy decisions about
information received on those multiple interfaces (which is pretty  
much

the question Scott asks about the container option)?

- Ralph


Well put.  It all comes down to where information is going to be
merged.  The case where a single RG client connected to multiple SP
servers is essentially already covered by MIF/6man, they just need to
document it.  If the information is merged at the RG server, then the
RG server should somehow know which interface which DHCP information
came from.  If all of the information is transparently passed to the
consumer device, then it needs the tags as well.

I don't know how the information could be usefully tagged -- the SP
server's IP address doesn't sound like a good idea.  The WG should
decide if tagging should be included in the container syntax or added
later (but documented now as needing study).

I'm CCing MIF in case people there aren't on the ietf list.

Thanks ... Scott



On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

 I am concerned about multiple interface scenarios as are being
 discussed in MIF and 6MAN, where either the RG is multiply  
connected
 or the end device is.  For a discussion of the sort of problems  
that

 lead to this concern, see (for example) notes from the MIF BOF at
 IETF74.

 - There must be a way to associate options with a particular
   upstream DHS they were obtained from, when the container is  
passed

   to the RG server and perhaps to the end device.  This source
   information may or may not be in the container itself -- that's  
up
   to the WG to decide.  If it is decided that the source  
information

   will not be part of the container syntax, at least the fact that
   it is necessary should be documented for people who ultimately do
   specify how container options are passed.

 - The SP server may have its ideas of how a consumer device should
   be configured, but it is not appropriate to say that the "SP
   server MUST be able to control which DHCP options are transmitted
   to the consumer device".  The RG server may need to make  
decisions

   about information from multiple DHCP servers.  Perhaps you could
   say that the SP server MUST be able to "provide information" to
   the RG server.

Less significant:

 5.1 and 5.2

   Alignment between the v4 and v6 descriptions would be better. The
   v4 description has "code" in the diagram and says that "code" is
   OPTION_CONTAINER_V4.  The v6 description has  
"OPTION_CONTAINER_V6"
   in the diagram and says that "option-code" is  
OPTION_CONTAINER_V6.


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

Re: Gen-ART review of draft-ietf-dhc-container-00

[Ralph Droms]

Scott raises an interesting point about identifying the source of  
options when delivered to clients.


BTW, Scott - what is "DHS"?

The usual case - almost the only case today - is that there is a  
single upstream service provider and a single source of DHCP options  
to be passed along to the client.  In this scenario, there's no need  
to pass along any information identifying the source of the options.


To allow for a multihomed subscriber network, I can imagine adding a  
tag that would be passed along with the options so the subscriber  
client can identify the source of each option.  But, what would the  
client do with that information?  How would the client interpret it?   
What is the syntax and semantics of the tagging?


Taken a step farther, sourcing information might be required even if  
there is no intermediate RG and the contained option is not in use.   
How does a device with multiple interfaces make policy decisions about  
information received on those multiple interfaces (which is pretty  
much the question Scott asks about the container option)?


- Ralph

On Apr 7, 2009, at 2:25 PM 4/7/09, Scott Brim wrote:


I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-dhc-container-00
Reviewer: Scott Brim
Review Date: 7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

  I am concerned about multiple interface scenarios as are being
  discussed in MIF and 6MAN, where either the RG is multiply connected
  or the end device is.  For a discussion of the sort of problems that
  lead to this concern, see (for example) notes from the MIF BOF at
  IETF74.

  - There must be a way to associate options with a particular
upstream DHS they were obtained from, when the container is passed
to the RG server and perhaps to the end device.  This source
information may or may not be in the container itself -- that's up
to the WG to decide.  If it is decided that the source information
will not be part of the container syntax, at least the fact that
it is necessary should be documented for people who ultimately do
specify how container options are passed.

  - The SP server may have its ideas of how a consumer device should
be configured, but it is not appropriate to say that the "SP
server MUST be able to control which DHCP options are transmitted
to the consumer device".  The RG server may need to make decisions
about information from multiple DHCP servers.  Perhaps you could
say that the SP server MUST be able to "provide information" to
the RG server.

Less significant:

  5.1 and 5.2

Alignment between the v4 and v6 descriptions would be better. The
v4 description has "code" in the diagram and says that "code" is
OPTION_CONTAINER_V4.  The v6 description has "OPTION_CONTAINER_V6"
in the diagram and says that "option-code" is OPTION_CONTAINER_V6.


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

Re: secdir review of draft-raj-dhc-tftp-addr-option-04

[Ralph Droms]

Jari - I agree that mentioning security issues, pointing to the  
Security Considerations in RFC 2131 and citing RFC 3118, is appropriate.


Responding to Richard...

On Dec 2, 2008, at Dec 2, 2008,5:35 PM, Richard Johnson wrote:

Ok, maybe I'm not understanding what's being suggested or maybe I'm  
simply reading the existing text in a different way.  Here's the  
contents of the draft's "Security Considerations" section:


  A rogue DHCP Server could use this option in order to coerce a  
Client
  into downloading configuration from an alternate Configuration  
Server

  and thus gain control of the device's configuration.  This is more
  easily done with the VoIP Configuration Server Address option  
than it

  was with the "TFTP Server Name" option, because in the latter case
  the attack would need to control DNS responses as well as inserting
  the rogue DHCP option information.  If this is a concern, then  
either
  DHCP Authentication may be used, or the "TFTP Server Name" option  
may

  be used instead.

  Message authentication in DHCP for intradomain use where the out- 
of-
  band exchange of a shared secret is feasible is defined in  
[RFC3118].
  Potential exposures to attack are discussed in section 7 of the  
DHCP

  protocol specification in [RFC2131].

  Other out-of-band methods of verifying the validity of the VoIP
  Configuration Server Address, such as certificates of trust,  
could be

  used to mitigate some security concerns.


So, it only mentions option 66 ("TFTP Server Name" option) by  
comparison and in order to point out the relative levels of security  
involved.  It has no "suggestion to use option 66".


The text already has an "explanation about why the use of this  
option without authentication might be problematic".  As a matter of  
fact, it seems rather explicit on the matter.


I suggest we elide the first paragraph Richard quoted, and leave the  
remainder unchanged ... except for fixing what appears to be a typo in  
the first sentence of the second paragraph: s/is feasible is/is  
feasible as/


Jeff Hutzelman mentioned other common techniques for mitigating the  
risk from DHCP server spoofing attacks, which have not, to date, been  
mentioned in any other DHCP RFCs.  If there is serious interest in a  
review of DHCP security practices, the dhc WG could return to its work  
on a DHCP threat analysis and BCP for threat mitigation.


On Dec 3, 2008, at Dec 3, 2008,5:39 AM, Jari Arkko wrote:

I think John's advice is solid. We really need to document the  
properties of our specifications, including being very clear about  
the shortcomings and recommended workarounds. Truth in advertising.  
(However, I'd would avoid making mandatory-to-implement changes that  
do not match with codebase for a legacy option document such as this  
is.)


I'm expecting a draft revision.

Jari



- Ralph


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

Re: secdir review of draft-raj-dhc-tftp-addr-option-04

[Ralph Droms]

John - guess I wasn't clear in my reply.  I think it would be fine to  
include text suggesting the use of DHCP authentication.  Mandating  
authentication would be, in my opinion, out of scope.


To be clear, I don't see that there are, in practice, problems with  
the current deployment practice.  RFC 3118 was published several years  
ago, but deployment practice today uses other methods to mitigate the  
risk of DHCP server spoofing attacks.  Similar words about  
recommending the use of RFC 3118 authentication have been included in  
other RFCs, but RFC 3118 remains undeployed (and, in fact, mostly  
unimplemented).


- Ralph


On Dec 2, 2008, at Dec 2, 2008,3:53 PM, John C Klensin wrote:




--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
<[EMAIL PROTECTED]> wrote:


Sam - I think most of the issues in your review of
draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing
the purposes of RFC 3942 and publishing Informational RFCs
describing DHCP option codes.  Fundamentally, the reason to
publish RFCs under the process described in RFC 3942 is to
document existing uses of option codes in the range of option
codes reclaimed for assignment to new DHCP options.  The
concern is to avoid conflicts between new options and those
grandfathered ("hijacked") option codes.  As such, these RFCs
(usually Informational) simply document the already
...
Responding to some of your specific points:


At the very least, I suggest mandating the use of DHCP Auth
and   removing the suggestion to use option 66 to enhance
security.  And,   in the absence of a more data about how
widely used this option is,   I suggest not publishing this
document at all.


The consensus of the dhc WG, to which I concur, is to publish
the document as Informational. The text in the Security
Considerations section about option 66 might be removed.
...
To reiterate, it's not so much a question of whether a new
code point is needed; rather, according to the procedures
described in RFC 3942, this document gives a description of an
existing use of option code 150.  That option code is in use
...


Ralph,

It seems to me that there is a middle ground here.   One can
stick with Informational publication as the WG intends, but
still modify the Security Considerations section, not only to
remove the reference to option 66 (if there is consensus that is
appropriate) but to add some explanation about why the use of
this option without authentication might be problematic.

Put differently, your objection to Sam's suggestion seems to
hinge on "just describe the existing practice, don't try to
change it in this document". Given RFC 3492, that is entirely
reasonable.  But, if there are relatively obvious difficulties
with that practice, it seems to me that documenting them would
be helpful (indeed that not doing so borders on irresponsible).

   john




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

Re: secdir review of draft-raj-dhc-tftp-addr-option-04

[Ralph Droms]

Sam - I think most of the issues in your review of draft-raj-dhc-tftp- 
addr-option-04 can be resolved by reviewing the purposes of RFC 3942  
and publishing Informational RFCs describing DHCP option codes.   
Fundamentally, the reason to publish RFCs under the process described  
in RFC 3942 is to document existing uses of option codes in the range  
of option codes reclaimed for assignment to new DHCP options.  The  
concern is to avoid conflicts between new options and those  
grandfathered ("hijacked") option codes.  As such, these RFCs (usually  
Informational) simply document the already established use of those  
option codes, so there are only very minimal requirements for  
demonstrating a need to record the use of the option code, and  
mandating changes to the established use of the option code is out-of- 
scope.  In the opinion of the dhc WG, this I-D meets the requirements  
of RFC 3942, which addresses your statement "It's not clear why a  
distinct code point is needed here" and the suggestions to require  
DHCP authentication, as well as the pointers to other, similar options  
are out-of-scope.


Responding to some of your specific points:

At the very least, I suggest mandating the use of DHCP Auth and  
removing the suggestion to use option 66 to enhance security.  And,  
in the absence of a more data about how widely used this option is,  
I suggest not publishing this document at all.


The consensus of the dhc WG, to which I concur, is to publish the  
document as Informational. The text in the Security Considerations  
section about option 66 might be removed.


It's not clear why a distinct code point is needed here.  The  
document

claims that the "TFTP server name" option (#66) must contain a domain
name, but I'm pretty sure that real-world devices (e.g. the Cisco
7960) happily accept and use v4 address literals in option 66.
Furthermore, there appear to be other DHCP options that could do the
trick (e.g. #128, documented in the IANA registry as "TFTP Server IP
address (for IP Phone software load)").


To reiterate, it's not so much a question of whether a new code point  
is needed; rather, according to the procedures described in RFC 3942,  
this document gives a description of an existing use of option code  
150.  That option code is in use today and, to eliminate any chance of  
conflict with a new option code in the future, it is entirely  
appropriate to record the use of the option code in the IANA registry  
and document its use.


The document's write-up says is "it is believed that to some extent  
this

option is in use in some deployments of VoIP devices".  That's not a
very convincing argument that enough devices use this to justify
invoking the RFC3942 procedure, given that other devices are making  
do

just fine with existing fields.


Richard checked internally at Cisco and got the following response  
from one of our colleagues:


  I would say that over 99% of Cisco Unified Communications Manager
  deployments use Option 150 with a small minority using Option 66.
  We do support Option 66, but it requires a DNS lookup if specified
  by name and does not allow for an array of addreses for the purposes
  of config server redundancy. Any third party phones that support
  registering with CUCM (e.g. Tandberg, Polycom, Sony, and others)
  also support using Option 150.

  Here's more information about uses of option 150 by Cisco customers  
(current as of 8/19/08):


• 95,000+ Cisco Unified Communications customers (all using option 150)
• 400+ customers deploying more than 5,000 IP phones
• 18M+ IP Phones shipped

Also, there are two key differences between the "VoIP Configuration  
server address" option described in this document and other options:


* This option can carry a list of addresses, rather than just a single  
address.

* Cisco's use of the option will ultimately move toward using other
  protocols such as HTTP instead of TFTP, which is why the name was
  changed from "TFTP server address" to "VoIP Configuration server  
address".



And if we do want to proceed with defining this option: shouldn't it
also allow for v6 addresses?  (The current doc only allows for v4.)


As this document describes existing practice and does not define a new  
option, there is no need to describe a version of the option for  
DHCPv6 to carry IPv6 addresses.  Cisco expects to use a vendor- 
identifying vendor-specific option for the DHCPv6 version of this  
option.


- Ralph

On Nov 26, 2008, at Nov 26, 2008,2:58 AM, Samuel Weiler wrote:


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.

Summary:

At the very least, I suggest mandating the use of DHCP Auth and  
removing 

Re: [BEHAVE] Handwaving? [Re: where to have the NAT66 discussion (was Re: Please move this thread to BEHAVE mailing list ... )]

[Ralph Droms]

Iljitsch - I understand the theory behind what you're describing...in  
practice, it's a hard problem to know where all the prefixes are that  
should be changed; worse yet, it's hard to know which prefixes in  
which parts of the configuration should be replaced with new prefixes,  
and which shouldn't be changed.


In theory (where theory == reductio ad absurdum), renumbering is just  
a network and host management problem.  In practice, while SLAAC and  
prefix delegation address some (I'll wager a fairly small percentage;  
for that matter, DHCPv4 addressed the host renumbering problem years  
ago) renumbering problems, most of the places where IP addresses are  
configured were never designed with renumbering or any sort of  
"signaling" in mind, and will be very difficult to automate.


- Ralph

On Dec 2, 2008, at Dec 2, 2008,2:11 PM, Iljitsch van Beijnum wrote:


On 2 dec 2008, at 20:02, Scott Brim wrote:

One way to fix that would be multipath transport protocols. Rather  
than
try to guess what works best, just use all of them (or at least  
several)

and get better performance without having to make difficult choices.



This doesn't help with site renumbering problems, just endpoint
renumbering.


NAT also helps very little with renumbering. The only thing that it  
buys you is that you don't have to renumber routers and other  
devices that have their addresses configured staticially sitting  
behind the NAT. But routers can receive prefixes over DHCPv6 and  
then use those prefixes to number their stuff rather than have this  
done by hand, so there is _very_ little need for static address  
configuration.

___
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: SHOULD vs MUST case sensitivity

[Ralph Droms]

Would a reasonable BCP for future docs looks something like:

  terms defined in RFC 2119 are to be capitalized for clarity;  
alternatives for RFC 2119 terms, such as "ought" and "can" are to be  
used in

  non-normative text to avoid confusion

- Ralph

On Jun 30, 2008, at Jun 30, 2008,10:08 AM, Spencer Dawkins wrote:

Without reference to other points that have been made in this  
thread, it's also worth noting that Gen-ART reviewers have been  
challenging 2119-ish statements in drafts under review for several  
years, assuming that capitalization is significant, and discouraging  
upper-casing for emphasis.


It would be lovely to have the current practice written down  
clearly, so authors and editors aren't surprised when this happens  
(and we never have to revisit the topic).


Thanks,

Spencer


However, there is abundant evidence to support argument
that prospective RFC authors should use the ALL-CAPS version of
these words - if for no other reason than because it removes any
possibility of doubt.  The evidence to support this is based at
least partly on current usage - such as a BCP like RFC 2119 is
meant to reflect.  It is also based at least in part on the the
arguments put forward in this thread.  And finally, it is based
at least in part on the common-sense proposition that anything
that adds clarity to a specification is generally a good thing.

Hence I believe the one thing we should take away from
this discussion is that - while use of the ALL-CAPS version of
the requriements level terminology in RFC 2119 is probably not
technically required to indicate the intended usage - it is a
very good idea to do this.  Further, if we assume that is the
case (and I think reasonable people will agree that it is),
then continuing the argument about the semantics in this case
is merely a distraction from useful discussion and clarity in
the work we all want to be doing.

--
Eric Gray
Principal Engineer
Ericsson


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Crocker
Sent: Sunday, June 29, 2008 10:32 PM
To: Randy Presuhn
Cc: IETF Discussion
Subject: Re: SHOULD vs MUST case sensitivity



Randy Presuhn wrote:
>> English is not case sensitive.
>
> Not so.  Case has long been used for emphasis in environments
> lacking other typographical means, such as bolding, underlining,
> or italicization.


Emphasis is not semantics.

Normative intent is semantic.

d/
--

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


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



___
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: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

[Ralph Droms]

No, you're not the only one seeing insanity.

- Ralph

On Jun 18, 2008, at Jun 18, 2008,12:44 PM, Bob Hinden wrote:

> Hi,
>
> Let me see if I understand this.
>
> - This is the specification for SMTP.  It's was first used on the
> Arpanet.
>
> - It is probably as widely deployed as IP and TCP.  Maybe more so.
>
> - It works (e.g., the email discussing this thread was sent via SMTP).
>
> - The IETF is now advancing it to Draft Standard.  I assume this means
> that we now have enough implementation experience.
>
> - Now the IESG doesn't want to approve it for Draft Standard because
> it is using a different set of example domains instead of the official
> IETF ones.
>
> Am I the only one who sees the insanity here?
>
> Bob
>
>
> ___
> 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: RFC 3484 Section 6 Rule 9

[Ralph Droms]

Without some way to choose which rule to use and when to use it, how  
can a recommendation that has conditional rule usage be implemented?

- Ralph

On Jun 3, 2008, at Jun 3, 2008,8:50 AM, Simon Josefsson wrote:

> Thomas Narten <[EMAIL PROTECTED]> writes:
>
>> Longest match in 3484 is a hack, ant it only works some of the
>> time. The WG most certinaly knew this when we approved the
>> document. But it was felt that longest-match was better than no rule
>> at all, as it helped on some situations.
>>
>> The real discussion that should be held is what could we replace it
>> with if we pulled out the rule entirely?
>>
>> We do need something better. What would that be?
>
> I suggest to describe the longest match as a rule that can be used  
> some
> of time, and describe a new rule, random selection, to be used some of
> the time.  Then you recommend the latter approach when the application
> don't know that the longest match rule is more appropriate.
>
> This would seem to meet the objective of causing the least surprise  
> and
> the least damage.
>
> Thanks,
> Simon
> ___
> 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: Confirming vs. second-guessing

[Ralph Droms]

Agreeing with Brian's dislike of 
http://www.iab.org/documents/docs/2003-07-23-nomcom.html, it was drafted, 
as far as I know, before RFC 3777 was published.  RFC 3777 defines the 
process, with the consensus of the IETF community as a whole.  I suggest 
that the IAB at least review its requirements document within the process 
defined by RFC 3777.  I think it would be more appropriate and more in 
keeping with RFC 3777 for the IAB to publish minimal or no a priori 
requirements, leaving to the Nomcom the responsibility for the provision 
of adequate documentation in support of its nominaions.  As Brian writes, 
the IAB can ask for specific additional information in those cases where 
it finds that information is necessary to complete its due diligence.

- Ralph

On Mon, 17 Mar 2008, Brian E Carpenter wrote:

> On 2008-03-17 14:16, Ralph Droms wrote:
>>
>>
>> On Sun, 16 Mar 2008, Michael StJohns wrote:
>>> [...]
>>> Put another way, the Nomcom is a search committee, but the hiring
>>> authority resides in the confirming bodies.
>>
>> Mike - I fundamentally and strongly disagree.  In my opinoin, the Nomcom
>> is the hiring committee; the confirming body is the oversight and sanity
>> check body.  The Nomcom is selected from the IETF as a whole to select the
>> management for the IETF, who then serve at the pleasure of the IETF as a
>> whole.  The confirming bodies do not form a hierarchical management or
>> hiring organization; rather, they perform a final check and review of the
>> process.
>
> To put it very slightly otherwise, the nomcom is supposed to represent
> the whole community in the process of appointing people - maybe it would
> be better named as the "appointments committee". The confirming bodies
> are supposed to provide a check that due process has been followed and
> that the proposed appointees are suitable, but they are clearly doing
> that as guardians of the process.
>
> I believe that it's appropriate for the confirming bodies to ask for
> additional information if they have reason to doubt that due proces
> has been followed or that some of the proposed appointees are suitable.
> I agree that they are inside the confidentiality boundary, too, and
> this should be made clear to all concerned. What I don't like about
> http://www.iab.org/documents/docs/2003-07-23-nomcom.html
> is that the materials are requested a priori, as if *every* NomCom
> choice is suspect. I think these are questions that should only be
> asked if the confirming body has specific reason to query a choice.
> (With one exception: it is quite reasonable to request a resume or CV
> a priori.)
>
>Brian
>
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Confirming vs. second-guessing

[Ralph Droms]

On Sun, 16 Mar 2008, Michael StJohns wrote:
> [...]
> Put another way, the Nomcom is a search committee, but the hiring 
> authority resides in the confirming bodies.

Mike - I fundamentally and strongly disagree.  In my opinoin, the Nomcom 
is the hiring committee; the confirming body is the oversight and sanity 
check body.  The Nomcom is selected from the IETF as a whole to select the 
management for the IETF, who then serve at the pleasure of the IETF as a 
whole.  The confirming bodies do not form a hierarchical management or 
hiring organization; rather, they perform a final check and review of the 
process.

- Ralph

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

Re: IONs & discuss criteria

[Ralph Droms]

On Mar 6, 2008, at Mar 6, 2008,8:55 PM, Brian E Carpenter wrote:

> On 2008-03-07 14:06, Lakshminath Dondeti wrote:
>> Brian,
>>
>> A small clarification below on the reference to the interpretation
>> problems related to 3777:
>>
>> On 3/6/2008 4:10 PM, Brian E Carpenter wrote:
>>> Dave,
>>>
>>> On 2008-03-07 12:34, Dave Crocker wrote:
 Sam Hartman wrote:
> Making it a BCP will make the interpretation problem worse not  
> better.

 How?
>>>
>>> To some extent that depends on how carefully the putative BCP
>>> is crafted, with "should" and when to disregard "should" being
>>> very precise. What I think we've seen, with 2026 over the years,
>>> and apparently this year with 3777, is that it's virtually
>>
>> I am not sure whether you have made it to the appendix in my  
>> report, but
>> the disagreements in interpretation of 3777 have a history (see Page
>> 37).  The only thing special about the current nomcom is that we  
>> chose
>> to bring it to the community's attention.  In Ralph's case, he  
>> brought
>> it to the IESG and IAB's attention in March 2006.
>
> That's true, from my personal knowledge since I was in the IESG
> at that time. However, that supports my point ;-) .
>
> (Not to be defensive, but the only changes in RFC 3777 that Ralph
> specifically recommended were the ones covered in RFC 5078).
>
>Brian

Brian - you might be right, but only on a technicality.  I noted that  
a clarification in RFC 3777 in the definition of the term of a mid- 
term appointment was needed, but didn't give a specific  
recommendation.  More to the point of Lakshminath's observation, I  
explicitly pointed out the conflict between RFC 3777 and the IAB  
requirements statement to the IAB and the IESG; I didn't recommend a  
change to RFC 3777 mostly because I thought it was the IAB  
requirements that needed to change.

- Ralph

>
>
>>
>> thanks,
>> Lakshminath
>> Nomcom 2007-8 Chair
>>
>>> impossible to write precise procedural text that deals with
>>> completely unexpected circumstances. Yet if the text has the
>>> force of a BCP, it becomes very hard to interpret it flexibly
>>> when flexibility is clearly needed.  I don't know if that
>>> is Sam's point, of course.
>>>
>>>Brian
>>> ___
>>> 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

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

Re: Nomcom 2007-8 Chair's Report

[Ralph Droms]

Lakshminath - thanks a lot for publishing this report.  We all  
appreciate and applaud the work you and the Nomcom put into this  
year's I* selections, and I especially appreciate that you invested  
the time and effort - after all that earlier hard work - to produce  
this report.  It will be of great value to future Nomcom chairs as  
well as the community as a whole, and I hope future Nomcom chairs will  
sustain the custom of producing similar reports (now I wish I had  
produced a report like yours after I served as Nomcom chair).

- Ralph

On Mar 5, 2008, at Mar 5, 2008,6:05 PM, Lakshminath Dondeti wrote:

> Folks,
>
> A report on the nomcom's activities is available at
> https://www.tools.ietf.org/group/nomcom/07/nomcom-report.  Please  
> direct
> any comments to [EMAIL PROTECTED]  I will make a brief presentation at  
> the
> IESG plenary.
>
> Abstract
>
>This document reports on the work of Nomcom 2007-8.  The topics of
>discussion include the experiences in starting the nomcom process
>early enough to facilitate the nomcom to do their work at 2 face- 
> to-
>face meetings, the various logistical challenges involved in the
>nomcom process and the differing interpretations of RFC 3777 by
>different people and organizations involved in the process.  This
>document also discusses the challenges in the interaction between  
> the
>nomcom and the confirmation bodies.
>
> regards,
> Lakshminath
> ___
> 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 @ IETF-71, especially Jabber

[Ralph Droms]

Iljitsch raises an interesting point that I'll generalize: can we  
maximize the learning by identifying specific applications to target  
for IPv6 compatibility during the IPv4 eclipse?

- Ralph

On Feb 29, 2008, at Feb 29, 2008,9:34 AM, Iljitsch van Beijnum wrote:

> What's going on with the preparations to turn off IPv4 at IETF-71?
> It's been really quiet surrounding that topic since the initial
> discussion.
>
> Because I've had an IPv6 mail server for years and a WWW proxy that
> allows IPv6-only hosts to get access to the IPv4 web is fairly trivial
> to set up (tip for XP users: XP can't do DNS lookups over IPv6, use
> Firefox and configure it with the IPv6 address of the proxy), my
> preperation for this has been mostly getting Jabber to work over IPv6.
>
> A while ago I managed to find a public Jabber server that is reachable
> over IPv6 (amessage.de with some other domains pointing to the same
> server). Unfortunately, the client I generally use, Apple's iChat,
> does support Jabber over IPv6 when there is IPv4 connectivity, but
> when the system has no IPv4 address it says that "you're not connected
> to the internet" and doesn't try to connect over IPv6. Recently I
> thought this was fixed but it turned out that the Parallels Desktop
> virtualization enviroment sets up a bunch of virtual interfaces with
> private addresses, which is enough for iChat to work over IPv6.
>
> Anyway, I started looking for Jabber clients that support IPv6. Most
> don't, but there are so many Jabber clients that there is actually a
> choice of ones that do. Unfortunately, none of them could connect to
> the jabber.ietf.org rooms. I first thought this was because of the
> clients, so I didn't keep a list of clients that support IPv6. But it
> turned out that this is a problem with my iljitsch at amessage.nl
> account on the amessage.de server, which doesn't seem IPv6-related.
>
> So... does anyone know a place to obtain a Jabber account that's
> usable over IPv6? I assumed psg.com would be a good candidate, but
> even though psg.com has a  record, jabber.psg.com doesn't.
> ___
> 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: IPv4 Outage Planned for IETF 71 Plenary

[Ralph Droms]

Fred - to be clear, that DHCPv6 interop testing was not associated in  
any way with the dhc WG.  I'll let the organizers comment on any more  
general sponsorship arrangement or other association of the event with  
the IETF.


- Ralph

On Dec 17, 2007, at Dec 17, 2007,12:23 PM, Fred Baker wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

what leads you to believe that the IETF doesn't do interoperability  
events? It has done quite a few, notably in DHCPv6 immediately  
following the recent IETF and going back in various working groups  
as far as I can remember.


On Dec 16, 2007, at 7:56 AM, Dave Crocker wrote:




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


That's not a plenary.

That's an interoperability event.

The IETF doesn't do those...

d/
--

 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

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


-BEGIN PGP SIGNATURE-

iD8DBQFHZrCebjEdbHIsm0MRAkHvAJ0ewiQIBvnSWP6/azSMbV5dNEdKdQCg41Ni
jK35XWwmLY7zg8p1qbh/DlM=
=u3fv
-END PGP SIGNATURE-

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


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

Re: IPv4 Outage Planned for IETF 71 Plenary

[Ralph Droms]

Seems to me we need ensure some formality in the experiment if we  
expect to get anything out of it.  Asking everyone to send in notes  
from their experience won't be enough - especially, as some have  
predicted, if many participants get exactly 0% Internet connectivity  
while IPv4 is off.


Some suggestions:

* Explicit documentation of any special preparations
  implemented by the IETF NOC

* Several jabber rooms during the experiment (and archive
  the logs); some suggestions:
  - explicit operational issues: successes, questions, help
  - read-only headlines from IETF NOC
  - general discussion
  - pointers to "places that work"

  Note that there is a chicken-and-egg issue accessing the jabber
  rooms over IPv6...

* IETF NOC post mortem

* IESG/IAB-sponsored post mortem


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

Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

[Ralph Droms]

Brian - OK, I agree that a wide range of tunneling/translation  
mechanisms have been considered; was the transition problem  
considered during the basic design?


In any event, in my opinion we don't have a fundamental level of  
backward compatibility that would solve the current deployment issues.


- Ralph

On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote:


On 2007-10-05 09:12, Ralph Droms wrote:

Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:

Regarding transition:

On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:



Unless I've missed something rather basic, in the case of IPv6,  
very little
attention was paid to facilitating transition by maximizing  
interoperability

with the IPv4 installed base.
Dave, I have to agree with you in this regard.  We may have  
achieved neither
significant new capabilities because IPv6 ~= IPv6+more_bits, nor  
ease of
transition because transition wasn't thoroughly evaluated early  
on in

the design process...


Ralph, that last assertion simply isn't true. Migration/transition/
co-existence was on the radar screen right from the start. The dual
stack model was chosen explicitly to allow for co-existence, and in
particular so that dual stack servers can serve both IPv4 and IPv6
clients, and that is running code.

There's a fundamental difficulty in having IPvX-only clients working
with IPvY-only servers except via application-level relays. It isn't
a consequence of design details of v4 and v6. I'm sure we could
have done better, but this was very definitely thought about.

Brian


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

Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

[Ralph Droms]

Brian - is it provable that no design for a follow-on to IPv4 would  
have provided that backward compatibility?  Or were there  
architectural and engineering decisions that chose other features  
over backward compatibility?


And, I guess I'll stop here as I'm rehashing a train that long ago  
left the station...


- Ralph

On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote:


On 2007-10-05 09:12, Ralph Droms wrote:

Typo: should read IPv6 ~= IPv4+more_bits...
- Ralph
On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:

Regarding transition:

On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:



Unless I've missed something rather basic, in the case of IPv6,  
very little
attention was paid to facilitating transition by maximizing  
interoperability

with the IPv4 installed base.
Dave, I have to agree with you in this regard.  We may have  
achieved neither
significant new capabilities because IPv6 ~= IPv6+more_bits, nor  
ease of
transition because transition wasn't thoroughly evaluated early  
on in

the design process...


Ralph, that last assertion simply isn't true. Migration/transition/
co-existence was on the radar screen right from the start. The dual
stack model was chosen explicitly to allow for co-existence, and in
particular so that dual stack servers can serve both IPv4 and IPv6
clients, and that is running code.

There's a fundamental difficulty in having IPvX-only clients working
with IPvY-only servers except via application-level relays. It isn't
a consequence of design details of v4 and v6. I'm sure we could
have done better, but this was very definitely thought about.

Brian


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

Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

[Ralph Droms]

Typo: should read IPv6 ~= IPv4+more_bits...

- Ralph

On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote:


Regarding transition:

On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:



Unless I've missed something rather basic, in the case of IPv6,  
very little
attention was paid to facilitating transition by maximizing  
interoperability

with the IPv4 installed base.
Dave, I have to agree with you in this regard.  We may have  
achieved neither
significant new capabilities because IPv6 ~= IPv6+more_bits, nor  
ease of

transition because transition wasn't thoroughly evaluated early on in
the design process...

- Ralph



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


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

Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

[Ralph Droms]

Regarding transition:

On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote:



Unless I've missed something rather basic, in the case of IPv6,  
very little
attention was paid to facilitating transition by maximizing  
interoperability

with the IPv4 installed base.
Dave, I have to agree with you in this regard.  We may have achieved  
neither

significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of
transition because transition wasn't thoroughly evaluated early on in
the design process...

- Ralph



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

Re: IPv6 will never fly: ARIN continues to kill it

[Ralph Droms]

Hear, hear.  We're making binary claims in a grey-scale world of  
economics.


Put the costs on the table and let the enterprises and ISPs fight out  
PI/PA.


- Ralph

On Sep 13, 2007, at Sep 13, 2007,5:27 AM, Jun-ichiro itojun Hagino  
wrote:



my persistent question to the enterprise operator is this:
how frequently do you plan to switch your isp, or how many times
did you do that in the past?


That's actually irrelevant.  Regardless of the real answer,
enterprises are
not willing to buy into vendor lock.


if the management needs to be convinced by the cost, i would suggest
ISPs to price PI advertisement like hell ($$$), so that we can make
the worldwide routing table smaller.
it will help ISPs use smaller peering routers in the end.

itojun

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


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

Re: Beggars _can_ be choosers?

[Ralph Droms]

I seem to remember that the idea of a postmortem was discussed at  
some point.  I don't know that anything came of that discussion.   
Having some facts and data to examine probably beats anecdotal  
observations about network behavior.


I think David is wise to observe that experience like "DHCP doesn't  
work" doesn't always carry over to "we need to fix DHCP".  Failure of  
one protocol service may just be a symptom of some other failure.   
And failure of a DHCP service request is likely to be an immediately  
and easily observable symptom of some other network failure.


- Ralph

On Aug 1, 2007, at Aug 1, 2007,12:12 PM, Joel Jaeggli wrote:


David W. Hankins wrote:


as recently as the IETF 69 tech plenary,
where we were told that firewalls were becoming obsolete,  
evidenced by

their lack of use at IETF meetings.

There's only one word for it:  Astounding.


Told by whom? I was one of the people at the the microphone. I work  
for
a firewall vendor, and I asked a question (probably rhetorical) of  
the IAB.



I have never, until now, heard the contrary fallacy attempted.  That
is, "because we did X at an IETF meeting and it did not work
allright, it is therefore insufficient for the Internet."

That's a new one on me.

Clever, but wrong: networks much larger than 1,200 laptops use DHCPv4
on a daily basis all over the Internet without similar symptoms.


Start by asking the contractor, the volunteers and the IAD for a
postmortem on the operation of the network. anything else is just
speculation.




- 
---


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



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


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

Re: Should I* opinions be afforded a special status? (Re: [saag] Declining the ifare bof for Chicago)

[Ralph Droms]

DHCP is also a frequently-used building block (some would say  
attractive nuisance).  Stig, Jari and I are trying to identify drafts  
from outside the dhc WG that extend DHCP or use DHCP in novel ways,  
so we can provide guidance to the authors of those drafts as early as  
possible.  Jari and Stig have arranged to review the contents of all  
I-Ds to scan for occurrences of "DHCP", and we're following up with  
manual review to identify which of those drafts should be reviewed by  
the dhc WG as a whole.


So far we've identified about 115 drafts that contain "DHCP", and  
have reviewed about 40 of those drafts.  Roughly 10% seem to be  
drafts that the dhc WG should review.


- Ralph


On Jun 28, 2007, at Jun 28, 2007,9:56 AM, Michael Thomas wrote:


Brian E Carpenter wrote:

On 2007-06-27 17:42, Michael Thomas wrote:

Brian E Carpenter wrote:

One thing that would make a significant difference would be if WGs
really took responsibility for their own quality control. Even  
at the

trivial level, the IESG still gets drafts that don't pass ID-nits
(but that is getting better, thanks to PROTO shepherding). But  
maybe

we should be pushing harder to make WGs responsible for getting
final external reviews done (and responded to). That would just be
more delegation along the path that's been followed for the last
several years.


Part of the problem with cross area review is that there's such a  
flood
of documents that it's pretty impossible to know unless somebody  
tells/asks

you to review it that you should care.


Indeed. The current reviews such as Gen-ART and secdir reviews  
don't just
happen spontaneously; specific reviewers are triggered by a  
"dispatcher."



As I said, I'm a little skeptical about
"expert review", but for so-called experts as well as the laity  
in other areas,
it might be nice to have some indexing when it touches areas  
which are

known to contain land mines.


We also need reviewers to look for land mines in unexpected places.



We already do this to some degree with Security Considerations,  
but they
often read as a "Full Disclosure" part of a contract rather than  
the basis of

how operation security is intended in the draft itself.

What might be nice is to have some cross domain Cliff's Notes  
capturing
the jist of how this draft uses or affects other areas? So that  
people in other
areas can determine more easily if something whacky might be  
going on
and pique their interest in reading it? Were this done sooner in  
the process
rather than later, we well might be able to nip more whackiness  
before it

bubbles all the way up to the IESG.


It sounds like that would be done before passing the document
on for AD review. Is that your idea?


Yes -- well before. Maybe something something along the lines of
what it builds on, might impact, might be applicable to, etc. The
problem that I see is that there a fair amount of beg, borrowing and
stealing (good) and that is often done without the keepers of those  
things

knowledge until pretty late in the game (bad). Take DNS for example
since it's a favorite franken-building block. Would anybody in the
namedropper crowd be likely to know if, say, the routing crowd
was using DNS in some new way? Probably not. If, however, we
had a dashboard which named out the cross-area dependencies in,
oh say, the area section or the working group page or somewhere
like that it would at _least_ give you a clue that there might be  
something

interesting to look at in an area you normally pay no attention to.
Mike

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


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

Re: IANA registration constraints

[Ralph Droms]

Can we please leave the specific opinions about DHCP out of this discussion?
The dhc WG has done its due diligence, with review and support from the IETF
and the IESG, to put into place processes to govern assignment of extensions
to DHCP and to accommodate future extensions to both DHCPv4 and DHCPv6 in
the option code space design.  This discussion is clearly not the place for
opinions about how future extensions to DHCP ought to be managed.

If DHCP must be brought into the discussion, please read and understand the
relevant RFCs and policies at IANA before using DHCP as a whipping
boy/example.

- Ralph (who's not bitter at all)



On 6/13/07 10:54 AM, "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:

> That is why I think this is an area that the IAB should look at.
> 
> I don't think we should be worried about running out of protocol numbers.
> Deployment of IPv6 and multicast pretty much demonstrate that it is a
> non-issue.
> 
> At the application level we just need to persuade people that, no it is not
> acceptable or sustainable to have an internet architecture that is dependent
> on parsimonious assignment of IP Port or DNS RR numbers.
> 
> Where we have a resource code consumption issue we should either declare the
> protocol essentially closed for extensions or work out a way to introduce a
> sustainable extension mechanism.
> 
> 
> So for example on DHCP I think it would be entirely justifiable to say 'this
> is an infrastructure for assigning IP addresses and specifying the domain name
> for the LAN and we do not therefore anticipate assignment of additional codes
> on an ongoing basis'. This does not rule out special pleading (e.g. geopriv)
> but clearly signals to people to think somewhere else.
> 
> Alternatively if we think that every new protocol is going to need a DHCP slot
> to advertise its existence then we would have to work out a way to insert an
> extensible mechanism.
> 
> In the case of DHCP the first approach is clearly the way to go.
> 
> 
>> -Original Message-
>> From: Jari Arkko [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, June 13, 2007 10:38 AM
>> To: Hallam-Baker, Phillip
>> Cc: ietf@ietf.org; [EMAIL PROTECTED]
>> Subject: Re: IANA registration constraints
>> 
>> Phillip,
>> 
>>> My personal view is that we should develop an Internet
>> architecture that allows an infinite number of new protocols
>> to be deployed without consumption of scarce resources, i.e.
>> port numbers of DNS RRs.
>> ...
>>> So in summary, the IAB should be charged with identifying
>> the set of finite resources that IANA assigns and propose an
>> Internet architecture in which deployment of new application
>> layer protocols does not cause any of the finite resources to
>> be depleted.
>>>   
>> 
>> I'm definitely in favor of improving the situation. And for
>> applications protocols this is probably an easier problem to
>> begin with. And as I said in the previous e-mail, as far as I
>> know, most new work uses field sizes and types that have less
>> scarcity.
>> 
>> However, the Internet runs to a large extent on protocols
>> that were designed decades ago, and some of those protocols
>> have number spaces that  are very finite. I don't want to run
>> out of protocol numbers, DHCP message types, etc.
>> 
>> Jari
>> 
>> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

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

Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[Ralph Droms]

Set up the relay agent in your router to point at my DHCP server.

- Ralph


On 4/20/07 1:59 PM, "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:

> OK how do I DHCP to the server on your network from my desk here?
> 
> (assuming that there are no NATs or firewalls)
> 
> If it was pure IP it would work.
> 
>> -----Original Message-
>> From: Ralph Droms [mailto:[EMAIL PROTECTED]
>> Sent: Friday, April 20, 2007 1:57 PM
>> To: Hallam-Baker, Phillip; David W. Hankins; ietf@ietf.org
>> Cc: GEOPRIV WG
>> Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68
>> Working Group Hums
>> 
>> Huh?  DHCP is carried in UDP and IP.  There is a little
>> funkiness in the
>> DHCPv4 transport, which we wouldn't have need if IPv4
>> link-local addresses had been defined when RFC 2131 was
>> published.  DHCPv6 uses link-local addresses and garden-variety IPv6.
>> 
>> - Ralph
>> 
>> 
>> On 4/20/07 1:48 PM, "Hallam-Baker, Phillip"
>> <[EMAIL PROTECTED]> wrote:
>> 
>>>  
>>> 
>>>> From: David W. Hankins [mailto:[EMAIL PROTECTED]
>>> 
>>>> On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker,
>> Phillip wrote:
>>>>> DHCP is a layer 3 technology that talks directly to layer 2.
>>>> 
>>>> DHCP is a technology that dynamically configures hosts.
>>> 
>>> That's not the point, the point here is that DHCP is not an
>> Internet protocol.
>>> It is an IETF protocol but not an Internet protocol. It
>> does not layer 
>>> on the IP stack.
>>> 
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf
>> 

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

Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[Ralph Droms]

Huh?  DHCP is carried in UDP and IP.  There is a little funkiness in the
DHCPv4 transport, which we wouldn't have need if IPv4 link-local addresses
had been defined when RFC 2131 was published.  DHCPv6 uses link-local
addresses and garden-variety IPv6.

- Ralph


On 4/20/07 1:48 PM, "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote:

>  
> 
>> From: David W. Hankins [mailto:[EMAIL PROTECTED]
> 
>> On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote:
>>> DHCP is a layer 3 technology that talks directly to layer 2.
>> 
>> DHCP is a technology that dynamically configures hosts.
> 
> That's not the point, the point here is that DHCP is not an Internet protocol.
> It is an IETF protocol but not an Internet protocol. It does not layer on the
> IP stack.
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

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

Re: Prague

[Ralph Droms]

I visited Prague about two years ago and had the same experience as Ed.  I
traveled via the Metro and on foot, visited all the tourist traps; had no
problems and never felt unsafe.

- Ralph


On 3/7/07 10:54 AM, "Edward Lewis" <[EMAIL PROTECTED]> wrote:

> I will attest to Prague being survivable.  I have been there once
> already and suffered no ill effects and was not robbed.  I.e., don't
> panic.
> 
> Location for location, the IETF (only) goes to the tamest and most
> accessible places in the world.  Compare it to other Internet
> organizations.
> 
> At 14:52 -0500 3/6/07...:
> ...
>> Under the entry for taxis from the airport they say "Warning:
>> Prague's taxi drivers ...

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

Re: Tracking resolution of DISCUSSes

[Ralph Droms]

Following up on that, I suggest a requirement that any DISCUSSes be posted
to that mailing list, along with conversation/resolution of the DISCUSSes.
I would very much like to see those last steps out in the open.

Only drawback to separate mailing list is that it requires active
involvement to get hooked into the last call discussion...

- Ralph


On 1/15/07 2:37 PM, "Steven M. Bellovin" <[EMAIL PROTECTED]> wrote:

> On Mon, 15 Jan 2007 14:26:33 -0500
> John C Klensin <[EMAIL PROTECTED]> wrote:
> 
> 
>> Perhaps we should make it a requirement that any document that
>> is Last Called must be associated with a mailing list, perhaps
>> one whose duration is limited to the Last Call period and any
>> follow-ups until the document is either published or finally
>> rejected.  If there were a WG, then the WG list should be a
>> proper subset of that list, anyone commenting during the Last
>> Call should be added to it, and others could be added on request.
>> 
> Actually, I think it's an excellent idea.  Tracking Last Call comments
> was always difficult, since the email tended to end up in several
> different folders and wasn't archived elsewhere.
> 
> 
> --Steve Bellovin, http://www.cs.columbia.edu/~smb
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

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

Re: "Discuss" criteria

[Ralph Droms]

I read Dave's words "clear statement of what actions must be taken to clear
the Discuss" not as requiring the specification of a complete fix, but
rather as an indication of what needs to happen to the draft.
Implementation details of meeting those requirements are left to the WG.

I agree with Dave on this point.

- Ralph


On 1/1/07 8:22 PM, "Keith Moore"  wrote:

>>  Something quite basic that is missing from the draft on
>>  Discuss Criteria is a requirement that any Discuss not only
>>  explain its precise normative basis, but that it give a clear
>>  statement of what actions must be taken to clear the Discuss.
>> 
> 
> I strongly disagree.  When a working group document fails to meet RFC
> 2026 criteria for the intended status, it's not up to the AD voting
> Discuss to fix the problem.  The burden is on the WG to either convince
> the IESG that its document does indeed meet RFC 2026 criteria, or to
> bring the document in line with RFC 2026.
> 
> While there is nothing wrong with an AD suggesting a simple fix to a
> document problem if he or she can identify one, expecting the AD to fix
> nontrivial problems is unrealistic and also encourages micromanagement.
> 
> Keith
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

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

Review of draft-ietf-ipv6-2461bis-09.txt

[Ralph Droms]

Here are my comments on draft-ietf-ipv6-2461bis-09.txt.  In general, I think
the document is ready for publication.  Included below are a few substantive
comments that I would like to see addressed before publication, and some
editorial corrections/suggestions/comments.

- Ralph

- 

Substantive/editorial: I'm confused by the statements in section 3.2,
   Supported Link Types: "Neighbor Discovery should be implemented
   as described in this document."  What is the intent of the
   statement - advice about whether to implement or how to
   implement?  Under what circumstances would a node not implement
   Neighbor Discovery as described in the document.

Substantive: From section 4.6, Option Formats:

   Options should
   be padded when necessary to ensure that they end on their natural 64-
   bit boundaries.

   How, exactly, is this padding encoded?  And, why bother?

Substantive: The definition of the L bit, from the Prefix Information
   option, includes:

 When
 not set the advertisement makes no statement about
 on-link or off-link properties of the prefix.

   This point about "no statement about on-link or
   off-link..." is made other places, as well.  I don't think
   I see any indication of the consequences of this
   definition; that is, what should the implementor be aware
   of as a consequence of the lack of knowledge about whether
   a prefix is on-link or off-link?  If those consequences are
   subtle, perhaps they should be explained?

Editorial/substantive: From section 5.1, Conceptual Data Structures:

  Default Router List
   - A list of routers to which packets may be sent.

   Is it possible for a host to send packets to routers that
   are not on the Default Router list?

Editorial: In the last paragraph of section 1,
   s/Deering Richard/Deering, Richard/

Editorial suggestion: In the definition of "link MTU" (section 2.1),
   s/piece/transmission unit/ (or some other similar term)

Editorial: In the definition of NBMA (section 2.2), s/it(e.g.,/it (e.g.,/

Editorial: In the definition of "Address Autoconfiguration" in section 3,
   I'm guessing that "How nodes automatically configure..." was
   changed to "Introduces the mechanisms needed in order to allow
   nodes to automatically configure..." because the mechanism is
   defined in RFC 2462.  A citation of RFC 2462 might be in order
   here.

Editorial: In the definitions of "Anycast addresses" and "Proxy
   advertisements" in section 3, the phrases "non-Override
   advertisements" and "non-Override Neighbor Advertisements"
   are used before they are defined.

Editorial: Seems "autonomous address configuration" and "stateless
   address configuration" (and some variants like "autonomous
   address-configuration", "stateless address
   autoconfiguration" and "address autoconfiguration") are
   used interchangeably throughout the document; it would
   improve clarity to pick one phrase and use it uniformly
   throughout the document

Editorial: The definition for Prefix Information option in section 4.2
   includes the text "specify the prefixes that are on-link
   and/or are used for address autoconfiguration".  Is it the
   case that a Prefix Information option will only appear for
   on-link and/or address autoconfiguration; i.e., at least
   one of the L and A bits will always be set in Prefix
   Information  option?

Editorial: In the definition of MinRtrAdvInterval in 6.2.1,
   s/.75 *MaxRtrAdvInterval/.75 * MaxRtrAdvInterval/

Editorial: In section 6.3.4, s/"on-link "/"on-link"/

Editorial suggestion: In Appendix E,
  s/working.  It merely/working; it merely/


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

RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt

[Ralph Droms \(rdroms\)]

Comment about DHCPv6 question in line...

- Ralph


-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
Sent: Wed 11/22/2006 4:51 AM
To: Scott W Brim; General Area Review Team; Jari Arkko; Mark Townsley 
(townsley); Bob Hinden; Brian Haberman; Thomas Narten; Erik Nordmark; William 
Allen Simpson; ipv6@ietf.org; ietf@ietf.org
Subject: RE: gen-art review of draft-ietf-ipv6-2461bis-09.txt
 

 > 4.2 router advertisement
 > 
 >   - "Note: If neither M nor O flags are set this indicates that no
 > information is available via DHCPv6."
 > 
 > This means that the responding router always knows if DHCPv6 is
 > definitely available or definitely not available.  Is there any
 > possibility that the responding router might not know?  

=> I don't think so. It should always know.

It's a network config and admin issue.  The router doesn't "learn" or "know" if 
DHCPv6 is available; rather, the router is explicitly configured by the network 
admin to advertise the availability of DHCPv6 to hosts.  Presumably, the 
netowkr admin knows whether DHCPv6 is available and configures the router 
appropriately.

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

Re: nomcom and confidentiality

[Ralph Droms]

Bob - depends on the meaning of "straw poll".  Any vote that results in an
action should be restricted to the 10 voting members.  My understanding of
"straw poll" is an opinion poll that results in no direct action.

But I'm speculating and don't know what "straw poll" means in the context
we're discussing.

- Ralph


On 11/7/06 5:40 PM, "Bob Hinden" <[EMAIL PROTECTED]> wrote:

> Danny,
> 
>>> What  The liaisons are there to provide additional
>>> information, not directly influence the outcome.
>>> 
>>> Do you have more information on this?  If this is true, I think
>>> the result from that Nomcom is questionable.  I think this needs
>>> to be investigated and the result be made public.
>>> 
>>> I realize that we can't go back in time, but it needs to be clear
>>> to current and future nomcom's that this is a major violation of
>>> the nomcom process and should not be repeated.
>> 
>> Not to further belabor Fred's point, but:
>> 
>> You might consider the text in section 5(9) of RFC 3777:
>> 
>> ---
>> 
>>9.  All members of the nominating committee may participate in all
>>deliberations.
>> 
>>The emphasis of this rule is that no member can be explicitly
>>excluded from any deliberation.  However, a member may
>>individually choose not to participate in a deliberation.
> 
> True, but in Section 4, bullet 3, last paragraph:
> 
> None of the Chair, liaisons, or advisors vote on the
> selection of
> candidates.  They do vote on all other issues before the
> committee unless otherwise specified in this document.
> 
> In my view, having liaisons voting in straw polls is part of the
> "vote on the selection of candidates" as it has the effect of
> eliminating candidates.   This is very different from
> "deliberations".  If wanted the liaisons to vote, we would have not
> have included them in the above paragraph.
> 
> The restriction on liaisons is repeated in bullet 7 of the same
> section.  Bullet 7 makes it clear the role of liaisons is to provide
> information to the nomcom and to represent the interest of their
> organizations, not to actually select the candidates.  Again in my
> view, participating in "straw polls" is voting and is a violation of
> RFC3777.
> 
> Regards,
> Bob
> 
> 
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

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

Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

[Ralph Droms]

OK, now I have to step in with a response and to correct a couple of
misconceptions.


On 9/28/06 12:27 PM, "John C Klensin" <[EMAIL PROTECTED]> wrote:

> Issue 1: Even if the option is desirable and the motivation for
> it is clear, the specification is inadequate in definitions and
> specificity in this particular document.   I believe that there
> is no longer any real controversy on that matter and that the
> issue suggests, and perhaps requires,  ending the Last Call and
> returning the document to the authors.  Further kicking of that
> dead horse on this list is unlikely to accomplish much of
> anything, IMO.

Based on feedback received during the IETF last call, the authors and the
dhc WG, in collaboration with the dnsop WG, will revise the spec to address
the following issues:

1. clarify the use case motivating this option
2. clarify/reword the phrase "domain suffix"
3. simplify the reference to RFC 1035 encoding

> Issue 2: [...] 
> 
> Certainly the charter of the DHC WG doesn't contain "mindlessly
> move options from v4 to v6".

And the dhc WG has explicitly not "mindlessly moved options from v4 to v6".
Had you checked the history of DHCPv6, you would have found that the dhc WG
considered several mechanisms for carrying DHCPv4 options over to DHCPv6.
The WG rejected those mechanisms and made an explicit decision to only
redefine DHCPv4 options for DHCPv6 on demand, as required by specific use
cases.

In retrospect, we should have collaborated with the dnsop WG on this option
and we'll do so now.

However, to correct another misconception, the dhc WG does, in fact,
collaborate with customer WGs on new DHCPv[46] options.  In fact, the WG, in
consultation with the Internet ADs, makes every effort to have the customer
WG do the bulk of the option development, with input from the dhc WG on
compatibility with DHCP operation, syntax, etc.

> [...]
> 
>john

So, you've all had an opportunity to make your points, more or less
accurately and constructively, and the dhc WG will, as I said, work with the
authors and the dnsop WG to review, reconsider and clarify the document.  We
will be sure to better document the motivation and use cases for this option
in a revised document.

I think we've spent way more energy in dead horse kicking than we needed to
on a fairly insignificant DHCPv6 option at this point.

- Ralph

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

Re: Adjusting the Nomcom process

[Ralph Droms]

Perhaps we could avoid similar delays in generating the final list of
volunteers in the future:

 Secretariat generates a list of eligible volunteers as early as possible
  (As far as I know, eligibility data is available well before call for
   volunteers is posted)
 List is used to verify volunteers when offer to volunteer is received
 Volunteer can contest eligibility
 List of volunteers is ready as soon as volunteer period closes

Seems like this process would lend itself well to automation; I can imagine
a web tool that accepts offers to volunteer, checks eligibility against list
from the Secretariat and gives immediate feedback to ineligible volunteers.

- Ralph


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

Re: The Emperor Has No Clothes: Is PANA actually useful?

[Ralph Droms]

Antonio - I'm not well-informed enough about the specifics of the PANA
problem space and framework to make definitive recommendations.  I was
mostly making an observation, based on my experience, of another reaction
someone might have to a particular technology/design/protocol.

- Ralph


On 5/26/06 11:50 AM, "Antonio F. Gómez Skarmeta" <[EMAIL PROTECTED]> wrote:

> Ralph Droms escribió:
> 
>> Dave - one quick follow on to your observation about "will not work" that
>> falls somewhere between "will not work" and "don't like it".  There is
>> another possibility: "works, but there's a much simpler way to meet the same
>> requirements"...
>> 
>>  
>> 
> 
>   Which one? and why it is better?
> 
>  Antonio
> 
>> - Ralph
>> 
>> 
>> On 5/26/06 11:34 AM, "Dave Crocker" <[EMAIL PROTECTED]> wrote:
>> 
>>  
>> 
>>> Joel M. Halpern wrote:
>>>
>>> 
>>>> EAP over IP (or UDP, or link) is about authenticating the user.  If a
>>>> media independent technique better than just using a browser is needed,
>>>> then solve that problem.  Personally, I would find the work far more
>>>> persuasive if it did not also try to solve the problem of creating an
>>>> IPSec association to the access device, nor of the authorization
>>>> selection problem.
>>>> 
>>>> And spell out in clear English what use case needs that problem solved.
>>>> I can read between the lines and start to guess.  But the document is
>>>> quite unclear.  The appendix about DSL is not helpful in that regard.
>>>>  
>>>> 
>>> Although not a guaranteed way to distinguish among criticisms, it can be
>>> helpful 
>>> to categorize them as either "It will not work" versus "I don't like it".
>>> The
>>> former indicates a basic technical flaw, and the latter a matter of
>>> preference.
>>> 
>>> If it is common for readers of a specification to fail to understand what it
>>> is 
>>> for then it has, perhaps, the most basic kind of technical flaw.  How can a
>>> specification succeed if there is confusion about its implementation or use?
>>> 
>>> By contrast observations such as "there are better solutions" moves into the
>>> fuzzier and more subjective realm of trying to predict market preferences.
>>> The
>>> IETF is not very good at making these predictions.  Absent any indication of
>>> actual harm that would ensue from publishing a specification, fear that no
>>> one
>>> will adopt it or that there will be multiple solutions seems an
>>> inappropriate
>>> basis for denying publication.  (On the other hand, strong indication of
>>> community interest in deplying a specification is supposed to be a factor in
>>> deciding whether to charter the work in the first place; however as Sam
>>> noted,
>>> we are rather late in the process.)
>>> 
>>> In any event, I would claim that concerns over who will use PANA fall into
>>> the
>>> "I don't like it" category, since it basically seeks to make statements
>>> about
>>> market preferences, which is a small step from personal preferences.
>>> 
>>> Having looked over this thread and the -framework document a bit, I find
>>> myself 
>>> unclear which of the two lines of concern is being pursued, although I
>>> impressed 
>>> by the degree of confusion about PANA after what appears to be considerable
>>> effort to understand it.  This does not bode well for community
>>> understanding,
>>> and that of course does not bode well for adoption and use.
>>> 
>>> I would find it particularly helpful to have a concise statement from
>>> someone
>>> who says that PANA will not work.  Cannot be implemented (properly) by
>>> virtue
>>> of 
>>> technical errors or documentation too confusing to understand.  Or cannot be
>>> deployed and used, by virtue of administrative complexity or, again,
>>> documentation too confusing to understand.
>>> 
>>> Absent this, I will ask why it is productive to note that the emperor is
>>> pursuing an idiosynchratic sartorial style?
>>> 
>>> d/
>>> 
>>> ___
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/ietf
>>>
>>> 
>> 
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www1.ietf.org/mailman/listinfo/ietf
>> 
>>  
>> 
> 

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

Re: The Emperor Has No Clothes: Is PANA actually useful?

[Ralph Droms]

Dave - one quick follow on to your observation about "will not work" that
falls somewhere between "will not work" and "don't like it".  There is
another possibility: "works, but there's a much simpler way to meet the same
requirements"...

- Ralph


On 5/26/06 11:34 AM, "Dave Crocker" <[EMAIL PROTECTED]> wrote:

> 
> 
> Joel M. Halpern wrote:
>> EAP over IP (or UDP, or link) is about authenticating the user.  If a
>> media independent technique better than just using a browser is needed,
>> then solve that problem.  Personally, I would find the work far more
>> persuasive if it did not also try to solve the problem of creating an
>> IPSec association to the access device, nor of the authorization
>> selection problem.
>> 
>> And spell out in clear English what use case needs that problem solved.
>> I can read between the lines and start to guess.  But the document is
>> quite unclear.  The appendix about DSL is not helpful in that regard.
> 
> 
> Although not a guaranteed way to distinguish among criticisms, it can be
> helpful 
> to categorize them as either "It will not work" versus "I don't like it". The
> former indicates a basic technical flaw, and the latter a matter of
> preference.
> 
> If it is common for readers of a specification to fail to understand what it
> is 
> for then it has, perhaps, the most basic kind of technical flaw.  How can a
> specification succeed if there is confusion about its implementation or use?
> 
> By contrast observations such as "there are better solutions" moves into the
> fuzzier and more subjective realm of trying to predict market preferences. The
> IETF is not very good at making these predictions.  Absent any indication of
> actual harm that would ensue from publishing a specification, fear that no one
> will adopt it or that there will be multiple solutions seems an inappropriate
> basis for denying publication.  (On the other hand, strong indication of
> community interest in deplying a specification is supposed to be a factor in
> deciding whether to charter the work in the first place; however as Sam noted,
> we are rather late in the process.)
> 
> In any event, I would claim that concerns over who will use PANA fall into the
> "I don't like it" category, since it basically seeks to make statements about
> market preferences, which is a small step from personal preferences.
> 
> Having looked over this thread and the -framework document a bit, I find
> myself 
> unclear which of the two lines of concern is being pursued, although I
> impressed 
> by the degree of confusion about PANA after what appears to be considerable
> effort to understand it.  This does not bode well for community understanding,
> and that of course does not bode well for adoption and use.
> 
> I would find it particularly helpful to have a concise statement from someone
> who says that PANA will not work.  Cannot be implemented (properly) by virtue
> of 
> technical errors or documentation too confusing to understand.  Or cannot be
> deployed and used, by virtue of administrative complexity or, again,
> documentation too confusing to understand.
> 
> Absent this, I will ask why it is productive to note that the emperor is
> pursuing an idiosynchratic sartorial style?
> 
> d/
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf

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

Re: The Emperor Has No Clothes: Is PANA actually useful?

[Ralph Droms]

Sam - I see where the nea BOF was more-or-less associated with the Internet
Area at IETF 65.  Do you expect that nea would (if eventually chartered)
land in Internet or Security?

- Ralph


On 5/26/06 10:58 AM, "Sam Hartman" <[EMAIL PROTECTED]> wrote:

>>>>>> "Ralph" == Ralph Droms <[EMAIL PROTECTED]> writes:
> 
> Ralph> What is the current state of the nea WG?  I don't see it
> Ralph> listed at http://ietf.org/html.charters/wg-dir.html
> 
> It had a BOF at the last IETF.
> 
> It seems highly likely it will either have a proposed WG or BOF again.
> (Russ and I have received both a charter and a BOF proposal)
> 
> Russ is shepherding the effort.

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