Gen-Art LC review for draft-cotton-rfc4020bis-01

[Robert Sparks]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-cotton-rfc4020bis-01
Reviewer: Robert Sparks
Review Date: 2013-09-11
IETF LC End Date: 2013-09-24
IESG Telechat date: not scheduled

Summary: This draft is on the right track but has open issues, described 
in the review.


(That summary was taken from the options in RFC6385. I would prefer to say
"There is one minor issue that is bigger than a nit, but it should be 
easy to straighten out")


Issue : Section 2 is very confusing. It starts out listing 4 things that 
look like they all have to be met. But then the last sentence confuses 
things. Is just reinforcing that both a and b have to be met (if so, 
then wouldn't things also stop if c and d weren't met? (see 3.1 step2)).
I suggest replacing "If conditions (a) or (b)" with "If any of the above 
conditions"


Nit 1: Section 3.1 reads harshly at the transition from step 4 to step 
5.  It leaves it implicit that the AD has to approve.
Step 3 has  "if steps 2 and 3 are satisfied". 4020 said "with the 
approval of the Area Director(s)". Adding that text  to step 5 would 
address the nit.


Nit 2: The introduction contains a bit of text that it carried forward, 
slightly modified, from 4020 for which I suggest further modification:

replace
"the IETF community wishes to retain tight control of the protocol"
with
"the IETF community has consensus to retain tight control of the 
registry content"


That way this document is reflecting the actual process point that would 
lead to a tighter registration policy without trying to speculate what 
motivated that consensus.


Nit 3: Several reviewers have pointed to a lack of clarity in section 2 a.
I suggest taking the change John Klensin proposed (with tweaks as below)

The code points must normally be from a space designated
as "RFC Required", "IETF Review", or "Standards Action".
In addition, code points from a "Specification
Required" space are allowed if the specification will be
published as an RFC.

Re: Anyone having trouble submitting I-Ds?

[Robert Sparks]

On 8/18/13 4:04 PM, John Levine wrote:

The anti-hijacking feature causes the confirmation email to
only go to the authors listed on the previous version of the document, so
mail was not sent to me and things are working as expected.

This behavior is not documented to the user when they submit the document
and is therefore a bug.

It's sort of documented somewhere, but I agree that it's a bug that it
doesn't tell the submitter what happened.

I reported it as a bug a while ago, dunno where it is in the tracker.

I remember that report, but am not finding the corresponding ticket with 
a quick search, so I've entered another to make sure this gets addressed:



If it turns out that's a duplicate, that's easy to fix.

RjS

Re: Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34

[Robert Sparks]

Hi Magnus -

Thanks for your careful treatment of these comments - I think you're on 
a good path with all the suggestions below.

Responses to questions and a few comments inline:

On 6/18/13 6:42 AM, Magnus Westerlund wrote:

Hi Robert,

Thanks for the massive review. A number of really good comments in here.
Below you will find my answers, comments, questions and in most cases
clarifications what I see us doing with your comment. These covers your
major and minor comments. The nits we will simply implement as we see
fit, if we have questions we will comeback with those.

WG, there are a number of issues in here that would be greatly helped by
your input!

On 2013-06-05 23:56, Robert Sparks wrote:

Document: draft-ietf-mmusic-rfc2326bis-34
Reviewer: Robert Sparks
Review Date: 05-Jun-2013
IETF LC End Date: 04-Jun-2013
IESG Telechat date: not yet on a telechat


The document is very long, and the structure is unusual - much of the
definition of the protocol itself is in the appendices. You are missing
an opportunity to make this document much shorter (thereby likely
increasing its effectiveness). Much of the jump in from RFC2326 was
importing the description of headers and responses from HTTP, tailoring
them to RTSP. That was a good exercise in that it highlights some issues
that would otherwise be non-obvious (and raises a few questions below).
But you followed the style from HTTP perhaps too closely - much shorter
descriptions without examples might have done the job better. Overall,
separating exposition and examples from the protocol definition would
make it much easier for an implementer to find the definition of the
protocol, and use the document as a reference when diagnosing a failure
to interoperate.

Agree, it would be differently structure if we wrote it from scratch
today. But it is an document that is 10 years in the making with dual
heritage in RFC 2326 and RFC 2068.


Major Issues

I'm not seeing what instructs an RTSP element on how to find the server
it would try to open a connection to given an rtsp or rtsps URI? Are you
assuming it would be doing A or  DNS lookups?

Yes, using A or  DNS records are assumed. No problem making that
explicit.

Should this protocol

use NAPTR/SRV?

Potentially, but as everyone have been using A records for all these
years, I think it is not worth defining it at this stage.

The document should be explicit. On a related note, (and

maybe I missed this), but where do you talk about what an element should
check in the server's certificate when connecting over TLS? Are you
assuming a common name match? Or are you expecting some SubjectAltName
processing?

This draft says in Section 19.2 the following regarding this:

RTSP MUST follow the same guidelines with
regards to TLS [RFC5246] usage as specified for HTTP, see [RFC2818].

Where section 3.1 (Server Identity) of RFC 2818 contains the following:

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used.

Isn't that clear enough on that matter?

Yes - I was worried that I might have missed it before.



The document should say more about when connection reuse is appropriate,
particularly when the connections happened because of an rtsps uri. Two
different names might resolve to the same IP address - reusing a
connection formed when looking at the first name (and verifying the
server's cert) is dangerous. A new connection needs to be formed (and
verified) instead.

I want to check my understanding of the issue you are seeing here. So a
client looks ups foo.example.org, gets an ip address A and establishes
an TCP/TLS connection and verifies that there are a SubjectAltName that
matches foo.example.org works. Then client is going to open
bar.example.com and looks up that address and gets the same IP address A.
Client matches A against existing connections and simply sends a request to
bar.example.com. Thus bypassing the certificate verification.

If we clarify that in the process of opening rtsps://bar.example.com the
client MUST verify that the server certificate for the TLS connection it
considers re-using has an SubjectAltName of bar.example.com, does that
resolve your concerns. If not, please explain the concern further.

You understood what I intended, and your resolution looks sufficient.




The text talks about the option to queue S->C requests if there isn't a
connection to the client available. Ostensibly, this means the request
can go down some future connection. It's not clear how the server can
tell the right client connected. In particular, when using rtsps, how do
you prevent a malicious client from getting such a queued message that
wasn't meant for him?


Okay, this security issue I have totally missed but it is clearly
serious. I don't see any easy way of fixing this. Thus I would su

Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34

[Robert Sparks]

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


<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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


Document: draft-ietf-mmusic-rfc2326bis-34
Reviewer: Robert Sparks
Review Date: 05-Jun-2013
IETF LC End Date: 04-Jun-2013
IESG Telechat date: not yet on a telechat

Summary: This draft is on the right track but has open issues, described 
in the review.


I have not reviewed this document at the level of detail I prefer for 
Gen-art reviews, but have tried to be thorough in the sections I have 
reviewed.


In particular,
I didn't verify the tables and the text agree
I didn't carefully check the ABNF
I haven't thought about possible edge cases and race conditions as much 
as I would have liked
I didn't closely review the security mechanisms in section 19 or the 
specialized MIKEY keying mechanism in the appendix - both need careful 
review from security experts.


One observation I would like to make before calling out issues and nits:

The document is very long, and the structure is unusual - much of the 
definition of the protocol itself is in the appendices. You are missing 
an opportunity to make this document much shorter (thereby likely 
increasing its effectiveness). Much of the jump in from RFC2326 was 
importing the description of headers and responses from HTTP, tailoring 
them to RTSP. That was a good exercise in that it highlights some issues 
that would otherwise be non-obvious (and raises a few questions below). 
But you followed the style from HTTP perhaps too closely - much shorter 
descriptions without examples might have done the job better. Overall, 
separating exposition and examples from the protocol definition would 
make it much easier for an implementer to find the definition of the 
protocol, and use the document as a reference when diagnosing a failure 
to interoperate.


Major Issues

I'm not seeing what instructs an RTSP element on how to find the server 
it would try to open a connection to given an rtsp or rtsps URI? Are you 
assuming it would be doing A or  DNS lookups? Should this protocol 
use NAPTR/SRV? The document should be explicit. On a related note, (and 
maybe I missed this), but where do you talk about what an element should 
check in the server's certificate when connecting over TLS? Are you 
assuming a common name match? Or are you expecting some SubjectAltName 
processing?


The document should say more about when connection reuse is appropriate, 
particularly when the connections happened because of an rtsps uri. Two 
different names might resolve to the same IP address - reusing a 
connection formed when looking at the first name (and verifying the 
server's cert) is dangerous. A new connection needs to be formed (and 
verified) instead.


The text talks about the option to queue S->C requests if there isn't a 
connection to the client available. Ostensibly, this means the request 
can go down some future connection. It's not clear how the server can 
tell the right client connected. In particular, when using rtsps, how do 
you prevent a malicious client from getting such a queued message that 
wasn't meant for him?


Given that the text talks about queuing S-C requests, it should 
explicitly call out whether a server can queue a response if the 
connection the associated request arrived on is no longer available. I 
think what you want to say is that such a response must not be queued, 
and must be dropped.


There are several places in the text that talk about using a 503 
response with a Retry-After header to push back on traffic from an 
element (the first is section 10.7).
* It's not clear what the subject of a 503 is. Is it intended to be 
scoped to requests to the resource in the RURI of the associated 
request? Is it intended to be scoped to the domain in that resource? Or 
is it, like in SIP, intended to be scoped to the server issuing the 
response, independent of what the RURI contained?
* If the intent is that the 503 talks about the server, then you should 
clarify that a proxy doesn't simply forward 503 responses (after 
rewriting CSeqs), and should probably have a response of its own. 
Otherwise, clients that might be talking to two different servers 
through one proxy would lose access to both of them when one of the 
servers 503ed.


Section 4.9.1 lists values the Seek-Style header can take, but 18.45 
lists a completely different set (which most of the rest of the document 
uses). Should 4.9.1 be changed to use the values in 18.45? Are the right 
strings being used in sections 13.4.4 through 13.4.6? Those appear to be 
using strings from 4.9.1.


The document will not stand if you delete some of the appendices. They 
aren't supplementary material. Please consider restructuring the 
normative sections back into the main 

Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

[Robert Sparks]

Thanks Bing -

The updates make the document better, and I appreciate the resolution of 
referencing Tim's expired draft.
I think you've addressed all my comments except for the one on section 
5.1, but that's ok.


For completeness and ease on the ADs, here's an updated summary:

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: May 10, 2013
IETF LC End Date: April 10, 2013
IESG Telechat date: May 16, 2013

Summary: Ready



On 5/2/13 6:02 AM, Liubing (Leo) wrote:

Hi, Robert

Thanks a lot for your continuous careful review.
Please see replies inline.


-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Wednesday, May 01, 2013 12:33 AM
To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
Cc: gen-...@ietf.org; ietf@ietf.org
Subject: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt

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

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

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: April 1, 2013
IETF LC End Date: April 10, 2013
IESG Telechat date: May 16, 2013

Summary: Ready with nits (that border on minor issues)

This update improved the readability significantly, and addressed my
major concern about being able to build a list of the gaps. Thank you.

There are a few issues from my last call review that are still not
addressed.
I have left the classification of minor issue vs nits the same as the
original review to make referring to the earlier review easier,
but please consider all of these Nits. The IESG will need to decide
whether to escalate them.

I've trimmed away the points that were addressed.

On 4/1/13 3:46 PM, Robert Sparks wrote:

--
Minor issues:

The document currently references
draft-chown-v6ops-renumber-thinkabout several times.
That document is long expired (2006). It would be better to simply
restate what is
important from that document here and reference it only once in the
acknowlegements
rather than send the reader off to read it.

This version still references that long expired draft. There was also
conversation on apps-discuss
about making that reference normative. IMHO, this is not the right way
to treat the RFC series, and
strongly encourage moving the text that you want to reference into
something that will
become an RFC.

[Bing] Maybe Brian's suggestion of putting some texts into an appendix is a 
good way. We'll discuss this problem when make the next time update.


Should section 8 belong to some other document? It looks like
operational renumbering
advice/considerations, but doesn't seem to be exploring renumbering
gaps, except for
the very short section 8.2 which says "we need a better mechanism"
without much explanation.

Afaict, this wasn't addressed at all. In particular, "we need a better
mechanism" is still all that
section 8.2 says.

[Bing] Sorry for leaving it out. Will do in next update.


Section 5.1, first bullet. The list below "the impact of ambiguous M/O
flags" says things like
"there is no standard" and "it is unspecified". I think you are trying
to say that there is
ambiguity in what's written, not that nothing's written. This entire
list would benefit from
being recast in terms of what needs to be done (what are the gaps?).

This text remains unmodified.

[Bing] We made revision focusing on explaining "what are the gaps", but the 
texts change was omitted, will do in next update.


--
Nits/editorial comments:

There are a few sentences ending with "etc." in the document. Please
consider deleting the
word from the list - it doesn't help each sentence make its point.

There were some changes, but mostly these still exist. I'll leave
pressing this point further to the RFC Editor.

[Bing] A professional language/editorial check would be helpful.


Seciton 7.1: The first bullet does not parse. If I guess its meaning
correctly
(that it would be benificial to tell hosts that local DNS has been
updated and
they may want to make fresh queries), please be careful with the
wording. The
hosts don't know which names are likely to resolve locally.

This text remained unchanged, and when coming back to the document for a
re-review
(which is somewhat like coming back to an RFC you've read before just
for reference),
it's even harder to understand what it's trying to say than it was when
reading the document
linearly.

I think you are trying to say
"A notification mechanism may be needed to indicate _to_ hosts that a
renumbering event has _changed how local recursive DNS servers will
respond_. That mechanism may also need to indic

Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

Looks good to me. Thanks!
RjS

On 5/6/13 3:02 AM, mohamed.boucad...@orange.com wrote:


Dear Robert,

I updated the document to cover the comments you raised. You can check 
the diff available at: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06


Cheers,

Med

*De :*dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] *De la 
part de* Robert Sparks

*Envoyé :* vendredi 26 avril 2013 17:42
*À :* dh...@ietf.org; ietf@ietf.org; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org

*Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


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

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, 
described in

  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 
6.3.

I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the 
content of RECONFIGURE-REQUEST message it issues (e.g., update the 
Client Identifier list).  This decision is local to the relay (e.g., 
it may be based on observed events such as one or more clients were 
reconfigured on their own).



introduces a race-condition that could lead to an erroneous state. If 
a relay's first message included client A, then the retransmission 
included clients A and B, but that retransmission crosses with a 
success RECONFIGURE-REPLY to the request that only included client A, 
the relay will think it succeeded in asking A and B to be reconfigured.


Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be 
supported, but are not discussed in this document.


places a requirement on a relay (even though it's not using a 2119 
MUST). Is there some other document that defines this requirement that 
you can reference? If not, the requirement should be discussed in this 
document. Alternatively, you could change the sentence to talk about 
the consequences of not having a proprietary means for recovering state.


Nits/editorial comments:

Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt

[Robert Sparks]

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

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

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: April 1, 2013
IETF LC End Date: April 10, 2013
IESG Telechat date: May 16, 2013

Summary: Ready with nits (that border on minor issues)

This update improved the readability significantly, and addressed my 
major concern about being able to build a list of the gaps. Thank you.


There are a few issues from my last call review that are still not 
addressed.
I have left the classification of minor issue vs nits the same as the 
original review to make referring to the earlier review easier,
but please consider all of these Nits. The IESG will need to decide 
whether to escalate them.


I've trimmed away the points that were addressed.

On 4/1/13 3:46 PM, Robert Sparks wrote:

--
Minor issues:

The document currently references 
draft-chown-v6ops-renumber-thinkabout several times.
That document is long expired (2006). It would be better to simply 
restate what is
important from that document here and reference it only once in the 
acknowlegements

rather than send the reader off to read it.
This version still references that long expired draft. There was also 
conversation on apps-discuss
about making that reference normative. IMHO, this is not the right way 
to treat the RFC series, and
strongly encourage moving the text that you want to reference into 
something that will

become an RFC.



Should section 8 belong to some other document? It looks like 
operational renumbering
advice/considerations, but doesn't seem to be exploring renumbering 
gaps, except for
the very short section 8.2 which says "we need a better mechanism" 
without much explanation.
Afaict, this wasn't addressed at all. In particular, "we need a better 
mechanism" is still all that

section 8.2 says.



Section 5.1, first bullet. The list below "the impact of ambiguous M/O 
flags" says things like
"there is no standard" and "it is unspecified". I think you are trying 
to say that there is
ambiguity in what's written, not that nothing's written. This entire 
list would benefit from

being recast in terms of what needs to be done (what are the gaps?).

This text remains unmodified.


--
Nits/editorial comments:

There are a few sentences ending with "etc." in the document. Please 
consider deleting the

word from the list - it doesn't help each sentence make its point.
There were some changes, but mostly these still exist. I'll leave 
pressing this point further to the RFC Editor.



Seciton 7.1: The first bullet does not parse. If I guess its meaning 
correctly
(that it would be benificial to tell hosts that local DNS has been 
updated and
they may want to make fresh queries), please be careful with the 
wording. The

hosts don't know which names are likely to resolve locally.
This text remained unchanged, and when coming back to the document for a 
re-review
(which is somewhat like coming back to an RFC you've read before just 
for reference),
it's even harder to understand what it's trying to say than it was when 
reading the document

linearly.

I think you are trying to say
"A notification mechanism may be needed to indicate _to_ hosts that a 
renumbering event has _changed how local recursive DNS servers will 
respond_. That mechanism may also need to indicate that such a change 
will happen at a specific time in the future."




Section 7.1, third bullet - This isn't obviously about notification. 
Why is it

in this section? What's the gap this is trying to identify?

This text was unchanged.


Section 9.4 - what is it about these that make them gaps, much less 
unsolvable gaps.

Is this discussion in the wrong section of the document?
This is now section 10.3 and is mostly unchanged. It's still not clear 
why this discussion is in the "unsolvable gaps" section.

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Robert Sparks]

On 4/2/13 4:58 AM, Brian E Carpenter wrote:

Just picking a couple of points for further comment:

On 02/04/2013 08:46, Liubing (Leo) wrote:

Hi, Robert

...


-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]

...

The document currently references
draft-chown-v6ops-renumber-thinkabout
several times.
That document is long expired (2006). It would be better to simply
restate what is
important from that document here and reference it only once in the
acknowlegements
rather than send the reader off to read it.

[Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the gap 
analysis. Although the draft is expired, most of the content are still valid.
draft-chown is a more comprehensive analysis, while the gap draft is focusing 
on gaps in enterprise renumbering. So it might not easy to abstract several 
points as important from draft-chown to this draft. We actually encourage 
people to read it.

Robert is right, though, sending people to a long-expired draft is a bad idea.
Of course we have to acknowledge it, but maybe we should pull some of its text
into an Appendix.

Tim Chown, any opinion?
The most recent version (and the one slated for the next telechat) still 
has this long-expired draft referenced.


RjS

Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

On 4/29/13 12:59 AM, mohamed.boucad...@orange.com wrote:

Robert,

Ted suggested a wording which is better than the one I proposed. I made the 
following changes my local copy:

(1)

OLD:
When retransmission is required, the relay may decide to correct the
content of RECONFIGURE-REQUEST message it issues (e.g., update the
Client Identifier list).

NEW:
The relay MAY remove clients from the client identifier list in
subsequent retransmissions, but MUST NOT add clients to the client
identifier list.

(2)

OLD:
Furthermore, means to recover state in failure events must be
supported, but are not discussed in this document.

NEW:
Furthermore, means to recover state in failure events (e.g.,
[RFC5460]) must be supported, but are not discussed in this document.

Is this better?

1 is better.

2 is an improvement, I might say "such as" instead of e.g. to even more
strongly avoid someone thinking you are _requiring_ implementation of
RFC5460.  Even then, it's still not clear whether you're trying to say

"Something that doesn't do this is does not conform to this specification"

or

"Something that doesn't do this isn't as good a tool as it can be and 
may create a condition that operators and users will not like much."


You chose not to use MUST in that sentence. Can you make it less likely 
that someone will assume you meant to?


Cheers,
Med



-Message d'origine-
De : Bernie Volz (volz) [mailto:v...@cisco.com]
Envoyé : samedi 27 avril 2013 06:24
À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN
Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
dhc-triggered-reconfig...@tools.ietf.org
Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

Robert:

The reason to allow this is that otherwise client A will be unnecessarily
reconfigured many times. (It is also possible that a client might Renew on
its own just as this is happening and thus it can also be removed from the
Reconfigure.)

I think the text should be cleaned up to indicate that allowing removal of
already reconfigured clients is recommended (to prevent unnecessary
reconfigures) when retransmitting the Reconfigure-Request.

Note that if clients are added, that is not a retransmission but requires a
"new" message (new XID).

- Bernie

-Original Message-
From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of
Robert Sparks
Sent: Friday, April 26, 2013 12:19 PM
To: mohamed.boucad...@orange.com
Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
dhc-triggered-reconfig...@tools.ietf.org
Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:

Dear Robert,

Thank you for the review.
Please see inline.

Cheers,
Med
____
De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de
Robert Sparks [rjspa...@nostrum.com] Date d'envoi : vendredi 26 avril
2013 17:42 À : dh...@ietf.org; ietf@ietf.org; General Area Review
Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review:
draft-ietf-dhc-triggered-reconfigure-05

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



<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools
.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described

in

the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section

6.3.

I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the

content of RECONFIGURE-REQUEST message it issues (e.g., update the Client
Identifier list).  This decision is local to the relay (e.g., it may be
based on observed events such as one or more clients were reconfigured on
their own).

introduces a race-condition that could lead to an erroneous state. If a

relay's first message included client A, then the retransmission included
clients A and B, but that retransmission crosses with a success
RECONFIGURE-REPLY to the request that only included client A, the relay
will think it succeeded in asking A and B to be reconfigured.

Med: This example does not apply for that text.

Really? What text constrains how you change what's in the retransmission?

   In fact, the example should be the other way around. Perhaps, this can

be made clearer if we change "(e.g., update the Client Identifier list)" to
"(e.g., remove a client f

Re: RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:

Dear Robert,

Thank you for the review.
Please see inline.

Cheers,
Med

De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert 
Sparks [rjspa...@nostrum.com]
Date d'envoi : vendredi 26 avril 2013 17:42
À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
   the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the content of 
RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier 
list).  This decision is local to the relay (e.g., it may be based on observed 
events such as one or more clients were reconfigured on their own).

introduces a race-condition that could lead to an erroneous state. If a relay's 
first message included client A, then the retransmission included clients A and 
B, but that retransmission crosses with a success RECONFIGURE-REPLY to the 
request that only included client A, the relay will think it succeeded in 
asking A and B to be reconfigured.

Med: This example does not apply for that text.

Really? What text constrains how you change what's in the retransmission?

  In fact, the example should be the other way around. Perhaps, this can be made clearer if we 
change "(e.g., update the Client Identifier list)" to "(e.g., remove a client from 
the Client Identifier list)".
If I understand you correctly, you need more than just changing a 
parenthetical e.g.. I think you're saying that you are constraining the 
message changes to be such that if anything earlier in the 
retransmission sequence succeeded, the request in the retransmission 
would also have succeeded. But why do you need that much complexity? Do 
you have it already with any other request?


Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be supported, but 
are not discussed in this document.
places a requirement on a relay (even though it's not using a 2119 MUST). Is 
there some other document that defines this requirement that you can reference?

Med: I'm not aware of any; but if there is one we can cite it.

  If not, the requirement should be discussed in this document. Alternatively, 
you could change the sentence to talk about the consequences of not having a 
proprietary means for recovering state.

Med: Will consider that option if you think this is really needed.

Nits/editorial comments:

Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer: Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

   When retransmission is required, the relay may decide to correct the
   content of RECONFIGURE-REQUEST message it issues (e.g., update the
   Client Identifier list).  This decision is local to the relay (e.g.,
   it may be based on observed events such as one or more clients were
   reconfigured on their own).


introduces a race-condition that could lead to an erroneous state. If a 
relay's first message included client A, then the retransmission 
included clients A and B, but that retransmission crosses with a success 
RECONFIGURE-REPLY to the request that only included client A, the relay 
will think it succeeded in asking A and B to be reconfigured.


Minor issues:

This sentence:

   Furthermore, means to recover state in failure events must be
   supported, but are not discussed in this document.

places a requirement on a relay (even though it's not using a 2119 
MUST). Is there some other document that defines this requirement that 
you can reference? If not, the requirement should be discussed in this 
document. Alternatively, you could change the sentence to talk about the 
consequences of not having a proprietary means for recovering state.


Nits/editorial comments:

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Robert Sparks]

On 4/2/13 4:54 AM, Alexey Melnikov wrote:

Hi Eric,
I am sorry if I sound pedantic below, but I think your suggestion can 
be misinterpreted and thus needs improving:


On 28/03/2013 12:13, Burger Eric wrote:
Rather than guessing all of the bad things that could happen, I would 
offer it would be better to say what we mean, like:
The IMAP interface MUST NOT provide any IMAP facilities that 
modify the underlying message and message metadata, such as mailbox, 
flags, marking for deletion, etc. If the client is authenticated and 
authorized, the IMAP interface MUST provide per-user marking of the 
underlying message as read or flagged.
One way to implement this is in an IMAP server is to always fail 
commands for modifying message metadata. Another way of implementing 
this is to allow them, but ignore (don't persist) results. Both ways 
were used in the past and they have different effect on IMAP clients. 
I hope the requirement is intended to allow for either.


Another thing to consider is that for IMAP servers that implement IMAP 
ACL, the easiest way to meet the intended requirement is by not 
allowing unauthorized users to access some commands on a mailbox. 
Again, a possible reading of your suggested text is that that is not 
allowed.


So, my suggestion is to change "MUST NOT provide any IMAP facilities 
..." to "MUST disallow any IMAP facilities ...".
I think I found a way to say this that strikes a good balance in -06. 
Let me know what you think.

Re: Missing requirement in draft-sparks-genarea-imaparch?

[Robert Sparks]

On 4/1/13 6:49 PM, Sam Hartman wrote:

May I suggest that the specific details of this be left to the
implementation effort.  What is easy to implement in this area depends
significantly on what platform (and here I mean more imap libraries and
imap server technology than say python vs ruby vs .net vs C) A simple
requirement like the implementation should consider how to handle abuse
of message marking.
Sam - I agree, and was taking a very similar approach in my working copy 
already.

Let me know if you think -06 has it right.

RjS

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Robert Sparks]

On 3/28/13 1:17 PM, SM wrote:

Hi Eric,
At 05:13 28-03-2013, Burger Eric wrote:
Rather than guessing all of the bad things that could happen, I would 
offer it would be better to say what we mean, like:
The IMAP interface MUST NOT provide any IMAP facilities that 
modify the underlying message and message metadata, such as mailbox, 
flags, marking for deletion, etc. If the client is authenticated and 
authorized, the IMAP interface MUST provide per-user marking of the 
underlying message as read or flagged.


The IMAP interface is a front-end to the read-only mailboxes 
(archive).  It's easier to do what is mentioned above.
I'm taking more or less that approach in my working copy (I'll be 
posting -06 soon).



Something to ponder:
I use the IMAP interface once, mark a bunch of things as read, and 
then decide never to use the IMAP interface ever again. How long does 
the server need to keep my (per-user) marking metadata? E.g., besides 
CPU and I/O issues, there is a potentially unbounded storage problem 
as well. It is unbounded because in IMAP I can assign any kind of 
label (marking) to a message, even ones I make up.


One thought for an approach to a solution:
1. per-user markings expire after X time units (six months?)
2. per-user markings may take up at most X storage units (512KB?)


I would go for both.
Instead, I propose that we make it possible to notice an abuser and turn 
off access (this is what -06 will contain).


I don't believe we could come to a consensus on an automatic expiry of 
state - there are use cases I can think of where any short

expiration (like 6-months) would be infuriating.

If keeping this state for normal use turns out to be too expensive for 
us, then we will have learned something, and can start talking about 
future IMAP work in general to help systems mitigate that expense.


Per-user metadata can be incredibly useful - I might label things by 
project, work group, draft, mumble, or foo. I would not want to limit 
the labels to red or green. However, we need some predictable limit 
as well.


Yes.

Regards,
-sm

Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Robert Sparks]

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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

Document: draft-ietf-6renum-gap-analysis-05.txt
Reviewer: Robert Sparks
Review Date: April 1, 2013
IETF LC End Date: April 10,2013
IESG Telechat date: Not yet scheduled for a telechat

Summary: This document is not ready for publication as an Informational RFC.
 It may be on the right track, but there issues both in substance
 and form that need to be addressed.

Major issues:

The document doesn't provide what its title and abstract claim it will 
provide.
For instance, the abstract claims a gap analysis is presented following 
a renumbering
event procedure summary, but neither appear in the draft. There are a 
few places
in the text that say "this is a gap", but usually it's not clear what 
"this" means.


The stated intent is to identify missing capabilities (gaps) and the work
needed to provide them. The document should lay these out very clearly. 
As the

document is currently written, it is difficult to pull out a simple list of
identified gaps. While addressing that, it would help more to provide some
sense of the relative importance of addressing each of the gaps identified.

There are several significant issues with clarity. I will point to the most
difficult in a section below.

--
Minor issues:

The document currently references draft-chown-v6ops-renumber-thinkabout 
several times.
That document is long expired (2006). It would be better to simply 
restate what is
important from that document here and reference it only once in the 
acknowlegements

rather than send the reader off to read it.

RFC4076 seems to say very similar things to this document. Should it 
have been referenced?


Section 5.3 punts discussion of static addresses off to RFC 6866. That 
document was scoped
only to Enterprise Networks. The scope of this document is larger. Are 
there gaps because
of that difference in scope that were missed? Would it make sense to 
summarize any gaps

RFC 6866 identified that are relevant to this document here?

Should section 8 belong to some other document? It looks like 
operational renumbering
advice/considerations, but doesn't seem to be exploring renumbering 
gaps, except for
the very short section 8.2 which says "we need a better mechanism" 
without much explanation.



--
Text needing clarity (more than nits):

Section 4.1, second paragraph: The first sentence needs to be 
simplified. Something like
"Delegation routers may need to renumber themselves with new delegated 
prefixes" perhaps.
The second sentence speaks of "the router renumbering issue" as if it's 
clear which particular
issue you're actually talking about. Is there a gap here? If so, 
consider replacing the entire

paragraph with an explicit description of the gap.

Section 5.1, first bullet, 2nd paragraph: The third sentence (starting 
"In ND protocol,")

makes no sense. The fourth sentence is also hard to parse.

Section 5.1, first bullet. The list below "the impact of ambiguous M/O 
flags" says things like
"there is no standard" and "it is unspecified". I think you are trying 
to say that there is
ambiguity in what's written, not that nothing's written. This entire 
list would benefit from

being recast in terms of what needs to be done (what are the gaps?).

Section 5.2, last paragraph. It's not clear what you are trying to say 
here. Is it simply
that the natural pressures in an ISP make it more likely that an ISP 
would choose to use
DNS names as part of configuration than an enterprise would? If so, can 
you list what some

of those pressures are? What gap is this discussion trying to identify?

Section 6.1, first paragraph, first sentence (starting "For DNS records 
update") - this sentence
does not parse. What is it trying to say, and what's the gap you are 
trying to point to?


Section 6.3, 6th paragraph. "So there's a big gap for configuration 
aggregation" is
unclear. Is it that configuration isn't stored in one place, or that it 
can't be

found through one place, or something different?

Section 7.1 second bullet. Taking this partial quote from RFC4192 
destroyed the meaning
of the sentence. The original sentence said "The suggestion applies" - 
this misquote says
"reducing the delay applies". There's no benefit to quoting 4192 
directly - say what you

mean and reference 4192.


--
Nits/editorial comments:

There are a few sentences ending with "etc." in the document. Please 
consider deleting the

word from the list - it doesn't help each sentence make its point.

Introduc

Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

[Robert Sparks]

All -

draft-sparks-genarea-imaparch has been revised to address comments from
Pete Resnick and Barry Leiba. Jari Arkko has suggested that the security 
considerations
section contain something like what RFC6778 contained about potential 
risks to CPU

and I/O utilization. I plan to make that change in the next version.

While looking at it, I noticed we don't explicitly say that this IMAP 
interface MUST NOT
allow messages in the archive to be deleted or moved to other mailboxes, 
and MUST NOT
allow messages to be inserted. I plan to add those as requirements in 
the next version.


RjS

On 3/26/13 3:45 PM, internet-dra...@ietf.org wrote:

A new version (-05) has been submitted for draft-sparks-genarea-imaparch:
http://www.ietf.org/internet-drafts/draft-sparks-genarea-imaparch-05.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-sparks-genarea-imaparch/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-sparks-genarea-imaparch-05

IETF Secretariat.

Re: Is there a Git repository of RFCs? Or of Internet-Drafts?

[Robert Sparks]

On 3/15/13 1:40 PM, Dale R. Worley wrote:

From: Christopher Morrow 

curious why rsync doesn't also seem 'straightforward' and 'well
supported' ?

Is this an advocacy of a particular tool?  Or are you asserting that
rsync can be used to maintain a directory of RFCs?  If the latter,
could you supply some details (including, especially, how to get at
the public repository)?
 -> 



alternatively, look at the third section on the right column at 


(starting with "Download the latest documents")

RjS



Dale

Re: Last Call: (Methodology for Benchmarking SIP Networking Devices) to Informational RFC

[Robert Sparks]

Please see my response to the last call message for 
draft-ietf-bmwg-sip-bench-term. That review covered this document and 
that one at the same time.


RjS

On 1/16/13 3:47 PM, The IESG wrote:

The IESG has received a request from the Benchmarking Methodology WG
(bmwg) to consider the following document:
- 'Methodology for Benchmarking SIP Networking Devices'
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-01-30. 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


This document describes the methodology for benchmarking Session
Initiation Protocol (SIP) performance as described in SIP
benchmarking terminology document.  The methodology and terminology
are to be used for benchmarking signaling plane performance with
varying signaling and media load.  Both scale and establishment rate
are measured by signaling plane performance.  The SIP Devices to be
benchmarked may be a single device under test (DUT) or a system under
test (SUT).  Benchmarks can be obtained and compared for different
types of devices such as SIP Proxy Server, SBC, and server paired
with a media relay or Firewall/NAT device.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/ballot/


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

Re: Last Call: (Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices) to Informational RFC

[Robert Sparks]

Reviews of draft-ietf-bmwg-sip-bench-term-08 and 
draft-ietf-bmwg-sip-bench-meth-08


Summary: These drafts are not ready for publication as RFCs.

First, some of the text in these documents shows signs of being old, and the
working group may have been staring at them so long that they've become 
hard to
see.  The terminology document says "The issue of overload in SIP 
networks is

currently a topic of discussion in the SIPPING WG." (SIPPING was closed in
2009). The methodology document suggests a "flooding" rate that is orders of
magnitude below what simple devices achieve at the moment. That these 
survived
working group last call indicates a different type of WG review may be 
needed

to groom other bugs out of the documents.

Who is asking for these benchmarks, and are they (still) participating 
in the

group?  The measurements defined here are very simplistic and will provide
limited insight into the relative performance of two elements in a real
deployment. The documents should be clear about their limitations, and 
it would
be good to know that the community asking for these benchmarks is 
getting tools
that will actually be useful to them. The crux of these two documents is 
in the

last paragraph of the introduction to the methodology doc: "Finally, the
overall value of these tests is to serve as a comparison function between
multiple SIP implementations".  The documents punt on providing any 
comparison

guidance, but even if we assume someone can figure that out, do these
benchmarks provide something actually useful for inputs?

It would be good to explain how these documents relate to RFC6076.

The terminology tries to refine the definition of session, but the 
definition
provided, "The combination of signaling and media messages and processes 
that
support a SIP-based service" doesn't answer what's in one session vs 
another.
Trying to generically define session has been hard and several working 
groups

have struggled with it (see INSIPID for a current version of that
conversation). This document doesn't _need_ a generic definition of 
session -
it only needs to define the set of messages that it is measuring. It 
would be
much clearer to say "for the purposes of this document, as session is 
the set
of SIP messages associated with an INVITE initiated dialog and any 
Associated

Media, or a series of related SIP MESSAGE requests". (And looking at the
benchmarks, you aren't leveraging related MESSAGE requests - they all 
appear to

be completely independent). Introducing the concepts of Invite-initiated
sessions and non-invite-initiated sessions doesn't actually help define the
metrics. When you get to the metrics, you can speak concretely in terms of a
series of INVITEs, REGISTERs, and MESSAGEs. Doing that, and providing a 
short

introduction pointing folks with PSTN backgrounds relating these to "Session
Attempts" will be clearer.

To be clear, I strongly suggest a fundamental restructuring of the 
document to
describe the benchmarks in terms of dialogs and transactions, and remove 
the IS

and NS concepts completely.

The INVITE related tests assume no provisional responses, leaving out the
effect on a device's memory when the state machines it is maintaining 
transition
to the proceeding state. Further, by not including provisionals, and 
building
the tests to search for Timer B firing, the tests insure there will be 
multiple
retransmissions of the INVITE (when using UDP) that the device being 
tested has
to handle. The traffic an element has to handle and likely the memory it 
will
consume will be very different with even a single 100 trying, which is 
the more

usual case in deployed networks. The document should be clear _why_ it chose
the test model it did and left out metrics that took having a provisional
response into account. Similarly, you are leaving out the delayed-offer 
INVITE
transactions used by 3pcc and it should be more obvious that you are 
doing so.


Likewise, the media oriented tests take a very basic approach to simulating
media. It should be explicitly stated that you are simulating the 
effects of a
codec like G.711 and that you are assuming an element would only be 
forwarding

packets and has to do no transcoding work. It's not clear from the documents
whether the EA is generating actual media or dummy packets. If it's actual
media, the test parameters that assume constant sized packets at a constant
rate will not work well for video (and I suspect endpoints, like B2BUAs, 
will

terminate your call early if you send them garbage).

The sections on a series of INVITEs is fairly clear that you mean each 
of them

to have different dialog identifiers.  I don't see any discussion of varying
the To: URI. If you don't, what's going to keep a gateway or B2BUA from
rejecting all but the first with something like Busy? Similarly, I'm not
finding where you talk about how many AoRs you are registering against 
in the
registration tests. I think, as written, someone could

Re: Issues relating to managing a mailing list...

[Robert Sparks]

The current plan is to investigate both a web based archive access 
mechanism and an IMAP based one.


I split the requirements for them into two drafts so the projects could 
be pursued separately.

See also 



On 3/15/12 12:57 PM, Cyrus Daboo wrote:

Hi Pete,

--On March 15, 2012 10:49:25 AM -0500 Pete Resnick 
 wrote:



Along those lines how about setting up an IETF IMAP server with
mailboxes for each mailing list hosted by the IETF?


There has been a discussion under way for some time to get that to
happen. I believe RFP's are being thought about (or written).


Right, so isn't this, 
, 
entirely satisfiable via IMAP? At the very least I think that draft 
needs another requirement:


* Users must be easily able to reply to archived messages using their 
email client of choice. In particular, replies need to preserve 
threading information in the form of References and In-Reply-To email 
headers.

Ack.

Re: Paris IETF Codesprint

[Robert Sparks]

If you are planning to join this codesprint, please make sure you've let 
us know by

adding yourself to this page:

so we can provision correctly.

If you've not thought about the codesprint, take a couple of minutes now 
to look over

the kinds of things we're planning to work on:

Please add to that list if there's something important to you that you 
see missing.
If see something there you'd really like to have, please join us and 
make it happen.


RjS

On 1/15/12 2:12 PM, IETF Chair wrote:

Paris IETF Codesprint

When:  Saturday, 24 March 2012, starting at 9:30 AM

Where: IETF Hotel

What:  A bunch of hackers get together to work on code for the IETF.
 All code will become part of the open source IETF tools.

Who:   Hopefully you can help

Many of the results of previous codesprint activities are being
used every day by the IETF community.  Shortly before the Paris
meeting, we will transition from the current database schema to a
new one.  We believe that the new schema will make many tasks
much easier.  No doubt, the transition will uncover new bugs.
Work to polish or improve existing tools, fix bugs, or make new
tools.  All efforts are appreciated and most welcome.

Steve Conte will be helping with advance planning.  Henrik Levkowetz
will be coordinating the event in Paris.  You can find more information
here:

  http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83Sprint

If you are able to participate, please sign up on the wiki at:

  http://trac.tools.ietf.org/tools/ietfdb/wiki/IETF83SprintSignUp

Please support the tools development effort,
  Russ

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

Proposal to remove three datatracker pages (https://datatracker.ietf.org/iesg/ann/ind/, /new, and /prev

[Robert Sparks]

There are three pages exposed at the datatracker that have become stale 
or are producing erroneous information.

https://datatracker.ietf.org/iesg/ann/ind/
https://datatracker.ietf.org/iesg/ann/new/
https://datatracker.ietf.org/iesg/ann/prev/

Has anyone been using those links?

The first link, in particular has not been updated to reflect RFC5742, 
and is currently showing an incomplete set.


All of the information on those pages is available in other locations 
(at the very least at

.

Unless someone has been relying on these links, I propose removing them.

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

Re: meeting slots

[Robert Sparks]

I understand Dave's concern, but I think it would be valuable to make it easy 
to see
what has been requested. Any changes to the conflict list would still have to 
come 
through the chairs, encouraging that distributed work model.

I've entered this as an idea that someone might pick up for work at a 
codesprint:


RjS

On Oct 12, 2011, at 8:53 PM, John C Klensin wrote:

> 
> 
> --On Wednesday, October 12, 2011 11:11 -0700 Dave CROCKER
>  wrote:
> 
>> On 10/12/2011 10:27 AM, Margaret Wasserman wrote:
>>> I was not picturing everyone adding their own conflicts.
>>> However, I thought this might help us avoid some of the
>>> issues we've had in the past, where obvious group-level
>>> conflicts are omitted, and meetings have to be rescheduled at
>>> the last moments.
>> 
>> I'll suggest a more distributed model:
>> 
>> Chairs circulate among their wg, the conflicts they believe
>> should be avoided. When that discussion settles down, the
>> chairs submit their set to ietf staff. IETF staff and ietf
>> main list are thereby spared the effort, but each set gets
>> review beyond the chairs.
> 
> Of course, some WGs / Chairs have been doing this, or variations
> on it. for some years now.   I'd venture that it works better in
> some WGs than others... much like many other things.
> 
>   john
> 
> 
> 
> 
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: draft-housley-two-maturity-levels

[Robert Sparks]

Scott -

Didn't RFC 5657 address your point 2?

The current proposal no longer requires this report during advancement, but it 
does not disallow it.
I hope it's obvious that I believe these reports are valuable, but I am willing 
to accept the proposed
structure, with the hope and expectation that  communities that are serious 
about producing and 
refining protocols will be producing these reports anyhow.

RjS

On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:

> 
> this is better than the last version but
> 
> 1/ I still see no reason to think that this change will cause any
> significant change in the percent of Proposed Standards that move up the
> (shorter) standards track since the proposal does nothing to change the
> underlying reasons that people do not expend the effort needed to
> advance documents
> 
> 2/ one of the big issues with the PS->DS step is understanding what
> documentation is needed to show that there are the interoperable
> implementations and to list the unused features - it would help a lot to
> provide some guidance (which I did not do in 2026 - as I have been
> reminded a number of times :-) ) as to just what process is to be
> followed
> 
> could be
>   a spread sheet showing features & implementations
>   an assertion by the person proposing the advancement that the
> requirements have been met
> or something in between
> 
> Scott
> ___
> 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: Late comment on draft-ietf-sippping-sip-offeranswer-14

[Robert Sparks]

I believe the current text in the draft reflects the discussion from 2007 at


To summarize, while we think there may be implementations that interpret a 
change of session-id as a session reset,
RFC3264 doesn't support the notion. The top-level assumption of 3264 is that 
there is one SDP session associated
with a SIP dialog. (See in particular:


and
)

The thread explores places where some folks would like to things to be 
different, but those
things will need normative updates, probably to more than one RFC.

I believe the text in the draft is consistent with what our current specs say.

For the normative updates we would need to make for this particular topic, I 
think 
restarting the debate on the RAI list (with pointers to SIPCORE and MMUSIC) is 
the right thing to do.

RjS

On Apr 26, 2011, at 8:37 AM, Elwell, John wrote:

> I know last call finished already, but the following has just been brought to 
> my attention:
> 
> In section 5.2.5
> "Changing the o-line,
>  except version number value, during the session is an error case.
>  The behavior when receiving such a non-compliant offer/answer SDP
>  body is implementation dependent. "
> I would content this is NOT an error situation, or at least not an error in 
> the case where a NEW session is being signalled.
> 
> Consider a 3PCC situation along the lines described in section 7 of RFC 3725. 
> The controlling B2BUA converts a session between UA A and UA B into a session 
> between UA B and UA C. Prior to this conversion, UA B has received UA A's SDP 
> (SDP A). As a result of the conversion, UA B receives UA C's SDP (SDP C).
> 
> SDP C is likely to be completely different from SDP A. Therefore just a 
> change of version number in the o-line is insufficient and would probably 
> violate RFC 3264. In particular, if SDP A has 2 m-lines and SDP C has only 
> one m-line, the change from 2 m-lines to 1 m-line is not permitted according 
> to RFC 3264. So although RFC 3725 talks about the controlling B2BUA adjusting 
> version numbers, that is insufficient in some cases.
> 
> The text of 5.2.5 then goes on to say:
> "The behavior when receiving such a non-compliant offer/answer SDP
>  body is implementation dependent."
> It is not clear what this fails to comply with. I can find nothing in RFC 
> 3264 that stops you sending a new o-line if there is a new session. Yes, it 
> would be non-compliant if only modifying an existing session, but how does 
> the recipient know whether or not it is a new session, and therefore whether 
> or not it is valid?
> 
> It then goes on to recommend use of Replaces in this situation (i.e. change 
> of session):
> "If a UA needs to negotiate a
>  'new' SDP session, it should use the INVITE/Replaces method."
> But Replaces is not feasible if the UA concerned does not support it (and 
> hence "should", presumably). So there will still be cases where a controlling 
> B2BUA is forced to change the o-line (not just the version) in order to 
> comply with RFC 3264.
> 
> So there needs to be a mechanism for changing to a 'new' session without 
> relying on Replaces. As far as I can see, there is no standards track RFC 
> that forbids changing the o-line to achieve this, so this new Informational 
> draft should not attempt to make that change, and in particular should not do 
> so without proposing an alternative solution.
> 
> A simple fix would be to delete the entire bullet beginning "In the o-line, 
> only the version number may change".
> 
> John
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

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

Re: Last Call: (Requirements for a Working Group Charter Tool) to Informational RFC

[Robert Sparks]

Hi Paul -

In section 2.2, I would prefer either using the names the tracker currently 
uses for IESG evaluation:
"Discuss" and "Comment", or some set of words that do not intersect those, 
perhaps "Blocking" and
"Not-Blocking". The current set ("discuss" and "regular") will lead to 
confusion.

In section 2.7, you don't specifically capture WGs that currently exist, but 
are not rechartering at the moment.
I think you meant to as part of the second paragraph, but the last phrase could 
be read to be exclusive.

(As an aside - do you intend that for existing working groups, this history 
will go all the way back to when
the group was formed? Will we be able to count on  being the 
charter that the working group
formed with for all foo?)

In section 3.1 - It would be better to have the ability to override the tool's 
rejection of a name because some
previous effort (particularly abandoned ones) had the same name. If someone 
thought about using a name
5 years ago, but never took it even to the point of Internal Review, why should 
the tool force it not be be used now?
This is a place that human judgement should be allowed to be exercised.

Also, we should make sure the tool doesn't unintentionally make reopening a 
closed WG harder than intended.

It would help to clarify in the first bullet in 3.1 that the tool should prompt 
the AD, but not prevent them from
completing the move if that's the right thing to do. (The tool is providing a 
reminder, not enforcing a rule).

In the 4th bullet of that list, you ask the tool to send a note to the 
scretariat to schedule discussion on a telechat.
In practice today, this happens as part of the transition into External Review. 
I suggest moving the sentence into
the 3rd bullet.

In section 3.2's second bullet, it is possible, I believe, to directly approve 
a recharter from internal review. The tool
should allow that transition.

I'm a little concerned about taking working groups for which a recharter is 
being considered out of the state named
"WG Exists". Semantically, if you aren't in that state, it implies the WG 
doesn't exist, and I could see someone
drawing the wrong conclusion from a search. The best way to avoid this might be 
to rename the "WG Exists" state
to something like "WG Chartered - no rechartering effort currently in progress" 
(which I realize is too wordy).


RjS








On Mar 11, 2011, at 4:11 PM, The IESG wrote:

> 
> The IESG has received a request from the General Area Open Meeting WG
> (genarea) to consider the following document:
> - 'Requirements for a Working Group Charter Tool'
>   as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-03-25. 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.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-genarea-charter-tool/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-genarea-charter-tool/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Re: Last Call: (Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC

[Robert Sparks]

One additional thought -

How much would the list of attributes in 2.1.6 need to be expanded to make one 
of these user-defined lists
enough to satisfy the initial "Reporting Requirements" in section 4.3 of 
draft-ietf-genarea-datatracker-iana-rfced-extns-00?
Should we add the ability to match against the values (or absence of value) of 
a state for the various state machines tracked by the tracker?

RjS

On Mar 14, 2011, at 4:26 PM, Robert Sparks wrote:

> Paul -
> 
> 1) If we publish this as an RFC, note that imgur.com will only keep an image 
> if it's viewed at least once every three months.
> 
> 2) In the list of things constituting an "update to an RFC", could you call 
> out marking an RFC as Historic, and changing the
> maturity level of an RFC in place (such as was done for 5652)
> 
> 3) 2.1.2 talks of the ease of use to create a datatracker account. I think we 
> have that already through the tools system.
> Are you thinking this will require the creation of a different system?
> 
> RjS
> 
> On Mar 4, 2011, at 4:46 PM, The IESG wrote:
> 
>> 
>> The IESG has received a request from the General Area Open Meeting WG
>> (genarea) to consider the following document:
>> - 'Requirements for Internet-Draft Tracking by the IETF Community in the
>>  Datatracker'
>>  as an Informational
>> RFC
>> 
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2011-03-18. 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.
>> 
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
>> 
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
>> 
>> 
>> 
>> No IPR declarations have been submitted directly on this I-D.
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

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

Re: Last Call: (Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC

[Robert Sparks]

Paul -

1) If we publish this as an RFC, note that imgur.com will only keep an image if 
it's viewed at least once every three months.

2) In the list of things constituting an "update to an RFC", could you call out 
marking an RFC as Historic, and changing the
maturity level of an RFC in place (such as was done for 5652)

3) 2.1.2 talks of the ease of use to create a datatracker account. I think we 
have that already through the tools system.
Are you thinking this will require the creation of a different system?

RjS

On Mar 4, 2011, at 4:46 PM, The IESG wrote:

> 
> The IESG has received a request from the General Area Open Meeting WG
> (genarea) to consider the following document:
> - 'Requirements for Internet-Draft Tracking by the IETF Community in the
>   Datatracker'
>   as an Informational
> RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-03-18. 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.
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-genarea-datatracker-community/
> 
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

Fwd: [Sip] New version of draft-ietf-sip-ipv6-abnf-fix

[Robert Sparks]

fyi

Begin forwarded message:

> From: "Vijay K. Gurbani" 
> Date: May 3, 2010 9:45:53 AM CDT
> To: IETF SIP List 
> Cc: Brian E Carpenter , Brett Tate 
> 
> Subject: [Sip] New version of draft-ietf-sip-ipv6-abnf-fix
> 
> Folks: A new version (-05) of draft-ietf-sip-ipv6-abnf-fix
> is ready to be sent to the IESG.
> 
> The summary of changes is as follows:
> 
> 1) Minor typo and grammatical fixes.
> 2) Added a new S4 in -05 to serve as a reference point to
>   draft-ietf-6man-text-addr-representation-07, a draft on
>   how to generate a canonical IPv6 textual representation.
> 
>   draft-...-addr-representation is now referenced using a
>   normative SHOULD and has been made a normative reference.
>   This should not delay the release of draft-...-ipv6-abnf-fix
>   since draft-...-addr-representation is now in RFC Ed Queue.
> 
> The relevant links are:
> New version (-05):
> http://www.ietf.org/internet-drafts/draft-ietf-sip-ipv6-abnf-fix-05.txt
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-sip-ipv6-abnf-fix-05
> 
> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: v...@{alcatel-lucent.com,bell-labs.com,acm.org}
> Web:   http://ect.bell-labs.com/who/vkg/
> ___
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP 
> implementation.
> Use dispa...@ietf.org for new developments on the application of sip.
> Use sipc...@ietf.org for issues related to maintenance of the core SIP 
> specifications.

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Sparks]

John, Jari -

I was one of the folks expressing the concern Jari points to below,  
and it's
a small facet of a larger worry I have about a potential (and I think  
likely)
unintended consequence of the header/boilerplate changes. To capture  
that
in this thread (with apologies for walking through old discussions) :  
specifically,
I think we're making it even harder for people who are not deeply  
steeped in

IETF arcana to tell the difference between the output of a working group
(or any other IETF product) and the output of an individual. By  
downplaying
that distinction, we are also making it easier for people with the  
motivation
to champion technologies that compete with IETF products to convince  
those

non IETF-arcana-steeped folks around them to follow.

But, that's water under the headers and boilerplate consensus building  
bridge.


I think it should be more _routine_ than we are making it for _some_  
body

representing IETF consensus to shine a light on that distinction when
necessary. The escalation process you point to is a fairly high bar  
and it
puts providing the required energy on the wrong parties. I'm sensitive  
to

the 'how it has always been' argument, but we are exactly in the process
of changing to a new RFC-editor model.

I've also been asking a few regular contributors and some chairs what
they thought about this, and am very frustrated with how little  
attention

the entire change this small conversation is part of appears to have
received in the greater community. I don't know what to do to improve  
that
beyond what we're doing now (through calls like this and through  
individual

prodding).

RjS

On Aug 31, 2009, at 9:37 AM, John C Klensin wrote:




--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
 wrote:


I would like to get some further input from the community on
this draft.
...
And now back to the input that I wanted to hear. I would like
to get a sense from the list whether you prefer (a) that any
exceptional IESG note is just a recommendation to the RFC
Editor or (b) something that is always applied to the
published RFC. Please reply before the next IESG meeting on
September 10. Some e-mails on this topic have already been
sent in the Last Call thread -- I have seen those and there is
no need to resend.


Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.


...


   regards,
 john



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

Reminder: Tools codesprint at IETF74

[Robert Sparks]

If you are planning to join the codesprint at IETF74, please add  
yourself to the wiki page at



to help us build a rough idea of how many folks will be present. More  
information about this sprint can be found at




If you can't work with the wiki for some reason, please drop me a note.

Thanks,

RjS


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

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

[Robert Sparks]

I support conducting this experiment.

RjS

On Jul 17, 2008, at 4:33 PM, IETF Chair wrote:


The IESG is considering an experiment for IETF 73 in Minneapolis, and
we would like community comments before we proceed.  Face-to-face
meeting time is very precious, especially with about 120 IETF WGs
competing for meeting slots.  Several WGs are not able to get as much
meeting time as they need to progress their work.  As an experiment,
we are considering adding two Friday afternoon one-hour meeting slots.
The proposed Friday schedule would be:

  0900-1130 Morning Session I
  1130-1300 Break
  1300-1400 Afternoon Session I
  1415-1515 Afternoon Session II

Please share your thoughts about this proposed experiment.  The
proposed experiment will be discussed on the IETF Didcussion mail
list (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: SHOULD vs MUST

[Robert Sparks]

fwiw -

I have, for many SIPits (a rather large interop event for SIP  
implementations) worked to get the people writing code from these  
documents to understand that MUST means MUST and SHOULD means MUST ... 
(very long pause)... unless you _really_ know that not following the  
SHOULD won't result in very bad things.


They typically respond with MUST means MUST unless they're sure they  
can get away without it most of the time, and that SHOULD means its in  
some future release that will get funding maybe someday. Some of that  
response is tongue-in-cheek - some of it isn't.


I see a strong trend for unadorned SHOULDs to remain unimplemented.  
SHOULDs that have a very clear, and explicitly called out even when  
they seem incredibly obvious, explanation of the bad things that can  
happen if you don't follow them get implemented.


So, at least for the documents I edit, I work really hard to explain  
the SHOULDs to help motivate the implementors to actually build things  
that conform to it.


RjS



On Jun 25, 2008, at 12:02 PM, Scott Brim wrote:


On 6/25/08 8:24 AM, John C Klensin allegedly wrote:

--On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
<[EMAIL PROTECTED]> wrote:

... and draft authors should include explanations in their
drafts of the reasons an implementor might legitimately have
for not implementing the "should".  For example, an older
operating system that does not support a new capability.



Do you really mean, e.g., 	... where feasible and, in the author's  
judgment,

appropriate, it is desirable to include explanations or
illustrations of the exception cases in drafts that use
SHOULD.
???
I've run into a number of situations over the years in which
there are known edge cases that prevent a MUST but where those
edge cases are rare and obscure enough that describing them
would require extensive text.


My rule of thumb is: when you're writing the draft if something is  
not a MUST, ask yourself "why not?" and write down your answer.  You  
can be brief but make it clear that the SHOULD is a MUST with  
exceptions.


There's no way we should have strict process rules about this.  The  
IETF has enough rules as it is.  However, explanations of SHOULDs do  
make better standards.  The point is to give guidance to  
implementors.  I did an informal survey last year and found that  
some implementors treat every SHOULD as a MUST, but more of them  
just treat a SHOULD as a MAY, essentially to be ignored.  An  
explanation of the circumstances surrounding a SHOULD will lead to a  
lot more consistency in implementation.  Many SHOULDs in RFCs are  
because there are old implementations that need to be taken into  
account, or because some capability isn't widely possible yet but  
will be within the lifetime of the standard.  If a MUST becomes a  
SHOULD to take that into account, and you explain it, your chances  
of getting rid of non-MUST-capable implementations eventually goes  
up tremendously.  So, to reiterate, when you're writing the draft if  
something is not a MUST, ask yourself "why not?" and write down your  
answer.



___
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: [Sip] NOTIFY on call transfer procedure

[Robert Sparks]

Section 6 of RFC3515 calls out why REFER is constructed this way.

The root cause is the fixed length of any SIP non-INVITE transaction.
The approach you sketch won't work as provisional responses to 
non-INVITE requests do _not_ lengthen the transaction.

If you want a more detailed description, look at
http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-00.txt
and
http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-00.txt

RjS


On Thu, 2004-05-06 at 23:55, Thomas Ackermann wrote:
> Hi all,
> 
> can anybody tell me why the transfer procedure needs NOTIFY message
> with application/sipfrag message body?
> 
> Why not simply keep the REFER transaction open by sending:
>  - a provisional response instead of the 202/Accepted and
>  - a final 200/OK response instead of NOTIFY(200 OK) ?
> Just like the INVITE transaction with all its intermediate responses.
> 
> Or even more simple:
> The Transferee sends the BYE by itself instead of asking the Transferor
> to terminate the call?
> 
> Do you know the reason why the NOTIFY transaction has been added to
> call transfer procedure?
> 
> Thanks for your help,
> Thomas
> 
> ___
> Ietf mailing list
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/ietf


___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf