require a new draft. If that
draft were to be approved it would need to start the publication
process at the beginning by finding a sponsoring AD.
Brian, thanks for all your work on this issue. While we did not end
up approving your draft, I think the discussion was informative and
useful.
Sam Hartman
Eliot == Eliot Lear [EMAIL PROTECTED] writes:
Eliot What is the result of a SG hitting its mile stones?
We move on to evaluating its work.
Now, there is a question of what happens when an SG misses its
milestones. I could see an argument that hints at us being wrong that
we had sufficient
Stephane == Stephane Bortzmeyer [EMAIL PROTECTED] writes:
Stephane But suggesting ORNS (Open Recursive Name Servers) for
Stephane the solution to this issue is, indeed, a bad idea (do
Stephane note I did not say the N word), for the reasons
Stephane explained in
Joao == Joao Damas [EMAIL PROTECTED] writes:
Joao It does indeed as Stephane pointed out. Opening up your
Joao resolver so you can server roaming users, without further
Joao protection, is, at best, naive.
I'd appreciate it if you took Paul's comments a lot more seriously and
Hi. I opened a ticket with the secretariat a few weeks ago
complaining that I cannot reach www.ietf.org using a teredo address
either allocated through the Microsoft Teredo server or the Debian
teredo server.
This is annoying because glibc's source address selection algorithm
seems to prefer
So, BCP 61's claim that MUST is for implementers and SHOULD is for
users is always something I've interpreted as non-normative and
additional explanation of RFC 2199. Well, I' guess it is normative in
that we do not for security reasons require that security be used.
I certainly think reviewing
Ted, speaking as an individual.
I completely agree that personnel decisions of ADs should be able to
be appealed. I actually considered proposing text modifications to
make it clear that there might be circumstances where it would be
appropriate for the IESG to resolve the conflict.
I and I
I think we should explicitly say that SGs follow WG rules.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Shumon == Shumon Huque [EMAIL PROTECTED] writes:
Shumon And yes, I agree that a new properly designed version of
Shumon HTTP Digest authentication might be one way to help. As
Shumon well as the various zero knowledge protocols.
I believe that http digest plus channel bindings does
Chris == Chris Drake [EMAIL PROTECTED] writes:
Chris Hi Alexey,
And if you would like to suggest a better process for moving
things forward, please share your opinion.
Chris Suggest: Properly document comments and reviews somewhere.
Chris Question: what's the best way to
Keith == Keith Moore [EMAIL PROTECTED] writes:
Keith Hallam-Baker, Phillip wrote:
If we can meet the needs of 80% of Internet users with some
form of shared access there will be more addresses left for the
20% with greater needs.
Keith with 2**128 potential
Ah. I must admit that I find the whole concept of informational
documents a heck of a lot less useful, but your reading of 2026 is of
course correct. I'll probably still end up treating informational
documents as close to ietf consensus statements (but not
recommendations) in my head because
Henning == Henning Schulzrinne [EMAIL PROTECTED] writes:
Henning Rather than an IESG note or in addition to, I think the
Henning author should clearly state, in the abstract, that this
Henning is a personal opinion only.
I don't think my personal opinion would make a very useful
Hi.
Both your and Eric's comments need a longer response.
It was my intent to use strong and weak password equivelantsin the
same way as the IAB document. We agree on what the IAB document
defines the terms to mean. I'll go look through my text and clarify
what needs clarification.
I'm
Eric == Eric Rescorla [EMAIL PROTECTED] writes:
Eric Well, the difference is in part the IESG note. More
Eric importantly, the question is whether the IESG intends to
Eric hold future work to the requirements in this document. If
Eric they do, then this document needs
Keith == Keith Moore [EMAIL PROTECTED] writes:
Fourth, lots of folks (me included) happen to find it
convenient to use NAT between my site/house/office and my
upstream provider.
Keith do you also find it convenient that NAT has effectively
Keith thwarted the deployment of
Paul == Paul Hoffman [EMAIL PROTECTED] writes:
I do hope that we have consensus these are good requirements,
Paul We absolutely do not have any such consensus. There was
Paul barely any discussion during IETF Last Call. There was not a
Paul mailing list for discussing the
Hi, Eric, responding as an individual.
Obviously, I disagree with your basic claim that it is too early to
write a document like this. I've asked the sponsoring AD to make a
consensus call on whether we have sufficient support to be making this
sort of statement. If not, then I'll be happy to
Paul == Paul Hoffman [EMAIL PROTECTED] writes:
Paul On a thread about a specific document that is proposed to be
Paul an Informational RFC coming through the IETF process:
Paul At 1:12 PM -0400 8/20/07, Sam Hartman wrote:
I've asked the sponsoring AD to make a consensus call
David == David Harrington [EMAIL PROTECTED] writes:
David Hi, The issue was raised during ISMS WGLC that there is a
David difference between our use of the word authenticate and the
David glossary in RFC2828. Since ISMS extends SNMPv3, ISMS is
David using terminology consistent
Iljitsch == Iljitsch van Beijnum [EMAIL PROTECTED] writes:
Iljitsch On 2-aug-2007, at 21:17, Dave Crocker wrote:
It was also interesting to open the Mac network control
pannel, enable my Airport (WLAN) interface, and see the IPv6
global address appear almost instantaneously
Soininen == Soininen Jonne (NSN FI/Espoo) [EMAIL PROTECTED] writes:
Soininen Hi, I just happened to read this mail today. I don't
Soininen remember seeing such a mail during previous nomcom
Soininen rounds (they might have come, but I just didn't notice
Soininen them). I think
Jari == Jari Arkko [EMAIL PROTECTED] writes:
Jari (I also thought that the SEC requirements were a bit too
Jari specific this year.)
They are no more specific this year than they have been in the past.
The only change is that they were at least specific in a direction
that would
Bob == Bob Braden [EMAIL PROTECTED] writes:
Bob At 08:38 AM 7/20/2007 -0700, Kurt Zeilenga wrote:
No, an I-D is a Draft Standard. An RFC is a Standard. :-)
-- Kurt
Bob No, and No.
He just says that because under his rules he's probably published more
draft
Keith == Keith Moore [EMAIL PROTECTED] writes:
Also from the draft: At least for the strong security
requirement of BCP 61 [RFC3365], the Security Area, with the
support of the IESG, has insisted that all specifications
include at least one mandatory-to-implement strong
Masataka == Masataka Ohta [EMAIL PROTECTED] writes:
Masataka Keith Moore wrote:
Also from the draft: At least for the strong security
requirement of BCP 61 [RFC3365], the Security Area, with the
support of the IESG, has insisted that all specifications
include at least
Jeffrey == Jeffrey Altman [EMAIL PROTECTED] writes:
Jeffrey Sam Hartman wrote:
Unless there is strong support for the more complex
registration process in the draft, we'd like to go to expert
review.
Jeffrey The technical argument in favor of a review list, whether
on that registration process. We
feel that in this instance, simple expert review is sufficient, and we
don't need registrations to go to a review list.
Unless there is strong support for the more complex registration
process in the draft, we'd like to go to expert review.
Sam Hartman
Security Area
Robert == Robert Elz [EMAIL PROTECTED] writes:
Robert Date:Fri, 15 Jun 2007 09:28:29 -0400
Robert From:Thomas Narten [EMAIL PROTECTED]
Robert Message-ID: [EMAIL PROTECTED]
Robert | Um, this train left the station a LONG time ago. RFC 2434 (and
I'd like to draw the attention of the community to section 3 of
draft-ietf-syslog-protocol-21.txt. This text contains text and a
clarified model of the various layers in the syslog architecture and
new terminology for the parties.
I believe this is responsive to the ietf last call comments and
p == [EMAIL PROTECTED] writes:
p Sam,
p While it is at each AD's discretion not to sponsor some
p document (and not initiate Standards Action), I don't think
p this discretion should extend to having a veto at the IESG
p table when the document and community input is
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
Lakshminath Folks, If you want the history of this thread, please
Lakshminath see the SAAG mailing list archive.
Lakshminath Thomas,
To be clear I'm not sure that I* opinions have been given special
treatment in this
has
significant value and wish we'd found a way to publish it. However we
follow a consensus process for many valuable reasons and it is clear
that the necessary consensus is not present in this case.
Sam Hartman
Security Area Director
___
Ietf mailing
Andy == Andy Bierman [EMAIL PROTECTED] writes:
Andy I think the inability of the IETF to make decisions in an
Andy open, deterministic, and verifiable manner is a major flaw.
I for one do not wish for deterministic decision making in the IETF.
Andy == Andy Bierman [EMAIL PROTECTED] writes:
Andy This is not an alternative. If you are not willing to make
Andy your technical objections to a technical specification
Andy publicly, then they cannot be part of the IETF
Andy decision-making process.
At one level I agree
I'm at an interop event this week, but I think I now get your concern
with host security and section 4.1 and would like to propose fixes.
Thanks for working with me to understand the concern.
--Sam
___
Ietf mailing list
Ietf@ietf.org
Eliot == Eliot Lear [EMAIL PROTECTED] writes:
Eliot Sam, I've reviewed draft-hartman-webauth-phishing-03.txt.
Eliot In general I agree with the tone of it in terms of how to
Eliot address these sorts of threats. However, I have a problem
Eliot with its scope. The problem you
Keith == Keith Moore [EMAIL PROTECTED] writes:
Keith it could be argued that the best thing to do is to remove
Keith ALL of the rules from the ABNF spec, leaving only the
Keith language definition and examples. (actually I think I did
Keith argue this sometime around 1996, but
John == John C Klensin [EMAIL PROTECTED] writes:
John --On Tuesday, 15 May, 2007 11:27 -0700 Dave Crocker
John [EMAIL PROTECTED] wrote:
Were we to deprecate every feature in IETF specifications that
get mis-implemented a couple of times over 10 years, I suspect
much of
John == John C Klensin [EMAIL PROTECTED] writes:
John If we are going to standardize a definitional requirement or
John method -- whether it is ABNF or IPR boilerplate or something
John -- we need to get it right as a self-contained definition
John and then live with it. We
Harald, I'm happy to accept your interpretation of the problem.
However it also leads me to the conclusion that documenting possible
reasons not to use ABNF's LWSP concept, or documenting implications of
that rule would be a good idea. I also believe that documenting
experience with a spec in
Dave == Dave Crocker [EMAIL PROTECTED] writes:
Dave Sam,
Ultimately cases like this should be evaluated based on whether
the final result is more clear overall.
Dave What about protecting the installed base for the existing
Dave spec?
I think that is not a useful
I think redefining the rule would require recycling at proposed. I
think it would be confusing and harmful to do so.
I think removing the rule would is allowed by the process (and would
require updates in referencing specs as they advance but would not
break anything). I think doing so would be
to actually allow working groups to make forward
progress.
Sam Hartman
Security Area Director
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
I think that having a single abstraction that can describe
what went by multiple names in different areas can be very
useful because it facilitates cross-area communication. And
missing an opportunity to point out
Hi.
For the last couple of years, we've been believing that EAP and GSS
used the term channel bindings inconsistently. For those of us
dealing with both, it's been a bit annoying.
I've been thinking about EAP a lot lately. and have come to the
conclusion that actually the terms are used
mean it to say. Hopefully Bernard and Russ will get back
to us on that soon.
---BeginMessage---
[ietf list trimmed to make sure I get this right; then I will forward]
Sam == Sam Hartman [EMAIL PROTECTED] writes:
Sam There are two types of lower layer identities: those that are
Sam used
Nicolas == Nicolas Williams [EMAIL PROTECTED] writes:
Nicolas Also, I think my draft's definition of end-point channel
Nicolas bidning needs to be tightened just a bit: not only must
Nicolas the end-point IDs be cryptographically bound into the
Nicolas channel, it must also be
Charles == Charles Clancy [EMAIL PROTECTED] writes:
to be an L2 identity. It can be any identity that's
meaningful to the parties involved, and can serve as the basis
for making authorization decisions.
As long as it's cryptographically bound to the L2 channel and
that
Bernard == Bernard Aboba [EMAIL PROTECTED] writes:
Bernard O, I definitely think they are session keys. [BA] They
Bernard are not TSKs according to the definition in the EAP Key
Bernard Management Framework.
That's true.
But that definition is not normative for
Dan, I'd appreciate it if you could work with Russ and Bernard on
seeing f the draft has adequate text to cover the issues that I think
we now agree should be covered. My approach would be to clarify the
definition of session key to clearly include MSK and handoff keys that
fill the same role.
Bernard == Bernard Aboba [EMAIL PROTECTED] writes:
Bernard O, I definitely think they are session keys. [BA] They
Bernard are not TSKs according to the definition in the EAP Key
Bernard Management Framework.
Bernard That's true. But that definition is not normative for
Hi. I'm sitting here reviewing changes to a document to see if I can
last call it.
As part of a response to AD review comments, one of the references
were changed. This document uses numeric references. Starting at
reference 16, everything was renumbered. That makes the diff a pain.
For
Dean == Dean Anderson [EMAIL PROTECTED] writes:
Dean On Mon, 2 Apr 2007, Sam Hartman wrote:
The IETf learned of Brown's patent application on 2006-11-29.
Dean Can you elaborate? From whom or what source did the IETF
Dean learn of the application?
The IETF learned through
Dan == Dan Harkins [EMAIL PROTECTED] writes:
Dan Sam,
Dan The keys in this hypothetical protocol are for network
Dan access and giving them to authenticators for that purpose
Dan would seem to fall under the key scope requirement.
Key scope means giving an authenticator a
Dan == Dan Harkins [EMAIL PROTECTED] writes:
Dan Sam,
Dan I guess the question is, what text in this I-D would
Dan prevent a new key distribution protocol based on AAA in which
Dan the authentication server sent a copy of the peer's keys
Dan willy-nilly to every
Hi, Dean.
First, with your permission I'd like to forward your comments to the
ietf list. This is not a promise or invitation to forward future
comments, but you have made comments on an issue that the community
rather than the IESG decides and for your comments to be considered
they need to be
[mailto:[EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 10:12 AM
To: Sam Hartman
Cc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED]
Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley-
tls-authz-extns
Sam Hartman [EMAIL PROTECTED] writes:
Simon == Simon
Hi. I had a few discussions in Prague and think that we're all
basically on the same page about what the document should say. I'm
going to describe that consensus here. I'd like to ask Russ to
confirm that the document reflects the consensus
and if so to ask me to remove my discuss and
John == John C Klensin [EMAIL PROTECTED] writes:
John I also do not believe that it is appropriate to view
John Informational publication as some sort of consolation prize.
John If the community, and the IESG, conclude that the document
John and its technology should be
to publish as a proposed
standard. Does this seem like the right approach to folks? I plan to
take some next step within the next couple of days based on input.
I'm sorry this issue is taking up so much of the community's time.
Sam Hartman
Security Area Director
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon I don't care strongly about the standards track status.
Simon However, speaking as implementer of the protocol: If the
Simon document ends up as informational or experimental, I
Simon request that we make an exception and
Ted == Ted Hardie [EMAIL PROTECTED] writes:
Ted I thought Eric Rescorla and Pasi Eronen had suggested that
Ted this document be evaluated by the TLS working group and the
Ted IPR terms evaluated there. I have that suggestion in an
Ted email thread on the main IETF list, started
Ted == Ted Hardie [EMAIL PROTECTED] writes:
Ted At 1:05 PM -0400 3/29/07, Sam Hartman wrote:
The problem is that this work is outside the charter of the TLS
working group. So, I don't think asking them to take on the
document would be appropriate. I also don't think
Ted == Ted Hardie [EMAIL PROTECTED] writes:
Ted At 4:25 PM -0400 3/29/07, Sam Hartman wrote:
Ted, I'd like to do this. However I could use some help
figuring out exactly what question I'm asking the TLS working
group to provide advice on. I guess it could be as simple
I support Nico's proposed text.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Andy == Andy Bierman [EMAIL PROTECTED] writes:
Andy I find it rather annoying to listen to the constant
Andy interruptions, reminding people of the process. The only
Andy reasons for such an interruption are:
Andy 1) it is very important to you that detailed and accurate
Narayanan, == Narayanan, Vidya [EMAIL PROTECTED] writes:
Narayanan, Dan, There is a fundamental security property in all
Narayanan, that we have been discussing:
Narayanan, It MUST NOT be possible for an entity A, impersonating
Narayanan, as entity B, to obtain any key material
I'd feel uncomfortable approving this draft until the authors indicate
that any IPR disclosures required by our process have been filed.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Russ == Russ Housley [EMAIL PROTECTED] writes:
Russ See
Russ https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=751
Russ At 08:43 AM 3/13/2007, Sam Hartman wrote:
*Sigh* I searched on the draft before sending the last call comment
and when the search tool is used
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert From the draft:
At a minimum, client and server implementations MUST be capable
of being configured to use HTTP Basic Authentication [RFC2617]
in conjunction with a TLS connection as specified by [RFC2818].
See
Robert == Robert Sayre [EMAIL PROTECTED] writes:
Robert Sam Hartman wrote:
My preference is to resolve this by making 2818 normative; I
believe we've already 3967'd 2818 so we don't need an
additional last call on this one.
Robert Is RFC 2818 sufficient to ensure
Hi, folks. The following last call comment was received and based on
discussion the draft was updated. This comment never seems to have
made it to the ietf list though.
The following text was added to address the comment. Please confirm
that this text addresses the comment and that from the
Dan, again, with the text as it stands, what attacks do you see
permitted by these requirements that you believe should not be
permitted.
The text changes you proposed were considered but are rather
problematic for existing protocols. I don't think we mind mandating
changing protocols for real
I think that a downward reference from to RFC 3325 from this document
needs a bit of thought and consideration from the community as a
whole.
Quoting the abstract of RFC 3325:
Abstract
This document describes private extensions to the Session Initiation
Protocol (SIP) that enable a
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
Hallam-Baker, The core assumption here seems to be that NAT is a
Hallam-Baker, bad thing so lets get rid of NAT rather than trying
Hallam-Baker, to make NAT work.
I disagree with this characterization of the
Hallam-Baker, == Hallam-Baker, Phillip [EMAIL PROTECTED] writes:
From: Fred Baker [mailto:[EMAIL PROTECTED]
On Feb 28, 2007, at 8:02 AM, Hallam-Baker, Phillip wrote:
The core assumption here seems to be that NAT is a bad thing
so lets get rid of NAT rather than
Steven == Steven M Bellovin [EMAIL PROTECTED] writes:
Steven On Wed, 28 Feb 2007 20:42:04 -0500
Steven Sam Hartman [EMAIL PROTECTED] wrote:
Hallam-Baker, == Hallam-Baker, Phillip
[EMAIL PROTECTED] writes:
From: Fred Baker [mailto:[EMAIL PROTECTED
Eric Rescorla has agreed to deal with the third party disclosure on my
behalf.
thanks for all the volunteers of help.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Folks, it should be surprising to no one here that we've recieved the
following disclosure; it is a direct result of my mail yesterday. I'd
ask the community to evaluate this potential IPR in addition to the
disclosure from Redphone.
---BeginMessage---
Dear Russ Housley, Mark Brown:
An IPR
Bill == Bill Fenner [EMAIL PROTECTED] writes:
Bill On 2/24/07, Sam Hartman [EMAIL PROTECTED] wrote:
I think there's a good split between RFC 3967 and this
document. RFC 3967 will cover informational documents; this
document will cover standards track.
Bill I have
I'd be happy with this title change. Does anyone object?
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Folks, in addition to the IPR disclosure that triggered this second
last call, I've received mail from an interested party that IPR held
by a third party who as far as we know was not involved in IETF
discussions of this draft may apply to the draft. While the
interested party was willing to
Tom == Tom Petch [EMAIL PROTECTED] writes:
Tom I have no problem with the underlying idea, in so far as I
Tom understand it, but I do not agree that this I-D is the best
Tom way to achieve it.
Tom I think that my problem is well illustrated by a sentence in
Tom the Abstract
Lakshminath == Lakshminath Dondeti [EMAIL PROTECTED] writes:
Lakshminath Dan, We are discussing the case of the authenticator
Lakshminath providing a different identity to the peer and the
Lakshminath server here. Sam raised that issue.
This is probably the last message you'll hear
Vidya, I found the model you proposed didn't fit what Dan was talking
about very well. In particular, Dan wants to focus on problems
resulting from the fact that the name of the authenticator used
between the peer and the authenticator may be different than the name
of the authenticator used
Speaking as an individual:
I believe the attack Dan is concerned about is very important and I
believe it is important that this draft make it clear that
distributing keys to the wrong parties does not meet the requirements
of the draft.
I take no position on whether the draft does accomplish
I'd like to draw your attention to changes made to resolve my discuss
comments on Russ's key management draft. The authenticate all parties
section has been changed to the following new text. Please let us
know if you have concerns about the text; the draft is scheduled for
approval in
My individual opinion is that these changes are a matter of style, and
that the current text is fine. If there is strong support for these
changes I can enter an rfc editor note.
___
Ietf mailing list
Ietf@ietf.org
Steven == Steven M Bellovin [EMAIL PROTECTED] writes:
Steven On Wed, 7 Feb 2007 21:14:35 -0800
Steven Joseph Salowey (jsalowey) [EMAIL PROTECTED] wrote:
I would like to understand better why ... no automated key
management is specified.
Steven Do they cite any of
Denis == Denis Pinkas [EMAIL PROTECTED] writes:
Denis Sam,
Russ == Russ Housley [EMAIL PROTECTED] writes:
Russ Denis: I do not consider these to be new comments. You made
Russ them during WG Last Call, and there was considerable
Russ discussion on the S/MIME WG mail list.
The title of this document is very confusing and should be revised to
include the string textual convention.
Seeing this last call announcement I was very puzzled why anyone
thought it would be a good idea to hae a MIB for monitoring and
managing all the URIs on a managed system. I was
Personally I've been convinced that this document definitely should
not be an informational RFC.
It should either be an ion or a bcp at the community's choice based on
how much review they want when the IESG decides to change things.
It doesn't make sense to me for the IETF to publish
Blake == Blake Ramsdell [EMAIL PROTECTED] writes:
Blake OK, let me back up and explain the events as I see them and
Blake try to clarify. And I am certainly welcome to any comments
Blake or criticism about what my role is or how I should proceed
Blake with this.
Blake * My
John == John C Klensin [EMAIL PROTECTED] writes:
John --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko
John [EMAIL PROTECTED] wrote:
Thanks for your note John. Let me also emphasize the need for
these two drafts to be synchronized. Last calling draft-iesg at
this
Mark == Mark Andrews [EMAIL PROTECTED] writes:
- 'The syslog Protocol ' draft-ietf-syslog-protocol-19.txt as
a Proposed Standard
Mark draft-ietf-syslog-protocol-19.txt recommends using a
Mark reliable protocol. Existing implementations of syslog do
Mark this and
Mark == Mark Andrews [EMAIL PROTECTED] writes:
Mark == Mark Andrews [EMAIL PROTECTED] writes:
- 'The syslog Protocol ' draft-ietf-syslog-protocol-19.txt
as a Proposed Standard
Mark draft-ietf-syslog-protocol-19.txt recommends using a
Mark reliable protocol.
Denis, it sounds like you have two issues:
1) This document goes beyond specifying how to determine if a message
is validly signed by a given signer.
2) There is not enough precision in the description of how to validate
a signature.
I strongly suggest that you try and build consensus for
Christian == Christian Vogt [EMAIL PROTECTED] writes:
Christian unamplified flooding would also be possible for the
Christian attacker without HIP because the attacker could send
Christian flooding packets with an IPv6 Routing header, directing
Christian the packets to the
Let me ask a silly question here: Why do we want to distinguish proto
shepherds from chairs? I at least hope all my WGs will produce
documents. That means most of my chairs will be proto shepherds.
Does the difference matter?
___
Ietf mailing list
301 - 400 of 746 matches
Mail list logo
