Dear Working Group,

You may have noticed multiple revisions of draft-ietf-homenet-arch posted 
recently. After many iterations and a ton of work for our Editor In Chief, Tim 
Chown, all IESG “DISCUSS” positions have been resolved to either “Yes” or “No 
Objection”, with the exception of one “Abstain” from one of our Routing Area 
ADs who had requested that the following text be added to section 3.5:

“Routing within the homenet will determine the least cost path across
 the homenet towards the destination address given the source address.
 The path cost will be computed as a linear sum of the metric assigned
 to each link.  The metric may be configured or automatically derived
 per link based on consideration of factors such as worst-case queue
 depth and router processing capabilities.”

The Chairs felt that the first half of this text was unnecessarily prescriptive 
for this document and did not reflect something the WG had achieved consensus 
on at this time.  We proposed a compromise that incorporated the latter 
non-normative half of this text in an earlier paragraph.  On the basis that we 
understood that this compromise had been accepted by the respective AD, the -14 
revision was posted.

After -14 was posted and the AD’s position changed to "No Objection", we 
noticed that the above paragraph had inadvertently been included, in full, in 
addition to the latter half included as part of the proposed compromise! At the 
Chairs’ request, Tim removed the above paragraph in -15, which caused the AD to 
object as it appeared to him that his text was being removed after the fact.

Later today, Tim will be posting a -16 revision of the document that reinstates 
the above paragraph, in full, and removes the “compromise” text. On the basis 
that the new text is a potentially substantive change, our AD has requested 
that we put the document through one more Working Group Last Call to determine 
WG consensus on that issue.

In addition, one small change was introduced in the -15 revision based on WG 
feedback where a reference to Source Specific Multicast [RFC 4607] was 
introduced, but had not been called out explicitly in London or before. That 
change is as follows:

Old:
   It is desirable that, subject to the capacities of devices on certain
   media types, multicast routing is supported across the homenet.

New:
   It is desirable that, subject to the capacities of devices on certain
   media types, multicast routing is supported across the homenet,
   including source-specific multicast (SSM) [RFC4607].

The WGLC will commence immediately after the -16 is posted, and will last for 
two weeks.

We very much want your feedback here, but are not aiming to revisit the 
document in its entirety. As such, we would like to limit the scope of the WGLC 
to just the text quoted in this email.

Many thanks,

Ray and Mark

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to